In 2007, a Google engineer, Michal Zalewski, published a memo detailing a potential vulnerability of both Apache and IIS Web Servers after investigating the HTTP/1.1 "Range" header implementation. He reported then:
it is my impression that a lone, short request can be used to trick the server into firing gigabytes of bogus data into the void, regardless of the server file size, connection count, or keep-alive request number limits implemented by the administrator. Whoops?
A proof of concept for the Apache DDoS tool was published as a Perl script on the August 19 ”Full Disclosure” security mailing list. On August 24, the Apache Security Team published a memo explaining:
It most commonly manifests itself when static content is made available with compression on the fly through mod_deflate - but other modules which buffer and/or generate content in-memory are likely to be affected as well. This is a very common (the default right!?) configuration.
The attack can be done remotely and with a modest number of requests leads to very significant memory and CPU usage.
Active use of this tools has been observed in the wild.
There is currently no patch/new version of apache which fixes this vulnerability. This advisory will be updated when a long term fix is available. A fix is expected in the next 96 hours.
On Friday, Apache published a second advisory in which they explain how Apache httpd and its so called internal 'bucket brigades' deal when a server processes a request to return multiple (overlapping) ranges; in the order requested. A single request can request a very large range (e.g. from byte 0- to the end) 100's of times in a single request. Currently this kind of 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. There are several immediate options to mitigate this issue until a full fix is available.
Apache's mitigation strategies ranged from completely disallowing the Range header, to limiting the size of requests, to deploying a custom Range counting module. Lori MacVittie detailed how the mitigation strategies could be implemeted with Big-IP.