Revival of an Unpatched Apache HTTPD DoS

Published: 2011-08-25. Last Updated: 2011-08-25 03:17:50 UTC
by Kevin Shortt (Version: 1)
8 comment(s)

Readers have been writing in and I wanted to get this out to for info and comment.  I have not had a chance to test it out myself.  It first surfaced in 2007 by Michal Zalewski on bugtraq. [1]   It appears due to its lack of sophistication, that it did not get much attention by Apache developers and it has remained unpatched all of this time.

It formally resurfaced last Friday with a proof of concept.  A CVE is in draft and a patch is expected in a few days by the Apache team.  You can read a discussion about it on the Apache HTTPD dev mailing list. [2]   The link provides details on some mitigation measures to be taken.   When I get chance I will test and report back.  

In the mean time please share your experiences with your fellow readers with a comment.

 
[1] http://seclists.org/bugtraq/2007/Jan/83
[2] http://marc.info/?l=apache-httpd-dev&m=131418828705324&w=2

-Kevin
--
ISC Handler on Duty

Keywords: apache DoS kill tool
8 comment(s)

Comments

I tried this out yestersay on a virtual machine running CentOS 6. Load and memory consumption immediately rose on the server, a very effective DoS IMHO. I shall be playing with mitigation techniques today ahead of an official patch.

Jim

Aug 25th 2011
1 decade ago

I too tested this on stock apache on CentOS 6, however the attack failed. I do not use the default config, instead my config is trimmed down to the only modules necessary and other general hardening. Unfortunately I was too buy to investigate it further, as all my servers utilize similar apache configuration.

VJ

Aug 25th 2011
1 decade ago

Since I had more time today, I investigated why the attack fails against my servers. Turns out I do not use mod_gzip/mod_deflate. See http://lists.grok.org.uk/pipermail/full-disclosure/2011-August/082302.html

This is not the first time taking the minimalist (least privilege) approach has paid off for me. :-)

VJ

Aug 25th 2011
1 decade ago

I tried this on metasploitable's web server. Results here:
http://compusec.org/?p=111

Albert

Aug 25th 2011
1 decade ago

Although the P0F uses mod_gzip/mod_deflate the concensus seems to be that the vulnerability lies in the range_bytes code and has nothing to do with mod_gzip/mod_deflate although this module seems to amplify the problem.
Disabling mod_gzip/mod_deflate is NOT A FIX, but considering the kiddies might save you a lot of grief.

Patrick

Aug 26th 2011
1 decade ago

The posting on the apache dev list that's linked above has broken solutions for handling the Range header.
Better read the "official" posting on the apache announce list that has updated info

http://marc.info/?l=apache-httpd-announce&m=131420273523300&w=2

Patrick

Aug 26th 2011
1 decade ago

I too was pleasantly surprised to see 'Host not vulnerable" results.... it was nice for a change walking over and praising the admins for their 'less is more' approach to their Apache configs.

I would encourage you to do the same if you can...

CS

Aug 26th 2011
1 decade ago

Also: "In an updated advisory posted this morning(8.26.11), the Apache team revealed further exposure of the platform to the attack, and noted that "active use of this tool has been observed." " ~DarkReading
http://seclists.org/fulldisclosure/2011/Aug/301

CS

Aug 26th 2011
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives