Weekly Edition Return to the Front pageSponsored link Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here. |
The Apache vulnerability, full disclosure, and monocultures
The advisory from Internet Security Systems
(ISS) came out on June 17: the Apache server has a remotely-exploitable
vulnerability in its "chunk handling" code, which is used for handling
uploads of unknown size. The alert describes the problem, notes that the
Apache project has been alerted, and includes a patch.
It all looks like a fairly normal response to security problems in the free software community, until you look a little more closely. It turns out that the Apache group was already aware of the problem and was working on a fix. The Computer Emergency Response Team (CERT) also was already involved. It also turns out that the ISS patch does not completely fix the problem. ISS, in its hurry to publicise the vulnerability, had not checked with either CERT or the Apache Software Foundation. Full disclosure of security vulnerabilities is (usually) seen as a good thing in the free software community. Freedom, with regard to software, includes the freedom to know about (and fix) problems. And, of course, full disclosure is a powerful tool for forcing a software maintainer to release a fix - most of the time. As a general rule, nobody is more secure when the crackers are the only ones to know about security problems. The other side of full disclosure, however, is that, when done too soon, it can leave millions of users open to a vulnerability while no fix is available. Such is the case this time around. Sites running Apache on Windows are most vulnerable to the chunk handling vulnerability; such sites are probably running a binary distribution of Apache, many do not even have a compiler available, and thus they will be poorly served by a source patch. Full disclosure is a powerful tool which should be used with care. The disclosure of a security vulnerability should never be a surprise to those who must clean up the mess. Those who find security problems should always work with the package maintainer and give that maintainer time to make a fix available. Only in cases of serious stalling or neglect should a disclosure go out before the maintainer is ready. This is a lesson that the free software community will probably have to relearn every so often. Free software has the potential to be far more secure; its open nature lets any interested party inspect the code for problems. But much of that advantage is lost when vulnerabilities are handled in an immature manner. If you or your company find a security vulnerability, surely you can wait a few days to claim your credit. This vulnerability raises another concern as well. Much has been said about the dominance of Windows systems on the net; the resulting "monoculture" is highly vulnerable to security problems. Apache's share of the total web server population is such that it could be considered a monoculture as well. Apache has obtained that share through consistent high quality and a strong security record. No package is completely invulnerable, however, and Apache problems, when they do turn up, place much of the net at risk. For the security of the net as a whole, it would be nice if there were another free web server with something resembling Apache's stature and market share. For details on the chunk handling vulnerability, see the LWN vulnerability entry, the advisory from the Apache Software Foundation or the CERT advisory. Initial indications were that this problem was not remotely exploitable on Linux systems, but that claim is now known to be false. If you are running an Apache server, you want to upgrade as soon as possible. (Log in to post comments)
The Apache vulnerability: why disclosure of this problem so early? Posted Jun 18, 2002 17:27 UTC (Tue) by BogusUser ((unknown), #2129) [Link] I think it is important to mention the vulnerability wasdetected during a test, there was no indication of anyone using this to compromise any server. Especially in cases like this, there is time to consult the makers of the software and to find a fix, before seeking publicity.
Apache 1.3.26 available Posted Jun 18, 2002 22:21 UTC (Tue) by dananderson (guest, #905) [Link] Apache 1.3.26 is available which is supposed to fix the buffer overflow problem.
For mirrors:
http://www.apache.org/dyn/closer.cgi/httpd/
To avoid monoculture nurture alternative servers (e.g. Caudium) Posted Jun 19, 2002 13:08 UTC (Wed) by ber (subscriber, #2142) [Link] Monoculture can grow to be a problem for the Free Software communityas this incident clearly shows. So having several high quality solutions 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 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.
Exploit posted to Bugtraq this morning (not just unix64/win32) Posted Jun 20, 2002 5:50 UTC (Thu) by yem (guest, #1138) [Link] http://online.securityfocus.com/archive/1/277830/2002-06-17/2002-06-23/0
Not so simple as "Apache is a monoculture" Posted Jun 20, 2002 17:50 UTC (Thu) by bjn (guest, #2179) [Link] 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.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.
it's not a problem of the monoculture at all Posted Jun 25, 2002 19:06 UTC (Tue) by BogusUser ((unknown), #2254) [Link] What if you do have e.g. 5 open source implementations of web serversthat all take about 20% of the server installations? in terms of the LWN argue it would be safer to drive like this, its simply a problem of having enough developers, code reviewers tell the world that open standards are a good thing but a different aspect - what if there were 5 webservers out there? compare to the desktop browser war on open source desktops - and for a last argue, there must be measures to make standard I want to remeber the cleanup of the multiple instances of the Dont complain that a single bug can have such a magnitude of affected A healty open source community must have a strong look onto its own Regards, Alex.
|
Copyright © 2002, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.