BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

"Apache Killer" a DDoS using the Range HTTP Header

| by Jean-Jacques Dubray Follow 3 Followers on Aug 28, 2011. Estimated reading time: 1 minute |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT