I recently became aware of a serious issue in Apache that has started to gain some notoriety over the last few days.   This vulnerability allows people to commit a very simple and effective DoS attack against most Apache servers out there.  Just to clarify how effective this attack is, I was able to take down a a decently powered web server in just a few seconds with an attack that could easily be carried out on a cheap laptop.  To clarify a little further, when I say “take down”, I’m not talking just about Apache.  The attack causes Apache to take up all of the physical memory and start going right into the swap space.  At this point, the whole server will become unresponsive and may even need to be rebooted.

The vulnerability stems from the way that Apache handles range headers.  These headers allow the client to request specific parts of the document, rather than the whole file.  This type of request is often used with download managers, media streaming, and PDF readers.  Unfortunately, Apache is not very picky about how it responds to requests for multiple ranges, and this can be exploited by requests that have many sets of overlapping ranges.  Apache will dutifully respond as best as it can, consuming a lot of processing and memory in the process.  It doesn’t take many of these abusive requests to take up all of the available resources on the server, which is why this attack can be so devastatingly easy to carry out.  This problem has been in Apache for a long time and was even discovered several years ago.  However, last week, someone decided that it was time to publicize it a little more.  The result was a Perl script, appropriately named “Apache Killer”.  This script basically sends these abusive range headers in multiple concurrent requests.  Running the script with 50 threads is suggested, which as I mentioned before, is more than sufficient to take down even the most powerful servers in a matter of seconds.  I have attached the text of this script for those who are interested in using it for testing their systems.

So now that I have pointed out how serious this issue is, the question is what can be done about it?  Fortunately, ASF released a new version of Apache, which fixes this issue by essentially ignoring the range header if the total range exceeds the size of the document requested.  This is the ideal fix, but it will probably involve downloading and compiling the server manually, as it will probably take awhile for it to show up in repos.  A simpler, but more ham-handed way of fixing the issue is configuring Apache to not accept the range headers at all.  This will cause issues with download managers and other special clients, but it will certainly stop any chance of this attack happening. Personally, I have found that the best solution is something of a compromise between the two I already mentioned.  Basically, this solution involves adding the following lines to your main Apache configuration:

          SetEnvIf Range (?:,.*?){5,5} bad-range=1
          RequestHeader unset Range env=bad-range
          RequestHeader unset Request-Range

This configuration will unset the range header if more than five ranges are sent, which is unlikely to happen in a legitimate request.  However, it is important to remember that it is possible for a legitimate request to have more than a few ranges, so you may need to adjust that number to fit your situation.  This should also only be used until you are able to update Apache, which has provided a more elegant solution.