Date: Fri, 26 Aug 2011 13:09:18 +0200
From: Carlos Alberto Lopez Perez <clopez@...lia.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Advisory: Range header DoS vulnerability
 Apache HTTPD 1.3/2.x (CVE-2011-3192)

On 26/08/11 12:35, Dirk-Willem van Gulik wrote:
>          Apache HTTPD Security ADVISORY
>          ==============================
>                    UPDATE 2
> 
> Title:       Range header DoS vulnerability Apache HTTPD 1.3/2.x
> 
> CVE:         CVE-2011-3192
> Last Change: 20110826 1030Z
> Date:        20110824 1600Z
> Product:     Apache HTTPD Web Server
> Versions:    Apache 1.3 all versions, Apache 2 all versions
> 
> Changes since last update
> =========================
> In addition to the 'Range' header - the 'Range-Request' header is equally
> affected. Furthermore various vendor updates, improved regexes (speed and
> accommodating a different and new attack pattern).
> 
> 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 tool 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 24 hours. 
> 
> Background and the 2007 report
> ==============================
> 
> There are two aspects to this vulnerability. One is new, is Apache specific; 
> and resolved with this server side fix. The other issue is fundamentally a 
> protocol design issue dating back to 2007:
> 
>      http://seclists.org/bugtraq/2007/Jan/83 
> 
> The contemporary interpretation of the HTTP protocol (currently) requires a 
> server to return multiple (overlapping) ranges; in the order requested. This 
> means that one can request a very large range (e.g. from byte 0- to the end) 
> 100's of times in a single request. 
> 
> Being able to do so is an issue for (probably all) webservers and currently 
> subject of an IETF discussion to change the protocol:
> 
>      http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
> 
> This advisory details a problem with how Apache httpd and its so called 
> internal 'bucket brigades' deal with serving such "valid" request. The
> problem is that currently such requests internally explode into 100's of 
> large fetches, all of which are kept in memory in an inefficient way. This
> is being addressed in two ways. By making things more efficient. And by 
> weeding out or simplifying requests deemed too unwieldy.
> 
> Mitigation:
> ===========
> 
> There are several immediate options to mitigate this issue until a full fix 
> is available. Below examples handle both the 'Range' and the legacy
> 'Request-Range' with various levels of care. 
> 
> Note that 'Request-Range' is a legacy name dating back to Netscape Navigator 
> 2-3 and MSIE 3. Depending on your user community - it is likely that you
> can use option '3' safely for this older 'Request-Range'.
> 
> 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.2)
> 
>          # Drop the Range header when more than 5 ranges.
>          # CVE-2011-3192
>          SetEnvIf Range (?:,.*?){5,5} bad-range=1
>          RequestHeader unset Range env=bad-range
> 
>          # We always drop Request-Range; as this is a legacy
>          # dating back to MSIE3 and Netscape 2 and 3.
>          RequestHeader unset Request-Range
> 
>          # optional logging.
>          CustomLog logs/range-CVE-2011-3192.log common env=bad-range
>          CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range
> 
>   Above may not work for all configurations. In particular situations
>   mod_cache and (language) modules may act before the 'unset'
>   is executed upon during the 'fixup' phase.
> 
>   Option 2: (Pre 2.2 and 1.3)
> 
>          # Reject request when more than 5 ranges in the Range: header.
>          # CVE-2011-3192
>          #
>          RewriteEngine on
>          RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
>          # RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
>          RewriteRule .* - [F]
^^
Better use this:

RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]

Because if you don't specify the [OR] apache will combine the rules
making an AND (and you don't want this!).

Also use NC=(nocase) to prevent the attacker upper casing "bytes="
(don't know if it will work.. but just to prevent)


> 
>          # We always drop Request-Range; as this is a legacy
>          # dating back to MSIE3 and Netscape 2 and 3.
>          RequestHeader unset Request-Range
> 
>   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.
> 
>   Furthermore to ignore the Netscape Navigator 2-3 and MSIE 3 specific
>   legacy header - add:
> 
>          RequestHeader unset Request-Range 
> 
>   Unlike the commonly used 'Range' header - dropping the 'Request-Range' 
>   is not likely to affect many clients.
> 
> 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
>   http://svn.apache.org/viewvc?view=revision&sortby=date&revision=1161534
> 
> 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.
> 
> mod_security:   Has updated their rule set; see
>                http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
> 
> 
> 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 - note 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 24 hours. Note that, while popular, Apache 1.3 is deprecated.
> 
> -- end of advisory - update 2 

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




Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)

_______________________________________________
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