mailing list archives
blowchunks - protecting existing apache servers until upgrades arrive
From: Cris Bailiff <c.bailiff+bugtraq () devsecure com>
Date: Sat, 22 Jun 2002 16:19:54 +1000
Many sysadmins will be in the unpleasant situation of having to live with a
known vulnerable apache server (or switching it off) until they can obtain,
test and integrate updated apache binaries for their various platforms from
different vendors, or make enough time to sit down and patch, re-compile and
test their home-grown versions.
Some vendors have been very fast to respond, and have back-ported the fix to
many older apache releases, helping avoid many issues that a forced upgrade
might involve. Other vendors supplying apache and apache-based servers may
not be so quick off the mark (or may not even be around anymore). Home grown
releases may also be similarly outdated, and back-porting is tedious.
Because apache is so great, and has had a history of very few serious
security bugs, older versions are embedded in a wide variety of products and
systems, making it even more problematic to update all of them to the latest
release in a timely manner.
Here's an option which might help in protecting those vulnerable servers,
giving a breathing space until a proper tested fix does become available:
Basically, most web sites and applications have no need for chunked transfer
encoding on HTTP *request* messages. Most browsers don't even support it,
and it's only *required* when a client doesn't know the final length of a
file before an upload (which is pretty rare). Disallowing such requests
should be no big deal. (This has nothing to do with using chunked encoding
for data served in the HTTP *response*, though I guess we should start
looking out for malicious web servers attacking vulnerable clients...)
Attached are a two versions of code to allow the server to intercept each
incoming HTTP request (at the 'Post Read Request' phase), and check to see if
chunked encoding has been requested. If so, the request is denied and
logged. This should prevent clients being able to trigger the vulnerable
'chunk size' reading code, and therefore prevent DoS or exploits.
* BlowChunks.pl - this version is for mod_perl enabled servers - if you have
a server with mod_perl already in place, this patch is trivial to install.
Just paste it into the end of your existing httpd.conf, and restart. All
done. Very Easy.
* mod_blowchunks.c - this version is an apache module. If your apache is
compiled with DSO support (run httpd -l and look for mod_so), you can compile
and install this module with just one apxs command (and a compiler!), and
restart. Should be straightforwards for most admins.
There is, of course, absolutely no warranty on these fixes, but it 'works for
me'. There could be ways round the protection provided, so rely on this
entirely at your own risk!
Both methods offer the advantage of not needing to touch your existing apache
binary (or any other modules), and can be trivially reverted if you have any
trouble, or when your real fix is ready. The should work on any platform with
either mod_perl or DSO support. If your apache is static, without DSO, you
could re-compile it with this module included, but then you might as well
just fix it properly.
Any suggestions, criticisms or improvements on this technique are welcome,
but, sorry, I am not able to 'help out', answer questions or otherwise
provide support or assistance in compiling, installing or making them work in
/dev/secure Pty Ltd - Awayweb, the Virtual VPN - http://www.awayweb.com
Description: blowchunks perl version
Description: blowchunks apache module version
- blowchunks - protecting existing apache servers until upgrades arrive Cris Bailiff (Jun 22)