Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The "CVE-2011-3192" page has been changed by wrowe: http://wiki.apache.org/httpd/CVE-2011-3192?action=diff&rev1=1&rev2=2 Comment: Draft edit from dirkx - Describe CVE-2011-3192 here. + {{{ + Apache HTTPD Security ADVISORY + ============================== + UPDATE 3 - FINAL + Title: Range header DoS vulnerability Apache HTTPD prior to 2.2.20. + + CVE: CVE-2011-3192 + Last Change: 20110831 1800Z + Date: 20110824 1600Z + Product: Apache HTTPD Web Server + Versions: Apache 2.0 - all versions prior to 2.2.20; + Apache 1.3 is NOT vulnerable. + + Changes since last update + ========================= + 2.2.20 has a fix. 2.2.21 a bitter on. 1.3. not vulnerable. Further regex/rule + improments. 1.3 support stopgap module. Explain DoS. Reduce severity for 1.3. + Added wiki link. Highlight fact that LimitRequestFieldSize is not sufficient. + + Changes since update 1 + ========================= + In addition to the 'Range' header - the 'Request-Range' 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 prior to version + 2.2.20: + + 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 installations version 2.0 and 2.2 prior to + 2.2.20 are vulnerable. + + Apache 2.2.20 does fix this issue; however with a number of side effects + (see release notes). Version 2.2.21 xxx + + Apache 1.3 + ========== + + Apache 1.3 is NOT vulnerable. However as explained in the background section + in more detail - this attack does cause a significant and possibly unexpected + load. You are advised to review your configuration in that light. + + Type of Attack + ============== + + This vulnerability concerns a 'Denial of Service' attack. This means that + a remote attacker, under the right circumstances, is able to slow your + service or server down to a craw. Leaving it unable to serve legitimate + clients in a timely manner. + + There are no indications that this leads to a remote exploit; where a + third party can compromise your security and gain foothold of the server + itself. The result of this vulnerability is purely one of denying service + by grinding your server down to an halt. + + 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: + + 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: + + 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. + + FIX + ==== + + This vulnerability has been fixed in release 2.2.20 and beyond. You are + advised to upgrade to version 2.2.21 (or newer). + + If you cannot upgrade - you can apply a Patch and recompile: + + If you cannot upgrade and/or cannot apply above patches in a timely manner + then you could consider to apply te mitigations suggested below. + + CAVEATS + ======= + + Note that this fix 1) will return a "200 OK" in cases where a 206 respond would + be larger and 2) changes the behavior of chunked responses. This may affect + certain clients. See the above background section and IETF reference for + more detail and the various discussions around fixing this in the protocol. + + Furthermore a request with a byterange beyond the end of the file used to + return 416 but now returns 200. This is a violation of a RFC2616 SHOULD. + + 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'. + + 0) Consult + for more recent + information (as this is the final advisory). + + 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 + + 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) + + # Reject request when more than 5 ranges in the Range: header. + # CVE-2011-3192 + # + RewriteEngine on + RewriteCond %{ + } !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC] + RewriteRule .* - [F] + + # 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. + + WARNING These directives need to be specified in every configured + vhost, or inherited from server context as described in: + + 2) 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. + + An improved stop-gap module for the 2.x series was provided by + Guenter Knauf and can be found at: + + Note + ==== + + Earlier advisories suggested theuse of LimitRequestFieldSize. This method is + not fully effective and can by bypassed by splitting the attack vector up + across multiple headers. Therefore you should not rely on LimitRequestFieldSize + alone. + + OS and Vendor specific information + ================================== + + Red Hat: Has additional RHEL specific information at: + + NetWare: Pre compiled binaries available. + + mod_security: Has updated their rule set; see + + + Actions: + ======== + + Apache HTTPD users who are concerned about a DoS attack against their server + should 1) upgrade to version 2.2.20, 2) if not possible - apply the provided + patches or 3) 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: + ========= + + No further advisories are planned. However we will track information at + }}} + --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
