Message-ID: <CAFB=mGARj0K3dy+5DFRu5cKq0Bx1R25YVi62t9O9LjPGvPyKTw@mail.gmail.com>
Date: Sat, 27 Aug 2011 05:03:47 +0200
From: "HI-TECH ." <isowarez.isowarez.isowarez@...glemail.com>
To: "-= Glowing Sex =-" <doomxd@...il.com>
Cc: full-disclosure@...ts.grok.org.uk,
	Pat Maechler <Patrick.Maechler@...d.unibas.ch>
Subject: Re: Apache Killer

Hello Lists,

the youtube video at the bottom illustrates the threat quite good.
these where the exact same observations I had when initially running the tool.
It has to be noted that a good architecture can very likely mitigate the risks.
For example load balancing to multiple targets will most likely slow
down the tool
giving different results than this flat configuration:

http://www.youtube.com/watch?v=3al1lsvFSpA

2011/8/25 -= Glowing Sex =- <doomxd@...il.com>:
> Hello list,
> Note about the original script/script being used..
>
> Just for anyone out there wishing to make this exploit 'useful' , as it
> says, this has nothing todo with the 'testapache' used in that code, as this
> involves checking on mod_deflate, wich is useless, so instead of that if ($x
> = /Partial/) { }
>
> if($x !~ /^http:\/\//) {
> print "[+] Host seems alive..\n";
> return 1;
> } else {
> return 0;
> }
>
> would then test all your servers, not just checking on those wich have
> mod_deflate enabled... i am yet to test the latest 'killer' :S but i will
> have a look soon.
> thx to everyone for theyre help on this, every fix was put it seems into the
> apache advisory, most of the fixes put forth here anyhow, wich is great.
> apache.orgh saw this list, and ackowledged it had todo something good, and
> they did, much props to them for theyre response on the matter, they have
> been class act on this, even tho it should have been patched in 2007 or even
> around then,... that is for atleast one hole... one, i guess could been
> stopped if the coe had been looked at, improved, wich has happened now, so
> thankyou to all who res[ponded on this.. but please be sure to adjust the
> script so it just tests a live url.
> cheers!
> xd
>
> The advisory i mentioned was also posted already but this, is great work:
>
>          Apache HTTPD Security ADVISORY
>          ==============================
>                    UPDATE 1
>
> Title:       Range header DoS vulnerability Apache HTTPD 1.3/2.x
>
> CVE:         CVE-2011-3192
> Last Change: 20110824 1800Z
> Date:        20110824 1600Z
> Product:     Apache HTTPD Web Server
> Versions:    Apache 1.3 all versions, Apache 2 all versions
>
> Description:
> ============
>
> A denial of service vulnerability has been found in the way the multiple
> overlapping ranges are handled by the Apache HTTPD server:
>
>     http://seclists.org/fulldisclosure/2011/Aug/175
>
> An attack tool is circulating in the wild. Active use of this tools has
> been observed.
>
> The attack can be done remotely and with a modest number of requests can
> cause very significant memory and CPU usage on the server.
>
> The default Apache HTTPD installation is vulnerable.
>
> There is currently no patch/new version of Apache HTTPD which fixes this
> vulnerability. This advisory will be updated when a long term fix
> is available.
>
> A full fix is expected in the next 48 hours.
>
> Mitigation:
> ============
>
> There are several immediate options to mitigate this issue until a full fix
> is available:
>
> 1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
>   either ignore the Range: header or reject the request.
>
>   Option 1: (Apache 2.0 and 2.2)
>
>          # Drop the Range header when more than 5 ranges.
>          # CVE-2011-3192
>          SetEnvIf Range (,.*?){5,} bad-range=1
>          RequestHeader unset Range env=bad-range
>
>          # optional logging.
>          CustomLog logs/range-CVE-2011-3192.log common env=bad-range
>
>   Option 2: (Also for Apache 1.3)
>
>          # Reject request when more than 5 ranges in the Range: header.
>          # CVE-2011-3192
>          #
>          RewriteEngine on
>          RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^
> $)
>          RewriteRule .* - [F]
>
>   The number 5 is arbitrary. Several 10's should not be an issue and may be
>   required for sites which for example serve PDFs to very high end eReaders
>   or use things such complex http based video streaming.
>
> 2) Limit the size of the request field to a few hundred bytes. Note that
> while
>   this keeps the offending Range header short - it may break other headers;
>   such as sizeable cookies or security fields.
>
>          LimitRequestFieldSize 200
>
>   Note that as the attack evolves in the field you are likely to have
>   to further limit this and/or impose other LimitRequestFields limits.
>
>   See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
>
> 3) Use mod_headers to completely dis-allow the use of Range headers:
>
>          RequestHeader unset Range
>
>   Note that this may break certain clients - such as those used for
>   e-Readers and progressive/http-streaming video.
>
> 4) Deploy a Range header count module as a temporary stopgap measure:
>
>     http://people.apache.org/~dirkx/mod_rangecnt.c
>
>   Precompiled binaries for some platforms are available at:
>
>        http://people.apache.org/~dirkx/BINARIES.txt
>
> 5) Apply any of the current patches under discussion - such as:
>
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3cCAAPSnn2PO-d-C4nQt_TES2RRWiZr7urefhTKPWBC1b+K1Dqc7g@mail.gmail.com%3e
>
> OS and Vendor specific information
> ==================================
>
> Red Hat:        Option 1 cannot be used on Red Hat Enterprise Linux 4.
>                https://bugzilla.redhat.com/show_bug.cgi?id=732928
>
> NetWare:        Pre compiled binaries available.
>
> Actions:
> ========
>
> Apache HTTPD users who are concerned about a DoS attack against their server
> should consider implementing any of the above mitigations immediately.
>
> When using a third party attack tool to verify vulnerability - know that
> most
> of the versions in the wild currently check for the presence of mod_deflate;
> and will (mis)report that your server is not vulnerable if this module is
> not
> present. This vulnerability is not dependent on presence or absence of
> that module.
>
> Planning:
> =========
>
> This advisory will be updated when new information, a patch or a new release
> is available. A patch or new apache release for Apache 2.0 and 2.2 is
> expected
> in the next 48 hours. Note that, while popular, Apache 1.3 is deprecated.
>
> ...it took into account the public,and altho the fixes could have been
> credited, it is a great advisory, and very good on respnding to the issue,
> albeit late.
> xd
>
>
>
> On 25 August 2011 03:07, Pat Maechler <Patrick.Maechler@...d.unibas.ch>
> wrote:
>>
>> Does this fix work as well if I put it in httpd.conf instead?
>> I'm no Apache/RewriteEngine crack, but I know that there are some
>> differences with the rewrite engine if you put it into httpd.conf
>> instead of .htaccess (and I have currently no possibility to do a safe
>> test) :-/
>>
>> Reply to
>> > From: Davide Guerri <davide.guerri () gmail com>
>> > Date: Wed, 24 Aug 2011 10:03:03 +0200
>> >> RewriteEngine On
>> >> RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
>> >> RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
>> >> RewriteRule .* - [F]
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists