| Summary: | Byte Range Filter might consume huge amounts of memory combined with compressed streams | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | kingcope <isowarez.isowarez.isowarez> |
| Component: | All | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | apache_bugzilla, stinkoid |
| Priority: | P2 | Keywords: | FixedInTrunk |
| Version: | 2.2.17 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: | DoS Exploit for mentioned vulnerability | ||
As discussed on the Apache Dev Mailing list it looks like this issue has nothing to do with mod_deflate or mod_gzip, wrong assumption by me. (In reply to comment #0) > Created attachment 27429 [details] > DoS Exploit for mentioned vulnerability > > At least apache 2.2.17 has a remotely exploitable dos vulnerability which > allows to consume all memory on a target system. A request for triggering the > memory consumption includes a large "Range" header which requests as many > different bytes as possible from a file served by httpd. Combining this with a > gzip "Accept-Encoding" header the httpd is assumed to compress each of the > bytes requested in the Range header seperately consuming large memory regions. > The behaviour when compressing the streams is devestating and can end up in > rendering the underlying operating system unusable when the requests are sent > parallely. Symptomps are swapping to disk and killing of processes including > but not solely httpd processes. > > How to repeat: > Execute the attached perl script for a vulnerable httpd, means Byte Range > filter and mod_deflate/mod_gzip enabled. > > Sidenote: > Apache should be aware of that through posting to full disclosure. Nevertheless > should in my opinion this bug be resolved. First, I'm not an expert on the matter. A small addition might be in place to the work-around option suggested in: <http://marc.info/?l=apache-httpd-dev&m=131418828705324&w=2> The first mitigation option was a configuration change: RequestHeader unset Range In addition to dropping the "Range" from request headers, it might prove useful to drop the "If-Range" as well, and might also be polite to respond with "Accept-Ranges: none". This could be accomplished with: # Removes the "Range" and "If-Range" from the request headers RequestHeader unset Range RequestHeader unset If-Range # Removes all "Accept-Ranges" from the response headers Header unset Accept-Ranges # Sets "Accept-Ranges: none" to the response headers Header set Accept-Ranges none (I'm not sure if the "Header unset Accept-Ranges" is even necessary.) According to the HTTP 1.1 specification RFC 2616: * "Servers that do not accept any kind of range request for a resource MAY send 'Accept-Ranges: none'" (section 14.5); and * "A server MAY ignore the Range header" (section 14.35.2). But clearly this is only a work-around. released in 2.2.20, just needs a 2.0 release to close I guess. (In reply to comment #3) > released in 2.2.20, just needs a 2.0 release to close I guess. any news on a 2.0.x fix ? revert OS change. |
Created attachment 27429 [details] DoS Exploit for mentioned vulnerability At least apache 2.2.17 has a remotely exploitable dos vulnerability which allows to consume all memory on a target system. A request for triggering the memory consumption includes a large "Range" header which requests as many different bytes as possible from a file served by httpd. Combining this with a gzip "Accept-Encoding" header the httpd is assumed to compress each of the bytes requested in the Range header seperately consuming large memory regions. The behaviour when compressing the streams is devestating and can end up in rendering the underlying operating system unusable when the requests are sent parallely. Symptomps are swapping to disk and killing of processes including but not solely httpd processes. How to repeat: Execute the attached perl script for a vulnerable httpd, means Byte Range filter and mod_deflate/mod_gzip enabled. Sidenote: Apache should be aware of that through posting to full disclosure. Nevertheless should in my opinion this bug be resolved.