This (All the other...) isn't totally true, there are Linux security vendors doing Open Source work, such as Enguarde and some promising things coming out of the RSBAC camp (Alt.Castle?)
Will there be a feature comparison to RSBAC (http://www.rsbac.de) and the NSA-sponsored stuff available anywhere soon?
Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.
Apache is meant to have configurability over performance, and does dynamic content. However, I'm sure we'll see better performance from *nix based Web servers over time.
Paul
It may be true of most people, however there are a lot of people writing a heck of a lot of code gratis. If *all* software were free (as in beer), not many companies would go out of business which weren't ISVs or Microsoft, or software consulting houses. If it were all required to be Open Source but not free very few at all would go out of business (companies like SuSe and RedHat open source all their software and they seem to be in business, so you see it's possible to do.)
The only externally used software I've written for my current employer was given away. Eventually software will reach the same stage of life as stock photography- almost all the pictures necessary are already taken- what will happen to your economics then?
Remember, unless you're playing, software isn't an end, it's a tool. If hammers were free, only the hammer makers and sellers would be impacted. The fact that there are very few commercial DNS server products on the market, for instance, doesn't mean people won't sell non-generic name service solutions or go hungry.
The opposite question is why spend years paying for a product if, after you've purchased it, the developer has made the fair value from you?
Finally, not everyone who is being paid to write software _should_ be. Narrowing that field down wouldn't be a bad thing in all cases.
Doug's point is only key if you're a one trick pony with only one way to make a living, otherwise it's not a very important point.
I spent almost 5 years at an ISV (mostly as an assembly language programmer), and let me tell you- "product" code is nowhere near as lucrative as custom code, which would be cheaper if most of it was already built- but the fact that VB programmers make more than teachers isn't necessarily a good thing.
Look at the stock photographic industry and understand what happens if you've only got one skill and the market shifts to commoditize it and be full of talented ameatures who don't mind making a tiny ammount or no money producing as good or better material.
It's software, as it becomes more commoditized, it won't help pay many bills in and of itself.
Products and services help pay the bills, no matter what flavor they are. You can charge for the "product" that is software, or you can use it as a loss-leader. You can also do it as well, or better as a hobbiest than as a professional. That makes the software itself much less valuable, which isn't necessarily a bad thing, as that affordability makes it easier for people who need the software to have it.
FWIW: I do INFOSEC, so Windows helps pay my bills more than the Open Source OS' that I use to do my work every day. I'm not sure that's the positive thing that you seem to paint it as.
Paul
Re:This isnt a virus, a worm, or a trojan
on
New Linux Worm
·
· Score: 2
It is a worm. This is *exactly* that, it the larger of the two 1i0n packages gets executed on a machine, plants a bunch of trojans and goes searching for new machines which have port 53 open. If it finds them open, it exploits them to download the smaller 1i0n code which then leaves one backdoor (no trojans) and goes looking for machines that listen on port 53...
It does *not* appear to rootkit downstream infected machines, but it *does* move itself to other computers, which is what makes it a worm. Auto-exploit code is only a component of a worm if it automatically transfers itself to new machines. This code does that, therefore its a worm.
Replication if it infected "normal" programs would make it a virus, replication like this makes it a worm. Take away the self-replication and it's an exploit. All of these terms are well-defined, well-known and well-understood in the security and malcode communities.
In this case, the *worm* is the entire kit, and the exploit is a GLIBC 2.0 based executable called "bind" that's utilized by the worm to propogate via the TSIG overflow in BIND 8.2.x where x<3-REL.
"That system is left alone" is patently false in this case, since the downstream machine loads the smaller worm code and starts infecting machines of its own.
I dunno what you think a worm is, but the rest of
the community is sure that this is a worm. It's a boring worm, but it's definitely a worm.
Paul
Re:We don't need NSA's assistance
on
NSA Inside?
·
· Score: 2
(a) It's not my project, I just like it a lot.
(b) When I went looking for security, it took
two searches to find RSBAC
(c) It's been discussed on Linux Kernel a few
times.
(d) It's been announced on comp.os.linux.announce.
Collaboration at this stage wouldn't gain much- the security framework piece of RSBAC is in place, compartments, role-based computing, the privacy model, malcode detection, etc. is already in there. An entire new project to do the same thing is very counterproductive. We'll just fire up a project without seeing what's already out there doesn't sound that feasible to me, especially from people who would supposedly be hooked on Bell-LaPadula, and follow research in that area. Finally, the RSBAC guys presented at NISSC one year (1998) when the first module (Privacy) was done, and that's NSA's own security conference.
I'm not surprised that people who probably don't look for compartmented OSen by default haven't heard of RSBAC, I am surprised when an organization which spends significant money on such commercial systems ignores three or four years worth of significant work in that direction.
Paul
Re:rootness and capabilities
on
New Linux Worm
·
· Score: 2
The default Unix permissions model was designed for a specific purpose. It's worth pointing out that only a subset of IBM Mainframe OS' had the capabilities you describe- for instance, VM never had it. I've had RACF special and Class A-Z in VM, and I've run mainframes on everything from DOS (not the PC kind) up. Unix, originally designed for minicomputers, has grown to usage models well beyond it's original purpose, which is why some Unixes have added ACLs (some a number of years ago) and compartments and other security features (Trusted Solaris, CMW, etc.)
Not everyone needs those (unlike brakes on a car), and just like a manual transmission, not everyone can operate one, so for Linux it's optional.
Sorry if you're used to fast food, some of us enjoy ordering quality food item-by-item to get the best meal, not just the same old Happy Meal.
If you want it enough, you'll install it, if you don't, then you don't have to. If you want to wait for someone to create a turnkey distribution you can do that too. Just don't whine like a little baby that someone else isn't doing everything for you.
Actually, the quality bar has been set to "if it doesn't do it out of the box, generally someone's put a hell of a lot of work into doing it and is willing to share it and support it if you take one step in their direction." That's a hell of a lot better than "If it doesn't do it out of the box, wait until the vendor decides to release a bug-ridden version of it and if they don't want to, then you don't get that."
Hold your breath waiting for MAC-based compartments in WindowsANYTHING, or anything else that looks sufficiently B-level to provide strong security.
You might like bloated "it's all in there no matter if it's necessary or not" software systems, but they're not condusive to security and it's best when security-minded people build security critical pieces of them instead of OS-minded people, so patching for RSBAC works very well for those of us who care about security that deeply. It also makes the code easier to check when it's diffs instead of intermingled with the base kernel code.
If you buy a 2 seater sports car, don't expect it to be good at off-roading. The power of Linux is in the fact that I can get anything from RSBAC security to high-powered general purpose clusters and run the same code on them all.
If you need a silly little box around the software to make you happy, then you shouldn't be looking at Linux, it's not about inside the box.
Back on topic: RSBAC actually solves the "I don't want the administrator to be able to trojan this machine" problem as well as is possible on general purpose hardware (you can go download the international patches if you want to add another layer- or I suppose you could pay someone to do it since you seem to be allergic to actually installing software- must be hell when those new Reader Rabbit things come out!) The only other systems that come close cost tens of thousands of dollars and/or are obsolete.
Must have really pained you to choose which options you wanted on your car, or are you just walking until somone figures out how to have leather and cloth seats at the same time?
Paul
We don't need NSA's assistance
on
NSA Inside?
·
· Score: 3
The RSBAC project has had MAC compartments for well over a year- no US Government help required. It also supports role-based computing, the European Privacy Model, and is a framework for developing new security models.
http://www.rsbac.org/
RSBAC is already there, an NSA sponsored project doesn't seem to have much additional value to me- seems like they should spend my tax money on something that's not a "me too" project. Maybe they could help Verisign hand out certificates?;)
There isn't a definitive list, but there are around two dozen. The real problem with a list is that most AV companies are concerned about wild viruses, and worms, and so far that list is 2 long, ramen and 1i0n. I don't think the number of Outlook targeted things that are ITW, and most of those seem to be worms. This worm proves that bash is just as good as WSH for worms. If you look at the shell script stuff in 1i0n, you'll see that it's not all that impressive and pretty simple. Viral code seems to be a little trickier, but not majorly so compared to say Win32 viral code targeted at NT. What is difficult is getting traction with one, worms that exploit buffer overruns in common services seem to be the only things with a chance of gaining enough traction to beome a problem. Sooner or later that'll change, but for now it's enough to know that basic sysadmin skills should keep you safe.
Sorry, I read "that's" as "it's"- too much time disassembling:(
It is useful to note that we're getting more executable Win32 viruses now though (as opposed to scripts and macros- which are still pervasive but were pretty much all that was coming out for a while.) Our malcode guys have been predicting that for a while though. What worries me is the ELF file infector stuff. Thank goodness we haven't reached critical mass for Linux binaries yet, as there's still time to build in protection.
Paul
Re:This isnt a virus, a worm, or a trojan
on
New Linux Worm
·
· Score: 2
You're wrong. Viruses don't necessarily have to have malicious payloads to be viral, they simply have to infect files and spread themselves that way. Worms infect machines and spread themselves that way- once again no malicious payload required. After giving itself root access, it searches for *other machines* to exploit, and keeps doing that ad infinitum. That's what makes it a worm.
http://www.tuxedo.org/~esr/jargon/html/entry/wor m. html
As far as malicious code, it's actually pretty boring, there are at least two examples of the exploit the worm uses to propogate, but it's definitely a worm and it appears to be in the wild.
Paul
Re:rootness and capabilities
on
New Linux Worm
·
· Score: 2
Actually, mainframes didn't get those sorts of attributes until the 70's AIR, DOS on the 360 certainly didn't have per-job file attributes, since it was a batch system.
If you want compartmentalization, ACLs, a privacy model, malcode capabilities, etc., then go to http://www.rsbac.org, patch your kernel and stop bitching.
Default configuration: Make your own distribution or script to turn everything on the way you like it. Neither is very difficult, and fixing is more productive than bitching.
Back to the task at hand- RSBAC could have stopped this worm, it's about time it went into a development kernel.
Technically, ILOVEYOU could propogate through any user's misunderstanding of running executable content from the Internet. Technically, 1i0n only replicates if Linux system adminstrators haven't patched BIND since late January. Also, other than scan traffic, a large infected base doesn't hurt those who have done the right thing, unlike e-mail where a large infected base hurts everyone.
If you don't *HAVE* to run ftpd, *don't* run it. Most especially don't run wu-ftpd. FTP is a bad protocol and every implementation I can think of has had problems, some more than others. Use a reasonably up to date HTTP server, and access control it if you allow HTTP upload. Throw on SSL and client-side certificates if you want something stronger. If you *have* to run FTP, you need to be updating it every time there's a new release (just like BIND.) A lot of us gave up on sendmail a long time ago and went to more secure mailers, http://www.postfix.org or http://www.qmail.org will make your box really zing mail out and both were written to be secure from the start. Sendmail's been pretty stable for a while now though, so it's not the concern it used to be.
As far as alerts go for public-facing services, generally you're better off following when the vendor/project team has released an update rather than trying to follow the mishmash of alerts, posts and filter the useful info out.
Sorry, it would appear that it's not a trojan, quick analysis seems to indicate that the trojaned piece isn't replicated with each subsequent infection. It's a worm, with the wormy piece coming from an HTTP server in China during the BIND exploit phase (via lynx.)
FWIW: There are more and more real viruses happening in the Windows world now that Win32's better understood by the bad guys.
It would appear from a quick analysis that only the initial infection vector gets the rootkit. I've only gotten a bit of the way through the initial code, but it looks like the secondary infections all happen without the rootkit. I haven't run it yet to see for sure, but my current conjecture is that the huge blob of code is only used on the initial vector and the smaller bit is what gets replicated to each victim.
It's a combination of hardware, load and additional softare. These days it's *extremely* difficult to depend on a single motherboard being manufactured for more than 2 quarters, so I'm leary of anything that's hardware-finicky or driver related (having just had to try to track down some video and Ethernet chipset stuff, I'm particularly sensative to this at the moment.)
I've seen certified hardware with unescapable problems and random issues, though not as often as grab-bag stuff.
Bugs:
In the best environment, 2/3ds of bugs are known- while most won't have a direct security context, 1% of them would be pretty significant. I don't like at all the fact that Microsoft will release a product that they've no intention whatsoever of ever fixing/finishing. Instability has been a next release selling point for them, and that bothers me a lot, but mostly morally.
Some people like the idea of microkernels, I'm not convinced they have any real-world advantages, and side with Linus on that front. Given the APIs, I'm not sure that Win2k qualifies as "micro" anything;)
You should try Apache under NT, it's been threaded for what about 2 years now? The server is modular enough that if you spend some time with it, you can pare it down pretty significantly, and it handles named virtuals as well as anything.
ACLs are only a beginning. If you want to see how a secure OS is built (secure to the level of potentially being able to give out writable CGI directories and open shell accounts and not worry about compromise) check out http://www.rsbac.de. That's the major advantage of an Open Source OS, for a relatively miniscule sized chunk of code (not to belittle the effort, the effort was and is tremendous) RSBAC gives us role based stuff (No more superuser compromise), full ACLs, Mandatory Access Control, compartments, malware control, and the European Privacy Model. Better yet, it's not just an implementation, it's a framework for creating new security paradynes. It's securelevel taken to the next level. That's where small *secure* dedicated machines should spring from. Best of all, it's still able to run normal programs. The only thing it could really use is more socket-oriented stuff, but there's already enough to use and gain from significantly as a base for secure systems.
Don't even get me started about Exchange- you *can't* pare it down, SQL Server is monsterous- very secure doesn't come in packages that large without a lot of dedicated work that MS will never do because it's not profitable. Lovebug's spread had help from Exchange's architecture issues.
They've already got massive version control issues with the current Service Pack/Hotfix stuff adding more products would be a death knell for QA. Regression testing is probably their longest lag time to fix on critical issues and why SPs take so long to get out and can't have last-minute fixes incorporated.
Given the inroads Linux has made into the high side, it's inevitable that MS will have problems down the road getting the successor to Win2k adopted since Win2k is at least mostly-stable.
Personally, I don't think Embedded NT stands a chance against Linux/*BSD. But I've been wrong before. Twice;) I just don't think that 2k brings anything significant to the table to make it worth the embedded device premium- you've still got the same driver difficulty issues and none of the source to fix them. Hardware's getting cheaper- why spend those revenue dollars on driver development? That's why "embrace and extend" and MS-only features are necessary to them, they're not scaled to compete any other way at the low end where volume would devalue their mid-and high end stuff. That's also why they need desktop and server OS merging.
Back to real-world stuff- It's certainly possible to run real-world sites on NT, and we have no problem certifying our customers that do so once they've gotten through the essentials, but the level of dillagence for IIS is higher than that for Apache (mod_rewrite's last bug is the only significant security sensative Apache bug for a while now if you've configured conservatively.) Obviously because on-going reporting and testing are a part of our business, IIS is good for our model. Just like Word and the Macro Virus problem though, I personally think there are a lot of better choices that make more secure platforms. Beta was better than VHS though- and now the only Beta is the broadcast stuff, not consumer stuff (that wasn't one of the times I was wrong though, I went VHS all the way;) )
BTW: I was serious in the first post about trying the top few exploits against your IIS servers- the last time I saw someone do it on what seemed to be well-managed sites, the results were astounding.
If you don't connect a box to the Net, you can't send it data (I condsider anything connected to a box connected to the Net to be connected to the Net, so that's possibly symantics in a first vs. second order connection, but I think an important distinction.)
I'm curious as to why you'd poll the database looking for unencrypted data versus arbitrating all DB access through a data broker that ensured it? In either case, the Web server has to be able to request and obtain the clear data, and while stored procedures are obviously the way to go, I've been hard-pressed to come up with a way to rate-limit the server's access to critical data if the server needs it (obviously CC#'s aren't the type of data a Web server needs access to, and stored procedures and second servers for customer service reps. fill that need quite well.) Especially in the "hundreds of thousands to millions of customers" category where queries per second are sometimes hardware limited instead of DB limited.
I've also asked folks to implement middleware changes in the past that would disallow any wildcard query and alert like hell on them. That helps reduces worst-case exposure pretty significantly even though it's not a 100% ideal solution.
My point on the number of bugs was twofold- first of all, I think that it's indicitive of the legal climate that such realities could be aggressively tilted toward contributary negligence. Secondly, one of the things that we rely on in the security community is history. Historical exposure provides significant help in determining relative security. For instance, BIND, which I now refer to as the "Sendmail of the 90/00's" has historically been insecure. Choosing DNSCache is more than likely going to produce a more secure system. It obviously shouldn't be the sole criteria, but I think it's important to add historical context to any architecture design decision.
OS Zealotry has such a limited place in any technical discussion or plan that it's minor, no matter what side the zealot fall on, but number of bugs does indeed indicate quite a bit once you normalize the results somewhat.
I've found history and current bug severity and number to be accurate in chosing firewall vendors, and in choosing at what point a firewall vendor has changed development/QA processes enough to significantly impact functionality (it's a shame there's not a money-back critical bug metric in software contracts.) 32k bugs says one good and one bad thing. It says a lot for the QA process and a bad thing about the development/release process. But then I originally worked on mainframes where you got a couple hours of scheduled downtime a year if you were lucky and vendors who produced significant recurring bugs got thrown out on their asses quite quickly.
I'm pretty happy working to secure alomst anything, but there are a lot of choices that I wouldn't make to host data *I* personally was responsible for the security of (Irix springs immediately to mind in its non-trusted varient.)
You should pause and ask yourself what the catchy number of bugs says about the design and implementaton of Win2k. The reason for its slow adoption curve is because that spoke volumes to a lot of people. Granted only a portion of those bugs have a significant security context, but security is but one piece of the whole. Win2k is where NT should have started in regards to features and stability, and I've little personal patience for any vendor who wants me to pay for QA (MS certainly isn't the only vendor on my list, just the extreme case.)
In an ideal world, we'd have easy to use and administer compartmented systems. Compartmented systems fly in the face of Microsoft's productivity in producing OS', and I see that as a potential problem moving forward- we're only starting to see the tip of that iceberg now in process-based protection mechanisms failing with very recent MS products. As usual though, security is always about compromise and securing what you have instead of what you might want. In an ideal world, OS' are commoditized to a point where it doesn't really matter which one you use and you can pick secure ones for secure purposes. That however flys in direct competition with every commercial OS vendor. It'll be really interesting to see what IBM does with AIX. SGI actually gamed it out early, but it doesn't seem to be overly important that IRIX is basicly EOL'd as far as their sales go.
Ah well, if the world was the way I'd like it to be, I'd be looking for interesting work...
Encrypting data in a database that a server uses means that the server has to have the key. That lowers the value of the encryption. It also doesn't provide a good scale point- that doesn't mean it isn't a good thing, it means that it's not always a likely thing.
There's been ongoing debate in the INFOSEC community and computing community at-large about the culpability of a vendor who knowingly fields bad software (the 32,000 known Win2k bugs fly immediately to mind)- in the automotive industry a manufacturer who knowingly fielded an unsafe product on such a scale would be sued into the poorhouse. Bridgestone/Firestone probably unkowningly fielded unsafe tires, and if they'd not done the recall, Congress and/or the court system would have stepped in because of the fact that they knew after the fact that the adhesive wasn't good and didn't rush to pull out the products until they had to. It's only the computer field that really hasn't felt the pain of product liability- licenses notwithstanding it's bound to get a legal precedent sooner or later.
Like many others, I feel that eventually we'll see some manufacturer culpability, and I don't like the idea of it at all. I'm even more worried about its impact on free software. Though with freee software the potential is probably less because you can pick what you use and fix it if it doesn't meet expectations, with commercial closed-source, the vendor picks when it hits the market and how it functions.
The thing I have little tollerance at all for is the lack of responsibility being placed on the attacker. We should be vilifying the hell out of people who have the ultimate responsibility for producing badness and creating victims out of consumers irregardless of the culpability of either manufacturers, retailers, adminsitrators or anyone else in the chain. In a lot of states, if a motorist has a chance to avoid an accident and doesn't- regardless of their fault in creating the accident conditions, then they bear responsibility. We need to focus more on that responsibility on the behalf of attackers.
On the DB thing:
Typically, running the DB off the same box give you the problem that the entire database is on the same likely to be compromised machine. So are the keys to the database, and that means that it's significantly easier for an attacker to grab all the cookies and go home to eat them. Also, SQL Server is its own nightmare of twisty waiting-to-be-exploited passages (as is Oracle for anyone out bias-hunting.)
Since it's my quote, I'll defend against the FUD charge...
It's a fact that most reported Web Site compromises for Microsoft sites happen via IIS. It's also a fact that most of those are RDS. It's another fact that the last significantly visible break-in was reported as the Unicode../ bug.
The quote is definitely based on currently available information. It's also got a greater than 75% lieklyhood of being the true vector of attack. FWIW, we also called the Microsoft vector of attack correctly about two days before MS figured it out.
I challenge you to take the top 6 IIS exploits and run scans against your ~60 NT sites and report the results. If they're not all virtual servers, I'd bet you'll find at least 30% of them vulnerable to one form of attack or other.
Given the initial information circulating in the press and in the community, I blamed the attack on incompetent administration. While IIS has more holes per pound than Apache, it's trivial to make any Web server vulnerable, and I was careful to state that it didn't matter *what* server you were running (and Rob quoted that at the very end of the article- so it was obviously clear to him that my intent was to ensure that he understood that the likelyhood of the attack being due to poor administration was fairly high.)
If you design sites where the DB is on the same server as IIS, you'd better get down off that high horse, you bear some culpability for poor design practices.
Seriously, getting 10-20 minutes worth of interview into a few lines of quoted text, you always hope that the reporter will understand and report the gist of what you said.
The sad part is that over two years after it's been fixed, RDS is still the #1 attack vector for IIS. It's _really_ getting difficult to point to Microsoft as partially responsible for releasing crappy code when fixes that are eons old are never applied. If we could get wu-ftpd, sunrpc, RDS and the unicode../ bugs out, we'd at least raise the bar a couple notches.
If they licensed it under a BSD license, obviously they don't *want* any say in the matter.
It's an interesting solution to the entire Intellectual Property debate- BSD license advocates simply write software to write software without any pre-supposed downstream use issues.
The GPL creates software as politics, proprietary licenses create software as property, and BSD licenses create software as software.
For some things I think the GPL is a good thing on the whole, but to say that BSD-style licenses created a need for the GPL is silly. If everything where BSD-licensed, you'd have the same situation as if everything were GPL'd- it's the proprietary licenses that make the difference in either equation.
I find myself in agreement with DJB on something- we'd all be much better off without any software licenses at all.
1. The German government is helping to fund some important Open Source projects.
2. The USG's involved in Open Source already [For example, the Beowulf Project came out of NASA.]
3. You always have the source.
4. Stupid laws will come anyway- but I'd rather see more Beowulfish stuff than Windows-based ships being towed back to port.
5. My guess is that the single license would be applied to Government-funded projects. All in all, as long as they chose a BSD-style license it wouldn't matter one bit.
> I managed to get postfix to dump core a few
> times on the mandrake 7.1 that I'm runnng at
> home. Users should not be able to cause
> programs started as root to core dump.
a) How did you get it to dump core exactly.
b) Where's your bug report? Wieste's always been extremely good at fixing actual bugs.
c) Postfix drops root _very_ quickly for the parts of the system that need it. It's not monolithic and all the parts don't run as root.
I don't know *anyone* in the security community that I respect who'd run Sendmail under any circumstance that wasn't "We need a specific feature that nothing else supports" and even then it'd be on a gateway downstream of something else.
Slashdot Mirror
Hi Bruce [we met at Defcon last year]
This (All the other...) isn't totally true, there are Linux security vendors doing Open Source work, such as Enguarde and some promising things coming out of the RSBAC camp (Alt.Castle?)
Will there be a feature comparison to RSBAC (http://www.rsbac.de) and the NSA-sponsored stuff available anywhere soon?
Thanks,
Paul
X15, an experimental user-space server written to "compete" with Tux is faster:
h tml#3
http://kt.zork.net/kernel-traffic/kt20010507_117.
Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.
Apache is meant to have configurability over performance, and does dynamic content. However, I'm sure we'll see better performance from *nix based Web servers over time. Paul
It may be true of most people, however there are a lot of people writing a heck of a lot of code gratis. If *all* software were free (as in beer), not many companies would go out of business which weren't ISVs or Microsoft, or software consulting houses. If it were all required to be Open Source but not free very few at all would go out of business (companies like SuSe and RedHat open source all their software and they seem to be in business, so you see it's possible to do.)
The only externally used software I've written for my current employer was given away. Eventually software will reach the same stage of life as stock photography- almost all the pictures necessary are already taken- what will happen to your economics then?
Remember, unless you're playing, software isn't an end, it's a tool. If hammers were free, only the hammer makers and sellers would be impacted. The fact that there are very few commercial DNS server products on the market, for instance, doesn't mean people won't sell non-generic name service solutions or go hungry.
The opposite question is why spend years paying for a product if, after you've purchased it, the developer has made the fair value from you?
Finally, not everyone who is being paid to write software _should_ be. Narrowing that field down wouldn't be a bad thing in all cases.
Doug's point is only key if you're a one trick pony with only one way to make a living, otherwise it's not a very important point.
I spent almost 5 years at an ISV (mostly as an assembly language programmer), and let me tell you- "product" code is nowhere near as lucrative as custom code, which would be cheaper if most of it was already built- but the fact that VB programmers make more than teachers isn't necessarily a good thing.
Look at the stock photographic industry and understand what happens if you've only got one skill and the market shifts to commoditize it and be full of talented ameatures who don't mind making a tiny ammount or no money producing as good or better material.
Paul
> nor does it help pay the bills for many people.
It's software, as it becomes more commoditized, it won't help pay many bills in and of itself.
Products and services help pay the bills, no matter what flavor they are. You can charge for the "product" that is software, or you can use it as a loss-leader. You can also do it as well, or better as a hobbiest than as a professional. That makes the software itself much less valuable, which isn't necessarily a bad thing, as that affordability makes it easier for people who need the software to have it.
FWIW: I do INFOSEC, so Windows helps pay my bills more than the Open Source OS' that I use to do my work every day. I'm not sure that's the positive thing that you seem to paint it as.
Paul
It is a worm. This is *exactly* that, it the larger of the two 1i0n packages gets executed on a machine, plants a bunch of trojans and goes searching for new machines which have port 53 open. If it finds them open, it exploits them to download the smaller 1i0n code which then leaves one backdoor (no trojans) and goes looking for machines that listen on port 53...
It does *not* appear to rootkit downstream infected machines, but it *does* move itself to other computers, which is what makes it a worm. Auto-exploit code is only a component of a worm if it automatically transfers itself to new machines. This code does that, therefore its a worm.
Replication if it infected "normal" programs would make it a virus, replication like this makes it a worm. Take away the self-replication and it's an exploit. All of these terms are well-defined, well-known and well-understood in the security and malcode communities.
In this case, the *worm* is the entire kit, and the exploit is a GLIBC 2.0 based executable called "bind" that's utilized by the worm to propogate via the TSIG overflow in BIND 8.2.x where x<3-REL.
"That system is left alone" is patently false in this case, since the downstream machine loads the smaller worm code and starts infecting machines of its own.
I dunno what you think a worm is, but the rest of
the community is sure that this is a worm. It's a boring worm, but it's definitely a worm.
Paul
(a) It's not my project, I just like it a lot.
(b) When I went looking for security, it took
two searches to find RSBAC
(c) It's been discussed on Linux Kernel a few
times.
(d) It's been announced on comp.os.linux.announce.
Collaboration at this stage wouldn't gain much- the security framework piece of RSBAC is in place, compartments, role-based computing, the privacy model, malcode detection, etc. is already in there. An entire new project to do the same thing is very counterproductive. We'll just fire up a project without seeing what's already out there doesn't sound that feasible to me, especially from people who would supposedly be hooked on Bell-LaPadula, and follow research in that area. Finally, the RSBAC guys presented at NISSC one year (1998) when the first module (Privacy) was done, and that's NSA's own security conference.
I'm not surprised that people who probably don't look for compartmented OSen by default haven't heard of RSBAC, I am surprised when an organization which spends significant money on such commercial systems ignores three or four years worth of significant work in that direction.
Paul
The default Unix permissions model was designed for a specific purpose. It's worth pointing out that only a subset of IBM Mainframe OS' had the capabilities you describe- for instance, VM never had it. I've had RACF special and Class A-Z in VM, and I've run mainframes on everything from DOS (not the PC kind) up. Unix, originally designed for minicomputers, has grown to usage models well beyond it's original purpose, which is why some Unixes have added ACLs (some a number of years ago) and compartments and other security features (Trusted Solaris, CMW, etc.)
Not everyone needs those (unlike brakes on a car), and just like a manual transmission, not everyone can operate one, so for Linux it's optional.
Sorry if you're used to fast food, some of us enjoy ordering quality food item-by-item to get the best meal, not just the same old Happy Meal.
If you want it enough, you'll install it, if you don't, then you don't have to. If you want to wait for someone to create a turnkey distribution you can do that too. Just don't whine like a little baby that someone else isn't doing everything for you.
Actually, the quality bar has been set to "if it doesn't do it out of the box, generally someone's put a hell of a lot of work into doing it and is willing to share it and support it if you take one step in their direction." That's a hell of a lot better than "If it doesn't do it out of the box, wait until the vendor decides to release a bug-ridden version of it and if they don't want to, then you don't get that."
Hold your breath waiting for MAC-based compartments in WindowsANYTHING, or anything else that looks sufficiently B-level to provide strong security.
You might like bloated "it's all in there no matter if it's necessary or not" software systems, but they're not condusive to security and it's best when security-minded people build security critical pieces of them instead of OS-minded people, so patching for RSBAC works very well for those of us who care about security that deeply. It also makes the code easier to check when it's diffs instead of intermingled with the base kernel code.
If you buy a 2 seater sports car, don't expect it to be good at off-roading. The power of Linux is in the fact that I can get anything from RSBAC security to high-powered general purpose clusters and run the same code on them all.
If you need a silly little box around the software to make you happy, then you shouldn't be looking at Linux, it's not about inside the box.
Back on topic: RSBAC actually solves the "I don't want the administrator to be able to trojan this machine" problem as well as is possible on general purpose hardware (you can go download the international patches if you want to add another layer- or I suppose you could pay someone to do it since you seem to be allergic to actually installing software- must be hell when those new Reader Rabbit things come out!) The only other systems that come close cost tens of thousands of dollars and/or are obsolete.
Must have really pained you to choose which options you wanted on your car, or are you just walking until somone figures out how to have leather and cloth seats at the same time?
Paul
The RSBAC project has had MAC compartments for well over a year- no US Government help required. It also supports role-based computing, the European Privacy Model, and is a framework for developing new security models.
;)
http://www.rsbac.org/
RSBAC is already there, an NSA sponsored project doesn't seem to have much additional value to me- seems like they should spend my tax money on something that's not a "me too" project. Maybe they could help Verisign hand out certificates?
Paul
There isn't a definitive list, but there are around two dozen. The real problem with a list is that most AV companies are concerned about wild viruses, and worms, and so far that list is 2 long, ramen and 1i0n. I don't think the number of Outlook targeted things that are ITW, and most of those seem to be worms. This worm proves that bash is just as good as WSH for worms. If you look at the shell script stuff in 1i0n, you'll see that it's not all that impressive and pretty simple. Viral code seems to be a little trickier, but not majorly so compared to say Win32 viral code targeted at NT. What is difficult is getting traction with one, worms that exploit buffer overruns in common services seem to be the only things with a chance of gaining enough traction to beome a problem. Sooner or later that'll change, but for now it's enough to know that basic sysadmin skills should keep you safe.
Paul
Sorry, I read "that's" as "it's"- too much time disassembling :(
It is useful to note that we're getting more executable Win32 viruses now though (as opposed to scripts and macros- which are still pervasive but were pretty much all that was coming out for a while.) Our malcode guys have been predicting that for a while though. What worries me is the ELF file infector stuff. Thank goodness we haven't reached critical mass for Linux binaries yet, as there's still time to build in protection.
Paul
You're wrong. Viruses don't necessarily have to have malicious payloads to be viral, they simply have to infect files and spread themselves that way. Worms infect machines and spread themselves that way- once again no malicious payload required. After giving itself root access, it searches for *other machines* to exploit, and keeps doing that ad infinitum. That's what makes it a worm.
r m. html
r us .html
http://www.tuxedo.org/~esr/jargon/html/entry/wo
http://www.tuxedo.org/~esr/jargon/html/entry/vi
As far as malicious code, it's actually pretty boring, there are at least two examples of the exploit the worm uses to propogate, but it's definitely a worm and it appears to be in the wild.
Paul
Actually, mainframes didn't get those sorts of attributes until the 70's AIR, DOS on the 360 certainly didn't have per-job file attributes, since it was a batch system.
If you want compartmentalization, ACLs, a privacy model, malcode capabilities, etc., then go to http://www.rsbac.org, patch your kernel and stop bitching.
Default configuration: Make your own distribution or script to turn everything on the way you like it. Neither is very difficult, and fixing is more productive than bitching.
Back to the task at hand- RSBAC could have stopped this worm, it's about time it went into a development kernel.
Paul
Technically, ILOVEYOU could propogate through any user's misunderstanding of running executable content from the Internet. Technically, 1i0n only replicates if Linux system adminstrators haven't patched BIND since late January. Also, other than scan traffic, a large infected base doesn't hurt those who have done the right thing, unlike e-mail where a large infected base hurts everyone.
Paul
If you don't *HAVE* to run ftpd, *don't* run it. Most especially don't run wu-ftpd. FTP is a bad protocol and every implementation I can think of has had problems, some more than others. Use a reasonably up to date HTTP server, and access control it if you allow HTTP upload. Throw on SSL and client-side certificates if you want something stronger. If you *have* to run FTP, you need to be updating it every time there's a new release (just like BIND.) A lot of us gave up on sendmail a long time ago and went to more secure mailers, http://www.postfix.org or http://www.qmail.org will make your box really zing mail out and both were written to be secure from the start. Sendmail's been pretty stable for a while now though, so it's not the concern it used to be.
As far as alerts go for public-facing services, generally you're better off following when the vendor/project team has released an update rather than trying to follow the mishmash of alerts, posts and filter the useful info out.
Paul
Sorry, it would appear that it's not a trojan, quick analysis seems to indicate that the trojaned piece isn't replicated with each subsequent infection. It's a worm, with the wormy piece coming from an HTTP server in China during the BIND exploit phase (via lynx.)
FWIW: There are more and more real viruses happening in the Windows world now that Win32's better understood by the bad guys.
Paul
It would appear from a quick analysis that only the initial infection vector gets the rootkit. I've only gotten a bit of the way through the initial code, but it looks like the secondary infections all happen without the rootkit. I haven't run it yet to see for sure, but my current conjecture is that the huge blob of code is only used on the initial vector and the smaller bit is what gets replicated to each victim.
Paul
The traffic you saw was likely the scanner portion looking for new victims. It randomly scans "class B" address blocks looking for new targets.
Paul
[We can take this to e-mail if you'd like]
;)
;) I just don't think that 2k brings anything significant to the table to make it worth the embedded device premium- you've still got the same driver difficulty issues and none of the source to fix them. Hardware's getting cheaper- why spend those revenue dollars on driver development? That's why "embrace and extend" and MS-only features are necessary to them, they're not scaled to compete any other way at the low end where volume would devalue their mid-and high end stuff. That's also why they need desktop and server OS merging.
;) )
NT4 Stability:
It's a combination of hardware, load and additional softare. These days it's *extremely* difficult to depend on a single motherboard being manufactured for more than 2 quarters, so I'm leary of anything that's hardware-finicky or driver related (having just had to try to track down some video and Ethernet chipset stuff, I'm particularly sensative to this at the moment.)
I've seen certified hardware with unescapable problems and random issues, though not as often as grab-bag stuff.
Bugs:
In the best environment, 2/3ds of bugs are known- while most won't have a direct security context, 1% of them would be pretty significant. I don't like at all the fact that Microsoft will release a product that they've no intention whatsoever of ever fixing/finishing. Instability has been a next release selling point for them, and that bothers me a lot, but mostly morally.
Some people like the idea of microkernels, I'm not convinced they have any real-world advantages, and side with Linus on that front. Given the APIs, I'm not sure that Win2k qualifies as "micro" anything
You should try Apache under NT, it's been threaded for what about 2 years now? The server is modular enough that if you spend some time with it, you can pare it down pretty significantly, and it handles named virtuals as well as anything.
ACLs are only a beginning. If you want to see how a secure OS is built (secure to the level of potentially being able to give out writable CGI directories and open shell accounts and not worry about compromise) check out http://www.rsbac.de. That's the major advantage of an Open Source OS, for a relatively miniscule sized chunk of code (not to belittle the effort, the effort was and is tremendous) RSBAC gives us role based stuff (No more superuser compromise), full ACLs, Mandatory Access Control, compartments, malware control, and the European Privacy Model. Better yet, it's not just an implementation, it's a framework for creating new security paradynes. It's securelevel taken to the next level. That's where small *secure* dedicated machines should spring from. Best of all, it's still able to run normal programs. The only thing it could really use is more socket-oriented stuff, but there's already enough to use and gain from significantly as a base for secure systems.
Don't even get me started about Exchange- you *can't* pare it down, SQL Server is monsterous- very secure doesn't come in packages that large without a lot of dedicated work that MS will never do because it's not profitable. Lovebug's spread had help from Exchange's architecture issues.
They've already got massive version control issues with the current Service Pack/Hotfix stuff adding more products would be a death knell for QA. Regression testing is probably their longest lag time to fix on critical issues and why SPs take so long to get out and can't have last-minute fixes incorporated.
Given the inroads Linux has made into the high side, it's inevitable that MS will have problems down the road getting the successor to Win2k adopted since Win2k is at least mostly-stable.
Personally, I don't think Embedded NT stands a chance against Linux/*BSD. But I've been wrong before. Twice
Back to real-world stuff- It's certainly possible to run real-world sites on NT, and we have no problem certifying our customers that do so once they've gotten through the essentials, but the level of dillagence for IIS is higher than that for Apache (mod_rewrite's last bug is the only significant security sensative Apache bug for a while now if you've configured conservatively.) Obviously because on-going reporting and testing are a part of our business, IIS is good for our model. Just like Word and the Macro Virus problem though, I personally think there are a lot of better choices that make more secure platforms. Beta was better than VHS though- and now the only Beta is the broadcast stuff, not consumer stuff (that wasn't one of the times I was wrong though, I went VHS all the way
BTW: I was serious in the first post about trying the top few exploits against your IIS servers- the last time I saw someone do it on what seemed to be well-managed sites, the results were astounding.
Best wishes,
Paul
If you don't connect a box to the Net, you can't send it data (I condsider anything connected to a box connected to the Net to be connected to the Net, so that's possibly symantics in a first vs. second order connection, but I think an important distinction.)
I'm curious as to why you'd poll the database looking for unencrypted data versus arbitrating all DB access through a data broker that ensured it? In either case, the Web server has to be able to request and obtain the clear data, and while stored procedures are obviously the way to go, I've been hard-pressed to come up with a way to rate-limit the server's access to critical data if the server needs it (obviously CC#'s aren't the type of data a Web server needs access to, and stored procedures and second servers for customer service reps. fill that need quite well.) Especially in the "hundreds of thousands to millions of customers" category where queries per second are sometimes hardware limited instead of DB limited.
I've also asked folks to implement middleware changes in the past that would disallow any wildcard query and alert like hell on them. That helps reduces worst-case exposure pretty significantly even though it's not a 100% ideal solution.
My point on the number of bugs was twofold- first of all, I think that it's indicitive of the legal climate that such realities could be aggressively tilted toward contributary negligence. Secondly, one of the things that we rely on in the security community is history. Historical exposure provides significant help in determining relative security. For instance, BIND, which I now refer to as the "Sendmail of the 90/00's" has historically been insecure. Choosing DNSCache is more than likely going to produce a more secure system. It obviously shouldn't be the sole criteria, but I think it's important to add historical context to any architecture design decision.
OS Zealotry has such a limited place in any technical discussion or plan that it's minor, no matter what side the zealot fall on, but number of bugs does indeed indicate quite a bit once you normalize the results somewhat.
I've found history and current bug severity and number to be accurate in chosing firewall vendors, and in choosing at what point a firewall vendor has changed development/QA processes enough to significantly impact functionality (it's a shame there's not a money-back critical bug metric in software contracts.) 32k bugs says one good and one bad thing. It says a lot for the QA process and a bad thing about the development/release process. But then I originally worked on mainframes where you got a couple hours of scheduled downtime a year if you were lucky and vendors who produced significant recurring bugs got thrown out on their asses quite quickly.
I'm pretty happy working to secure alomst anything, but there are a lot of choices that I wouldn't make to host data *I* personally was responsible for the security of (Irix springs immediately to mind in its non-trusted varient.)
You should pause and ask yourself what the catchy number of bugs says about the design and implementaton of Win2k. The reason for its slow adoption curve is because that spoke volumes to a lot of people. Granted only a portion of those bugs have a significant security context, but security is but one piece of the whole. Win2k is where NT should have started in regards to features and stability, and I've little personal patience for any vendor who wants me to pay for QA (MS certainly isn't the only vendor on my list, just the extreme case.)
In an ideal world, we'd have easy to use and administer compartmented systems. Compartmented systems fly in the face of Microsoft's productivity in producing OS', and I see that as a potential problem moving forward- we're only starting to see the tip of that iceberg now in process-based protection mechanisms failing with very recent MS products. As usual though, security is always about compromise and securing what you have instead of what you might want. In an ideal world, OS' are commoditized to a point where it doesn't really matter which one you use and you can pick secure ones for secure purposes. That however flys in direct competition with every commercial OS vendor. It'll be really interesting to see what IBM does with AIX. SGI actually gamed it out early, but it doesn't seem to be overly important that IRIX is basicly EOL'd as far as their sales go.
Ah well, if the world was the way I'd like it to be, I'd be looking for interesting work...
Happy Holidays,
Paul
Encrypting data in a database that a server uses means that the server has to have the key. That lowers the value of the encryption. It also doesn't provide a good scale point- that doesn't mean it isn't a good thing, it means that it's not always a likely thing.
There's been ongoing debate in the INFOSEC community and computing community at-large about the culpability of a vendor who knowingly fields bad software (the 32,000 known Win2k bugs fly immediately to mind)- in the automotive industry a manufacturer who knowingly fielded an unsafe product on such a scale would be sued into the poorhouse. Bridgestone/Firestone probably unkowningly fielded unsafe tires, and if they'd not done the recall, Congress and/or the court system would have stepped in because of the fact that they knew after the fact that the adhesive wasn't good and didn't rush to pull out the products until they had to. It's only the computer field that really hasn't felt the pain of product liability- licenses notwithstanding it's bound to get a legal precedent sooner or later.
Like many others, I feel that eventually we'll see some manufacturer culpability, and I don't like the idea of it at all. I'm even more worried about its impact on free software. Though with freee software the potential is probably less because you can pick what you use and fix it if it doesn't meet expectations, with commercial closed-source, the vendor picks when it hits the market and how it functions.
The thing I have little tollerance at all for is the lack of responsibility being placed on the attacker. We should be vilifying the hell out of people who have the ultimate responsibility for producing badness and creating victims out of consumers irregardless of the culpability of either manufacturers, retailers, adminsitrators or anyone else in the chain. In a lot of states, if a motorist has a chance to avoid an accident and doesn't- regardless of their fault in creating the accident conditions, then they bear responsibility. We need to focus more on that responsibility on the behalf of attackers.
On the DB thing:
Typically, running the DB off the same box give you the problem that the entire database is on the same likely to be compromised machine. So are the keys to the database, and that means that it's significantly easier for an attacker to grab all the cookies and go home to eat them. Also, SQL Server is its own nightmare of twisty waiting-to-be-exploited passages (as is Oracle for anyone out bias-hunting.)
Happy Holidays,
Paul
Since it's my quote, I'll defend against the FUD charge...
../ bug.
It's a fact that most reported Web Site compromises for Microsoft sites happen via IIS. It's also a fact that most of those are RDS. It's another fact that the last significantly visible break-in was reported as the Unicode
The quote is definitely based on currently available information. It's also got a greater than 75% lieklyhood of being the true vector of attack. FWIW, we also called the Microsoft vector of attack correctly about two days before MS figured it out.
I challenge you to take the top 6 IIS exploits and run scans against your ~60 NT sites and report the results. If they're not all virtual servers, I'd bet you'll find at least 30% of them vulnerable to one form of attack or other.
Given the initial information circulating in the press and in the community, I blamed the attack on incompetent administration. While IIS has more holes per pound than Apache, it's trivial to make any Web server vulnerable, and I was careful to state that it didn't matter *what* server you were running (and Rob quoted that at the very end of the article- so it was obviously clear to him that my intent was to ensure that he understood that the likelyhood of the attack being due to poor administration was fairly high.)
If you design sites where the DB is on the same server as IIS, you'd better get down off that high horse, you bear some culpability for poor design practices.
Paul
Me either! ;)
../ bugs out, we'd at least raise the bar a couple notches.
Seriously, getting 10-20 minutes worth of interview into a few lines of quoted text, you always hope that the reporter will understand and report the gist of what you said.
The sad part is that over two years after it's been fixed, RDS is still the #1 attack vector for IIS. It's _really_ getting difficult to point to Microsoft as partially responsible for releasing crappy code when fixes that are eons old are never applied. If we could get wu-ftpd, sunrpc, RDS and the unicode
Paul
If they licensed it under a BSD license, obviously they don't *want* any say in the matter.
It's an interesting solution to the entire Intellectual Property debate- BSD license advocates simply write software to write software without any pre-supposed downstream use issues.
The GPL creates software as politics, proprietary licenses create software as property, and BSD licenses create software as software.
For some things I think the GPL is a good thing on the whole, but to say that BSD-style licenses created a need for the GPL is silly. If everything where BSD-licensed, you'd have the same situation as if everything were GPL'd- it's the proprietary licenses that make the difference in either equation.
I find myself in agreement with DJB on something- we'd all be much better off without any software licenses at all.
Paul
1. The German government is helping to fund some important Open Source projects.
2. The USG's involved in Open Source already [For example, the Beowulf Project came out of NASA.]
3. You always have the source.
4. Stupid laws will come anyway- but I'd rather see more Beowulfish stuff than Windows-based ships being towed back to port.
5. My guess is that the single license would be applied to Government-funded projects. All in all, as long as they chose a BSD-style license it wouldn't matter one bit.
Paul
> I managed to get postfix to dump core a few
> times on the mandrake 7.1 that I'm runnng at
> home. Users should not be able to cause
> programs started as root to core dump.
a) How did you get it to dump core exactly.
b) Where's your bug report? Wieste's always been extremely good at fixing actual bugs.
c) Postfix drops root _very_ quickly for the parts of the system that need it. It's not monolithic and all the parts don't run as root.
I don't know *anyone* in the security community that I respect who'd run Sendmail under any circumstance that wasn't "We need a specific feature that nothing else supports" and even then it'd be on a gateway downstream of something else.
Paul