LWN: Comments on "The Apache vulnerability, full disclosure, and monocultures"
http://lwn.net/Articles/2756/
This is a special feed containing comments posted
to the individual LWN article titled "The Apache vulnerability, full disclosure, and monocultures".
hourly2it's not a problem of the monoculture at all
http://lwn.net/Articles/3426/rss
2002-06-25T19:06:24+00:00DeletedUser2254
What if you do have e.g. 5 open source implementations of web servers<br>that all take about 20% of the server installations?<p>in terms of the LWN argue it would be safer to drive like this,<br>but they are on error. when you do have 5 web servers then you<br>have 5 mostly different codebases, 5 times the places where<br>vulnerabilities might waiting to compromise the community.<p>its simply a problem of having enough developers, code reviewers<br>and lab tests plus the usual out in the wild "tests" with hackers.<br>when your software lacks inspection due to its magnitued then it<br>can only get worser when you have 5 of that magnitude.<p>tell the world that open standards are a good thing <br>and that open source standard software is just the better choice.<p>but a different aspect - what if there were 5 webservers out there?<br>would you expect them to have all the same features?<br>would you expect at least on of them to provide you <br>all the features you need for your business?<p>compare to the desktop browser war on open source desktops - <br>which of them does Java, SSL and a few more features? <br>why do we need all those wanne be browsers <br>whilst only a few fullfill the practical needs<br>but an unknown amount of them is most likely having security <br>vulnerabilities? same for the crowds of MP3 audio/video players...<p>and for a last argue, there must be measures to make standard<br>open source software more secure. think of the SEL package<br>for the Linux kernel and its userland counterpart. <br>did you ever notice that there is no BeOS, no BSD (net, free, open)<br>and no hurd version of the SEL package around? Thats where choice<br>does developers drive mad. good development is done only once.<p>I want to remeber the cleanup of the multiple instances of the<br>zip algorithm in the linux kernel some half year ago. And i want<br>to remember the Amiga OS that had really only a single implementation<br>of "printf" in the whole system, regardless of application, system<br>or kernel caller - they all used the same prooven codebase. If there<br>would ever pop up a bug, then the fixing would be a single operation.<p>Dont complain that a single bug can have such a magnitude of affected<br>systems due to "monoculture" (in fact Apache does have only some 50%<br>share if i remember correctly). Only a widespread system can ensure<br>that open source community has the man power to maintain it. If we<br>had multiple of such software then the number of bugs that a certain<br>system with a particular software will suffer wont get better. It only<br>will take longer time to get fixes and updates carried out due since<br>the number of developers (and developer time) per software package<br>will significantly shrink. <p>A healty open source community must have a strong look onto its own<br>effectiveness (like using bitkeeper), else it will spent a good deal<br>of its working hours with useless tasks. Thats not true in all cases,<br>e.g. where there are different promising approaches to follow and<br>different requirements to fullfill, but its true in general for the <br>whole community. Re-inventing the wheel over and over again wont<br>benefit anyone, despite the one that feels great about.<p>Regards, Alex.
Not so simple as "Apache is a monoculture"
http://lwn.net/Articles/3113/rss
2002-06-20T17:50:42+00:00bjn
This vulnerability, like many others, is a stack overflow. Such vulnerabilities are very sensitive to the hardware architecture, operating system, and compiler. Unlike IIS (which runs on only one OS, and only one hardware architecture), Apache runs on many OSes, and many hardware architectures, and is compiled with many compilers. I wouldn't call that a monoculture (w.r.t security), since it is much harder to write an exploit that will work on all of them.<p>I would expect the more popular variations (Red Hat Linux on Intel, for example) to be widely attacked; but I doubt any attack tool is going to reach a majority of the Apache servers worldwide.
Exploit posted to Bugtraq this morning (not just unix64/win32)
http://lwn.net/Articles/3037/rss
2002-06-20T05:50:23+00:00yem
http://online.securityfocus.com/archive/1/277830/2002-06-17/2002-06-23/0
To avoid monoculture nurture alternative servers (e.g. Caudium)
http://lwn.net/Articles/2911/rss
2002-06-19T13:08:22+00:00ber
Monoculture can grow to be a problem for the Free Software community<br>as this incident clearly shows. So having several high quality solutions<br>and some diversity is good even for webservers. The Free Software is out there, we just have to foster diversity. I'm a long time user of<br>the Caudium (www.caudium.info) webserver (a people's fork of Roxen formerly known Spinner, aka Spider) and it is good to have a choice.
Apache 1.3.26 available
http://lwn.net/Articles/2857/rss
2002-06-18T22:21:12+00:00dananderson
Apache 1.3.26 is available which is supposed to fix the buffer overflow problem.
<p>
For mirrors:
<a href="http://www.apache.org/dyn/closer.cgi/httpd/">
http://www.apache.org/dyn/closer.cgi/httpd/</a>
<br>
For direct download:
<a href="http://www.apache.org/dist/httpd/">
http://www.apache.org/dist/httpd/</a>
The Apache vulnerability: why disclosure of this problem so early?
http://lwn.net/Articles/2785/rss
2002-06-18T17:27:04+00:00DeletedUser2129
I think it is important to mention the vulnerability was<br>detected during a test, there was no indication of anyone<br>using this to compromise any server.<br>Especially in cases like this, there is time to consult<br>the makers of the software and to find a fix, before<br>seeking publicity.