Weekly Edition
Return to the Front page
| |||||||||||||
|
| |||||||||||||
Monocultures and software security
A vulnerability which allows a cracker to break into a computer is, in
general, a bad news. But a vulnerability which exposes a large percentage
of the entire network can be catastrophic. There will come a day when a
truly malicious individual or group finds a hole first and makes use of it
to trash as many machines as possible; how can one, reading the headlines,
doubt that claim? We have been lucky that it has not happened yet.
When that time comes, our biggest problem will be the "monocultural" aspect of much of the software landscape. If everybody is running the same software, it only takes a single vulnerability to expose all systems. Unfortunately, that is exactly the situation we find ourselves in with a number of security-critical applications. Consider Apache, OpenSSH, Bind, and Sendmail for starters. Each accounts for well over half the installed systems in its class. A vulnerability in any of these programs puts a large portion of the net at risk. Of course, it is easy to point out that this situation is going to bite us. It is harder to suggest things to be done about it. The free software community produces a great diversity of products. There are, seemingly, almost as many editors available as users to run them. We have multiple desktops, numerous mail clients, a wealth of scripting languages, etc. But the core infrastructural components tend to narrow down to a small number of choices. We have many shells, but only one secure shell protocol and implementation worthy of note. When a free infrastructure component achieve dominance, it seems a waste of time to work on (or use) a competitor. That is a perception that, perhaps, needs to change. If we can improve the diversity of our network ecosystem, we will all be better off as a result. A wide choice of distributions (and operating systems), along with multiple machine architectures, is a good start; exploits tend to be specific to a particular distribution and processor. But we really need a wealth of choices for the individual software components as well. In some areas (i.e. mail transfer agents) that range of choices exists now. But in others it does not: where are the viable, free alternatives to OpenSSH and Bind? We will all be better off when popular alternatives to those programs emerge - even if we do not run them ourselves. (Log in to post comments)
Monocultures and software security Posted Oct 17, 2002 3:38 UTC (Thu) by smoogen (subscriber, #97) [Link] I think that we have to just accept that monocultures are a part of the game of code reuse. We extol the re-use of code because it allows us to work on bigger problems without having to re-invent the wheel one more time.We just have to come up with methods to deal with security problems more effectively. Having us come up with 30 different versions of apache from the ground up is actually the worst thing we could do because it produces a different kind of holy war. While apache, openssh, and other applications are prevalent major applications, there are also large parts of code that either get re-used verbatim or re-used by design. Look at how many packages had to be replaced because of the problem in the RPC XDR code. This affected several of packages that had grabbed the source, or had implemented identical like functions. In the end, I think the problem isnt monocultures as much as poor engineering techniques. We dont expect our cars to be safer because their are 40 brands of them. We expect them to be safer because engineers did the hard work of tearing them apart.
Monocultures and software security Posted Oct 25, 2002 8:08 UTC (Fri) by wolfrider (guest, #3105) [Link] It would be nice if somebody would develop a C compiler or profiler that AUTOMATICALLY checks for buffer overflows on every compile! That seems to be the #1 "gotcha" these days as far as security updates go.
The 80/20/5 law Posted Oct 17, 2002 4:44 UTC (Thu) by raph (guest, #326) [Link] Just about every competitive landscape has something like an 80/20/5 rule, in which the top 3 competitors grab about 95% of the landscape. I don't see any reason for things to be different with free software. For some discussion of why this "law" applies, see "Linked", by Albert-Laszlo Barabasi. It's a power-law distribution.Of course, what you didn't mention is that the Microsoft world is far more monocultural than the free software world. A great deal of mail and Web runs on MS servers, for whatever that's worth. I expect security to get better very slowly. An exciting old technology is provably-correct software (an assertion that won't be surprising for those following my recent diary). In the meantime, probably the biggest win is to deploy software and configurations as simple as needed, something far more difficult to do in the feature-laden world of proprietary software.
Alternative to bind Posted Oct 17, 2002 5:50 UTC (Thu) by anr (subscriber, #234) [Link] djbdns is a very good alternative to bind. Is the license a problem? There could be a whole article discussing this issue. I certainly find djbware very reliable and secure, and use it a lot. I am glad it's available, and I think LWN should at least mention it as an option.
Alternative to bind Posted Oct 17, 2002 14:25 UTC (Thu) by corbet (editor, #1) [Link] See this article from 2001 - we've not ignored DJB's stuff. Hey we even run qmail (though, if I had it to do over again, I'l likely pick postfix instead). But in this article I made the distinction of free alternatives; it makes a big difference for a lot of people.
Another Alternative to bind Posted Oct 26, 2002 9:27 UTC (Sat) by sam (guest, #1329) [Link] OK, shameless plug time. MaraDNS, which is my attempt to make a non-BIND DNS server which has been extensively tested and is stable. Unlike any other non-BIND DNS server with an open-source compatible license, MaraDNS is currently both an authoritative and recursive DNS server.MaraDNS has the same security history as BIND 9: Some minor denial of service issues have been found, but there has not been found anything which could give an attacker elevated privledges. MaraDNS has a good security design; it does not have the usual buffer overflows and string format attacks which plague other software. The only issues that people may have with MaraDNS are:
Monocultures and software security Posted Oct 17, 2002 6:47 UTC (Thu) by Peter (guest, #1127) [Link] Who was it, Mark Twain? "Put all your eggs in one basket - and watch that basket." Whoever it was, there is something to be said for the OpenSSH approach. Not only do we have perhaps the world's foremost security auditing experts working on it, but now, with things like privilege separation, I actually think OpenSSH is getting more secure over time - the opposite trend, unfortunately, from most software. Sure, there have been a couple recent holes, but these were a result of active auditing by the maintainers themselves - so I expect such "surprises" to be rare in the future. As for MTAs, lots of people run Postfix and Exim (and of course qmail and Exchange, in the less-free category), so while Sendmail is the default choice for old-school Unix, I think it will continue to decline over time (market-share-wise, of course). Bind? Well, the world is at least split between v8 and v9 (with a few stalwarts hanging on to v4.9). Bind 9 was a complete rewrite, so I think this counts as two products, for security vulnerability purposes. Likewise with Apache 1.3 vs 2.0. All I'm saying is, perhaps our installed base is a little more diverse than it looks. (:
Monocultures and software security Posted Oct 18, 2002 10:37 UTC (Fri) by tres (guest, #352) [Link] The put all your eggs in one basket and watch it philosophy has a problem with it as well. Remeber Perl Harbor? At the time the biggest threat was considered sabotage so our military assets were "put in one basket and watched", or in other words airplanes and ships were closely grouped together so that they could be gaurded from people wanting to sabotage them. By the time we realized that we were protecting them from the wrong threat all we were able to do was watch the entire basket burn.I think the point that Mr. Corbet is trying to make is that we need to have a few baskets and watch them all, even if we cannot watch them all as efficiently as we could watch one. Regards,
OT: Perl Harbour Posted Oct 18, 2002 15:03 UTC (Fri) by X-Nc (guest, #1661) [Link] There is an interesting point of trivia about this...Did you know that all of the Aircraft Carriers were out wandering the Atlantic during the attack? There's been some speculation that the carriers were ordered out, without their supporting floatilla, because the War Department had evidence the attack was coming and wanted to use it as a reason to join the war. Why keep the carriers out? Historians will tell you that they were one of the most importent and powerfull peices of combat weapons. No carriers? The US does not win the war in the Pasific. Ok, enough useless trivia rambling... I'm home sick today and not feeling up to being productive at all.
OT: Perl Harbour Posted Oct 25, 2002 12:45 UTC (Fri) by Wol (guest, #4433) [Link] The other not-so-trivial nugget is that the Navy High Command thought that carriers were useless - pretty obvious from their behaviour, and typical psychology too - many of them learnt their trade in the days when aircraft were new ...So the carriers just happened not to be there - and as several people have said, "At one stroke, Japan converted America's fleet from a 28-knot fleet to a 33-knot fleet" - and paid the price. It was only at Midway, 6 months later, when the carriers defeated Japan's fleet in a pitched battle while the big battleships never even fired their guns, that the American High Command really began to appreciate the value of the carrier. We had a similar problem our side of the pond. We lost THOUSANDS of men and aircraft ploughing German fields, when if only we'd used a small fraction of that force providing air escorts for our convoys, we'd have lost far fewer ships. If you count losses on the fingers of hands, how many people do you need to count ships lost while they had an air escort? TWO!!! Cheers,
Monocultures and software security Posted Oct 17, 2002 10:57 UTC (Thu) by evgeny (guest, #774) [Link] > There are, seemingly, almost as many editors available as users to run them.1. Because they are "compatible" - you can open the same file in any text editor and can see the same contents. So it takes no time to _try_ a new one, therfore the chances are high each user selects what suits him best. Situation with MTA, HTTP servers etc is much more complicated. Eventhough, say, sendmail, postfix, and qmail share at least 95% of functionality (and these 95% cover 99.9% of existing installations), the configuration of that 95% differs drastically from one to one. Syntax of configuration files, names of parameters,.. - all is different. When it comes to plugins - ABI and even API are different - but why? why can konqueror and mozilla use the same plugins but apache and e.g. aolserver can't? 2. About everyone has tried a dozen editors (and from time to time, gives a try to a new one), but how many sysadmins can you count who actually tried several MTAs in real-life configurations? And it's undesrtandable. A wrong choice of editor in the worst (and extremely rare) case means a corrupted text file. A wrong choice (read - misconfiguration) of MTA means emails disappearing, angry users and managers, etc etc - and all that after many hours of installation/reading manuals/configuration/... Clearly, people use either the MTA they've been working with last years or whatever comes by default with their distribution, and switch to a different one only when there is an ultimate need. IMHO, monocultures can _improve_ security, but monocultures here are meant in the sense of foundation stuff like mature configuration, string handling etc libraries. A major part of security holes are due to wrong memory (usually text string) handling - which is a simple reflection of the fact that the relevant part of the libc API is light years back and completely inadequate. Same regarding configuration - a lot of code in a lot of projects is just for basic config file parsing, meaning, as a result, many hours of duplicate work and NO compatibility. I dream about a well designed and implemented equivalent of AD/Registry. Well, this is a separate topic...
Monocultures and software security Posted Oct 18, 2002 10:58 UTC (Fri) by tres (guest, #352) [Link] Hopefully something like XML will standardize both the config files and the code that parses them.
Monocultures and software security Posted Oct 24, 2002 19:26 UTC (Thu) by scripter (subscriber, #2654) [Link] XML is not the be-all, end-all solution to our file format compatibility problems.From http://weblog.burningbird.net/archives/000581.php regarding XML: "I'm considered the savior, the ultimate solution, the final word. Odes are written to me, flowers strewn at my feet, virgins sacrificed at my altar. "Programmers speak my name with awe. Companies insist on using me in all their projects, though they're not sure why. "And whenever a problem occurs, someone somewhere says, "Let's use XML", and miracles occur and my very name has become a talisman against evil. "And yet, all I am is a simple little markup, from humble origins. It's a burden, being XML."
Monocultures and software security Posted Oct 17, 2002 12:42 UTC (Thu) by brugolsky (✭ supporter ✭, #28) [Link] I have to agree with many of the folks here -- the benefits of code reuse weigh heavily in favor of monocultures. We simply need to write better code in languages that have safer primitives (since most exploits these days rely on buffer overflows or arithmetic overflows). Also, security *policy* can differ from system to system, even if the code is the same. E.g., deploying SELinux provides layered defense, but it complicates things considerably. Security is difficult, and when it comes to core infrastructure, there is no alternative to relying on professionals to configure and manage complex systems correctly.Also, with a layered defense, if there is a security breach, there is usually some layer at which the breach can be halted quickly (e.g., iptables), while a longer-term solution is found (fix the bug in the application).
Monocultures and software security Posted Oct 17, 2002 17:22 UTC (Thu) by strombrg (guest, #2178) [Link] It's not like lsh is unusable, right? And I believe it's GPL'd.
Monocultures and software security Posted Oct 17, 2002 19:58 UTC (Thu) by cdmiller (subscriber, #2813) [Link] Stability comes first. The most stable, mature products will always garner the most use. Given that, as long as there is choice, monoculture in free or open source software will never take a firm or lasting grip. Even Linux itself, (the kernel), is up for grabs for full replacement or endless customization.Some examples: As mentioned Sendmail, Postfix, Qmail, Exim... I have replaced Sendmail with Qmail everywhere I worked. I assume others are doing the same with their favorites, even tweaking and upgrading Sendmail itself counts as some difference where monoculture vulnerabilities are concerned. Openssh, Lsh, SSL, SEP, Kerberose capable telnet and ftp clients are all in use. Openssh is often run in differing configurations. Apache competes with tons of other web servers. Apache is run in different custom configurations, not just default pre packaged Linux distro flavors. One persons Apache config may be vulnerable while anothers is not. Djbdns is actively in use, other name servers will appear eventually. Lots of folks who actually run Bind do so in fairly safe ways, (chrooted etc.) Some Linux distros even recompile their entire code base with tools like Stackguard. Free software monoculture? I think not, and that's by design.
Monocultures and software security Posted Oct 24, 2002 6:40 UTC (Thu) by rickmoen (subscriber, #6943) [Link] Excellent question. Free/open-source alternatives to OpenSSH (that implement the SSH protocols):
Free/open-source alternatives to BIND:
Rick Moen
Monocultures and software security Posted Oct 26, 2002 9:34 UTC (Sat) by sam (guest, #1329) [Link] Rick,As a correction on your listing of MaraDNS, it is me, Sam Trenholme, that is responsible for writing MaraDNS. Leo designed the original web page for MaraDNS but is not a MaraDNS developer. - Sam
Monocultures and software security Posted Oct 28, 2002 19:15 UTC (Mon) by rickmoen (subscriber, #6943) [Link] My apologies, Sam. I've corrected that.
Monocultures and software security Posted Oct 24, 2002 6:46 UTC (Thu) by rickmoen (subscriber, #6943) [Link] Since the story also mentioned Sendmail: Here's a brief attempt to outline the points of comparison among MTAs commonly used on Linux, both open-source (Postfix, Exim, Sendmail, and Courier) and proprietary (Qmail): http://linuxmafia.com/~rick/linux-info/mtasRick Moen
Source/Binary & Monocultures Posted Oct 24, 2002 10:00 UTC (Thu) by anonymous (guest, #6955) [Link] I have question: if it is the same source code,but binaries differ, because of some randomizing option in gcc, will the "community" be still vulnerable? I mean, if buffer overflow does something different on every single machine.
Source/Binary & Monocultures Posted Oct 24, 2002 14:52 UTC (Thu) by rwmj (subscriber, #5474) [Link] A clever way to do this is to load the shared libraries at random addresses in memory (on a standard Linux system, the libraries are loaded at fixed addresses). OpenBSD does something like this. This certainly can be used to increase the difficulty of 'return-into-libc' attacks, because the attacker won't know where libc is located.An even clever way to do this is to randomly relink the functions and variables in the binary and libraries at some point. Either at load time - but that's not very good because you lose the ability to share executables across apps - or at package install time. Another great side effect of this is that certain types of memory corruption bugs become more visible. Rich.
Source/Binary & Monocultures Posted Oct 31, 2002 8:10 UTC (Thu) by anonymous (guest, #6955) [Link] hm, ..actually, i didn't realized how easy it isjust simple ld wrapper or slight modification
Viable free alternative to OpenSSH Posted Oct 26, 2002 9:03 UTC (Sat) by job (subscriber, #670) [Link] The GNU version of SSH, lsh, hasn't had any of these security holes. However, far too few people use it, so please install and try. It interoperates with SSH.com and OpenSSH, but you'll have to relearn some command line switches (much like going from PGP.com to GnuPG). I have been running lsh 1.4.2 as my SSH daemon on several servers for over a year, and so far it has been rock stable.
|
|
||||||||||||