Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams
Byte Range Filter might consume huge amounts of memory combined with compress...
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: All
2.2.17
All All
: P2 critical (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-08-24 00:49 UTC by kingcope
Modified: 2014-03-20 15:21 UTC (History)
2 users (show)



Attachments
DoS Exploit for mentioned vulnerability (1.82 KB, application/octet-stream)
2011-08-24 00:49 UTC, kingcope
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kingcope 2011-08-24 00:49:57 UTC
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.
Comment 1 kingcope 2011-08-24 03:32:01 UTC
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.
Comment 2 Mikko Parviainen 2011-08-26 10:13:11 UTC
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.
Comment 3 Eric Covener 2011-09-03 17:58:08 UTC
released in 2.2.20, just needs a 2.0 release to close I guess.
Comment 4 akuster 2011-09-13 17:24:15 UTC
(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 ?
Comment 5 Eric Covener 2014-03-20 15:21:26 UTC
revert OS change.