As in the first exploit, the source code for apache-nosejob states that over a two-month research period, Gobbles Security discovered how to use the attack against not just BSD operating systems, but also against Solaris 6 through Solaris 8 on both SPARC and i386 chips and Linux 2.4 on i386.
Gobbles also says it will release further exploit details this week.
Given these statements and the widespread availability of existing exploit code, its critical that all organizations using Apache upgrade as soon as possible to fixed versions of the Web server.
Problem detection and prevention
Apache patches and updated versions of the full Apache HTTP Server are available from the Apache Software Foundation, openbsd.org and most Linux vendors. As of mid-day on Monday, Sun hadnt posted a patch yet—typically, it takes Sun three to four weeks to release a security patch.
In addition, BugTraq poster Cris Bailiff has published plug-ins for Apache that will block all chunked encoding transfers from clients. The plug-ins are in mod_perl format and in Apache binary module format—both can be used without recompiling or upgrading Apache as a temporary workaround. Chunked encoding is a little-used feature for uploading data to a Web server from a browser, and most sites dont need it in any case.
Chunked encoding a widespread problem
Apache HTTP Server has a well-deserved reputation for excellent security: The last remotely exploitable hole in Apache that allowed attackers to run executable code was back in January 1997, five-and-a-half years ago.
The chunked encoding problem is not unique to Apache—Microsofts IIS 4.0, 5.0 and 5.1 all have had similar buffer overflows in their default configurations (see Microsoft Security Bulletin MS02-018, released on April 10, 2002), and Microsoft Security Bulletin MS02-028(released on June 12, 2002). Both these sets of vulnerabilities allow attackers to execute the code of the attackers choice on IIS if posted patches are not applied.
Weve seen how bad IIS worms are. Apache hosts almost twice as many Web sites as IIS does (see www.netcraft.com/survey/) and is embedded in a great number of products (Oracles namesake database and application server are two examples).
With Apaches huge deployed base, this attack could become the core of the mother of all Internet worms. This is a bad, bad situation.
New exploit makes attacks easier
The new Gobbles Security exploit, titled apache-nosejob, adds FreeBSD and NetBSD to the list of operating systems for which the exploit has pre-coded attack settings. It also adds command-line options to set various buffer overflow settings manually to use the code to attack systems other than those with pre-set settings. Theres also an automatic setting permutation option (a brute-force scan option) to make it simpler to attack other systems that dont have settings already specified.
I installed a fresh copy of OpenBSD 3.1 and enabled the copy of Apache 1.3.24 that comes with the operating system (Apache is installed but not enabled by default in OpenBSD).
The exploit did not work against this system using either the pre-set OpenBSD 3.1 settings or the brute-force attack option, but other OpenBSD users have reported the attack works against their system. To see what a successful attack looks like, go to www.anuzis.net/apachescalp.txt.
Prompting yet further concern, Gobbles Security claims in an interview with security site SecurityFocus that it originally developed exploit code for this problem in November 2001, months before it was discovered and reported to Apache Software Foundation by security researcher Mark Litchfield.
Gobbles Security also states in its exploit source code that the exploit has been tested against a number of high-profile sites including Yahoo, Hotmail and @Stake, so it now appears this attack has been circulating in secret among the computer underground for some months.
Because of this, eWeek Labs advise examining Apache server logs back to mid-2000 for evidence of Apache child Web processes crashing.
While the buffer overflow does not leave an entry in Apaches access log, it will leave a notice in the Apache error log stating: "[notice] child pid (nnnnn) exit signal Segmentation fault (11)".
Im not sure if this notice is created in the case of a successful exploit, but my tests showed that it definitely is left by an unsuccessful attack as well as a probe to determine if the system is vulnerable (the eEye Apache security checker leaves such an error message).
Attack detection signatures for intrusion detection systems have also begun to appear that will alert administrators to Apache chunked encoding attacks. Snort has one such signature available.
Again, finding all vulnerable Apache Web servers installed in your organization (regardless of platform) and then either upgrading, patching or installing workarounds to block chunked encoding transfers has become an urgent task.
West Coast Technology Director Timothy Dyck can be reached at firstname.lastname@example.org.