Apache worm could have been prevented
Usually, it's considered appropriate to notify the vendor first, so it has time to come up with a fix before the public--which includes malicious users--knows about the security hole.
But how much time is appropriate? And should the process be sped up when several security experts--and perhaps some malicious users--already know an exploit exists?
This issue came to light recently with regard to a vulnerability in the Apache server software, an open source application from the Apache Software Foundation that runs under Windows, Linux, Solaris, OpenBSD, and FreeBSD. Roughly 60 percent of Internet servers run Apache server software, according to the latest Netcraft survey. So an Apache flaw would likely affect a large percentage of the Internet population.
Over the last several years, Apache has fared better than Microsoft's server apps in terms of security. It's had virtually no known vulnerabilities.
However, on June 17, security company Internet Security Systems (ISS) went public with a vulnerability it discovered. ISS says it notified Apache several hours before releasing the announcement, but the security community condemned ISS for giving Apache so little time to respond. ISS countered by saying it provided a patch for the hole with its alert.
Nonetheless, within 11 days of the vulnerability announcement, a malicious user wrote an Internet worm, called FreeBSD.Scalper.Worm, to take advantage of the flaw.
The flaw in question involves a chunk-encoding buffer overflow in Apache. Chunked encoding is a process used when the HTTP specification accepts data from Web servers. Basically, anytime a user inputs data to a Web server, there needs to be enough memory allocated to hold it. When the input size is unknown, the client's system will negotiate to send data chunks of a certain size. However, a misinterpretation of the incoming chunk by the Apache server allows a malicious user to craft a buffer overflow, and run rogue code on the server.
The question is: Could the Scalper worm have been prevented? That's hard to say for sure, but it's clear that other security companies knew about the flaw before ISS made it public.
On June 19, a company called Gobbles Security took issue with ISS's statement that only win32 and certain 64-bit platforms were vulnerable. It also provided the source code to Apache-scalp.c, a way to exploit the chunk encoding vulnerability on OpenBSD. In addition, Gobbles also claimed to have exploits for OpenBSD (versions 2.6-3.1), Sun Solaris (versions 6-8), FreeBSD (versions 4.3-4.5) and Linux (GNU versions) systems, but did not release these.
It would appear that the Gobbles Security exploit formed the basis of the FreeBSD.Scalper worm. It also seems reasonable that if ISS had privately contacted the Apache vendors before releasing the information to the public, Gobbles might not have released its exploit, which in turn might have delayed or prevented the creation of the Scalper worm. As of July 1, very few FreeBSD systems had been infected with Scalper, and it appears that the worm--for the moment--is a dud.
Whatever Gobbles Security's motivation (it claims to be working in the interests of the security community), the company reported in its BugTraq announcement that it took close to two months to exploit each of the four operating systems. That means it knew about the chunk encoding vulnerability (but did not make it public) back in April or May. Once ISS alerted the public to the vulnerability, Gobbles felt compelled to post its exploit code. Someone then crafted the Gobbles code into the Scalper worm.