blowchunks - protecting existing apache servers until upgrades arrive

From: Cris Bailiff (c.bailiff+bugtraq@devsecure.com)
Date: 06/22/02


From: Cris Bailiff <c.bailiff+bugtraq@devsecure.com>
To: bugtraq@securityfocus.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
any way!

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









Relevant Pages

  • [TOOL] Blowchunks - Protecting Existing Apache Servers Until Upgrades Arrive
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... a known vulnerable apache server until they can ... on HTTP "request" messages. ... Attached are a two versions of code to allow the server to intercept each ...
    (Securiteam)
  • [UNIX] Apache HTTP Server 413 Error Page XSS
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Apache HTTP Server 413 Error Page XSS ... Apache 2.X returns a '413 Request Entity Too Large' error, ...
    (Securiteam)
  • Re: My web server is being redirected (more info)
    ... >> I host my friends site on my home server. ... >> It appears that Apache2 is redirecting the request to the loopback ... # We now support multiple apache configurations on the same server. ... # Format: Redirect old-URI new-URL ...
    (comp.os.linux.networking)
  • Request exceeded the limit of 10 internal redirects
    ... I just installed mod_fastcgid for Apache 2.2 on Fedora Core 6 Linux ... I get an internal server error, and this appears in the error_log: ... # This is the main Apache HTTP server configuration file. ... # will make a new request for the document at its new location. ...
    (comp.infosystems.www.servers.unix)
  • Re: apache question
    ... # Based upon the NCSA server configuration files originally by Rob McCool. ... # configuration directives that give the server its instructions. ... Directives that control the operation of the Apache server process as ...
    (alt.php)

Quantcast