From: Cris Bailiff [c.bailiff+bugtraq@devsecure.com]
Sent: Saturday, June 22, 2002 2:20 AM
To: bugtraq@securityfocus.com
Subject: blowchunks - protecting existing apache servers until upgrades
arrive


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 
any way!

Cris Bailiff
/dev/secure Pty Ltd - Awayweb, the Virtual VPN - http://www.awayweb.com