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+k1dq...@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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
