httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <Dirk-Willem.van.Gu...@bbc.co.uk>
Subject Re: Final draft / CVE-2011-3192
Date Thu, 25 Aug 2011 06:49:18 GMT
Thanks. Added to the interim draft update.

Dw.

On 25 Aug 2011, at 06:36, Steffen wrote:

> For Mitigation of Apache Range Header DoS Attack with mod_security, see
> also:
> 
> http://blog.spiderlabs.com/2011/08/mitigation-of-apache-range-header-dos-attack.html
> 
> 
> ----- Original Message -----
> From: "Dirk-Willem van Gulik" <dirkx@webweaving.org>
> Newsgroups: gmane.comp.apache.devel
> To: <security@httpd.apache.org>; <dev@httpd.apache.org>
> Sent: Wednesday, August 24, 2011 5:34 PM
> Subject: Final draft / CVE-2011-3192
> 
> 
> Thanks for all the help. All fixes included. Below will go out to announce
> at the top of the hour - unless I see a veto.
> 
> Dw.
> 
> 
> 
> 
> Title:    CVE-2011-3192: Range header DoS vulnerability Apache HTTPD 1.3/2.x
>           Apache HTTPD Security ADVISORY
> 
> 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:
> ============
> 
> However there are several immediate options to mitigate this issue until
> that time.
> 
> 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 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
> 
> Actions:
> ========
> 
> However there are several immediate options to mitigate this issue until
> that time.
> 
> 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 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
> 
> 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.
> 
> 
> 
> 
> 


Mime
View raw message