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" <[email protected]> > Newsgroups: gmane.comp.apache.devel > To: <[email protected]>; <[email protected]> > 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+k1dq...@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+k1dq...@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. > > > > >
