Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Apache

Apache Warns Web Server Admins of DoS Attack Tool 82

CWmike writes "Developers of the Apache open-source project warned users of the Web server software on Wednesday that a denial-of-service (DoS) tool is circulating that exploits a bug in the program. 'Apache Killer' showed up last Friday in a post to the 'Full Disclosure' security mailing list. The Apache project said it would release a fix for Apache 2.0 and 2.2 in the next 48 hours. All versions in the 1.3 and 2.0 lines are said to be vulnerable to attack. The group no longer supports the older Apache 1.3. 'The attack can be done remotely and with a modest number of requests can cause very significant memory and CPU usage on the server,' Apache said in an advisory. The bug is not new. Michal Zalewski, a security engineer who works for Google, pointed out that he had brought up the DoS exploitability of Apache more than four-and-a-half years ago. In lieu of a fix, Apache offered steps administrators can take to defend their Web servers until a patch is available."
This discussion has been archived. No new comments can be posted.

Apache Warns Web Server Admins of DoS Attack Tool

Comments Filter:
  • Algorithmic complexity attacks (of which this is an example) are nothing new. They have been done on really bad sorting algorithms (quick sort, which is still defended by quite a few people that simply do not get it or are not bright enough to implement the alternatives) and are today employed, e.g., against hash-tables. Libraries/languages by people with a clue (e.g. LUA), have protection against that. Others do not.

    Writing secure code is a bit harder than writing merely working code. I guess people have t

    • by BitHive ( 578094 )

      Sadly, idiots (of which the the folks that codeed Apache are an example) nothing new. Their mediocrity has long suffocated us bright folk, many of whom are too timid to call these people what they are: pathetic failures. Others, like yourself, are not.

      Achieving perfection is a bit harder than merely rewriting flawed code. I guess people have to experience humiliation over and over again...

    • There are still people who didn't switch to introsort?

  • Quickfix (Score:4, Informative)

    by pasv ( 755179 ) on Wednesday August 24, 2011 @08:00PM (#37199240) Homepage
    http://www.gossamer-threads.com/lists/apache/dev/401638 [gossamer-threads.com] -- someone has got a patch. Keep those fast moving script kittens at bay
  • Imagine the anti-Microsoft shitstorm around here if this was an IIS attack tool.

  • by CajunArson ( 465943 ) on Wednesday August 24, 2011 @08:07PM (#37199324) Journal

    All versions in the 1.3 and 2.0 lines are said to be vulnerable to attack. The group no longer supports the older Apache 1.3.

    Since Slashdot is still stuck in the late '90's with a thin veneer of bad javascript, over apache 1.3 it's vulnerable... and no patch either.

    • Oh and before you say that Malda & crew will do a deep code analysis of the 1.3 branch and fixit themselves:
                    1. They're STILL RUNNING 1.3!!
                    2. Slashcode... QED.

    • by antdude ( 79039 )

      So someone could use this exploit and take /. down. :(

      • by gl4ss ( 559668 )

        maybe they patched it. or maybe they filter the vuln. before it hits apache, it seems that it's just about asking for a large number of ranges in a head request.

  • A quick summary (Score:5, Informative)

    by rabtech ( 223758 ) on Wednesday August 24, 2011 @08:47PM (#37199826) Homepage

    A quick summary: A client can use byte range requests that are overlapping and/or duplicated to use a single small request to overload the server. eg: 0-,0-,0- would request the entire contents of the file three times. YMMV but this has to do with how Apache handles the multipart responses consuming memory and isn't an actual bandwidth DoS.

    Unfortunately there are legit reasons for allowing out-of-order ranges and multiple ranges, such as a PDF reader requesting the header, then skipping to the end of the file for the index, then using ranges to request specific pages. Another example was a streaming movie skipping forward by grabbing byte ranges to look for i-frames without downloading the entire file.

    So the fix discussion centers on when to ignore a range request, when can you merge ranges, can you re-order them, can you reject overlapping ranges and how much do they need to overlap, etc. The consensus seems to be that first you merge adjacent ranges, then if too many ranges are left OR too many duplicated bytes are requested then the request skips the multi-part handling and just does a straight up 200 OK stream of the whole file or throws back a 416 (can't satisfy multipart request).

    • Shouldn't the fix just be that Apache calculate the _total_ size requested by the client, and if that crosses some definable limit, knock back the request with a HTTP 4xx response ( "client demands too much" ) or a 5xx error ("we're not google") (if it wants to be polite)

      • Or one could gather range requests and create a merge list with no repeats and Apache should only keep 1 copy in memory, maybe if they have too many repeated requests for overlapping ranges the error could be "I'm sorry, could you repeat that please?"
    • by Anonymous Coward

      Worse than that... even requesting a lot of small ranges can overload the server. The example code (iirc) requested the range 5-,5-0,5-1,5-2,5-3,5-4...5-1299 repeatedly. The real killer though is accept-encoding gzip, which causes Apache to try to zip all of those tiny ranges. That's really what kills the server.

  • Not that bad (Score:5, Interesting)

    by Evets ( 629327 ) * on Wednesday August 24, 2011 @10:13PM (#37200570) Homepage Journal

    I read the advisory, chose a course of action, then it took about a minute to make my server not vulnerable. It's great that they made the disclosure.

  • by Anonymous Coward on Wednesday August 24, 2011 @10:36PM (#37200722)

    You can do a quick test with something like this:

    /bin/echo -en "HEAD / HTTP/1.1\r\nHost:localhost\r\nRange:bytes=0-,$(perl -e 'for ($i=1;$i<1300;$i++) { print "5-$i,"; }')5-1300\r\nAccept-Encoding:gzip\r\nConnection:close\r\n\r\n" | nc localhost 80

    If you're vulnerable, you should see a really ridiculously long Content-Length header, like 900k or so.

    Disabling mod_deflate or the equivalent prevents this behavior, but it's not clear that there isn't another exploit waiting to happen. A super quick fix is to kill the Range header entirely using mod_header, like so

    RequestHeader unset Range

    in your apache.conf or moral equivalent. For the most part, you can get away with not serving Range headers, and if you can't, you know it and don't need my advice on fixing this.

    • Just to add on to this, if your web server doesn't accept requests addressed to localhost or the ip address with a rewrite rule or for some other reason, then you may need to add in the hostname for that query rather than just using localhost for the headers.

      eg: echo -en "HEAD / HTTP/1.1\r\nHost:www.mydomainname.com\r\nRange:bytes=0-,$(perl -e 'for ($i=1;$i<1300;$i++) { print "5-$i,"; }')5-1300\r\nAccept-Encoding:gzip\r\nConnection:close\r\n\r\n" | nc localhost 80

      A couple of my servers have Limit o
    • by rabtech ( 223758 )

      Just wanted to point out that this does *not* depend on mod_deflate or mod_gzip. That makes the problem worse, but it is the fact that Apache sets up a lot of internal data structures to handle the "metadata" of the multi-part request. Even with compression disabled, you can still easily overload the server with comparatively fewer requests because you're asking Apache to setup thousands and thousands of multi-part buckets for each single HTTP request. It doesn't take very many requests to bring everything

  • I think Apache is just like all the other projects that grow too big ! The jewelry store [thomassabo-ebuy.com], welcome to go and have a look .
  • When I saw the headline, I thought Apache was going to warn retailers about selling HP touchpads...
  • has anyone noticed if mod_evasive disarms/mitigates this attack vector?

  • Exploit code and ways of testing the vulnerability seem to be addressed towards HTTP. Has anyone tested it against HTTPS yet?
    • HTTPS is still HTTP. There's just an SSL layer in between. If you want to interact with some HTTPS server, try using OpenSSL with the s_client option.
  • With the bug first reported over 4.5 years ago, this was entirely avoidable.

    http://seclists.org/bugtraq/2007/Jan/83 [seclists.org]

  • FY, Options -indexes on /var/www made my boxes safe against this attack.
  • The included Apache 1.3 on OpenBSD (heavily patched by the OpenBSD developers) appears not to be vulnerable [marc.info]. The Apache2 in the ports tree may well be, though.

  • Since we're discussing Apache anyway... I've used Apache for over a decade now. Right now I'm working on a Pyramid [pylonsproject.org] app and publishing it with mod_wsgi [google.com] on Apache 2.2, for no other reason than that I'm already familiar with Apache. Since this is a brand new project and will be running on its own dedicated server - and therefore doesn't have play nicely with any pre-existing web apps - I wanted to re-evaluate my decision. If you needed to publish a WSGI app today, what server would you use and why?

  • So...

    "... and said it would release a fix for Apache 2.0 and 2.2 in the next 48 hours."
    "... According to Apache, all versions in the 1.3 and 2.0 lines are vulnerable to attack."

    So dropping support for 1.3 I understand (EOL etc), but fixing 2.2 event though it isn't reported as vulnerable? which is it?
    • I figured it was two different points. The first being that they'd release a fix for 2.x, and the other a less than subtle "Update your goddamn software!" reminder.

  • I am glad they finally got to it, but if apache had told their bank that there was an issue with their account , I am sure they would have wanted their bank to do something right away about it, and not 4.5 years ago....you just have to hit them where it hurts...ddos their banks, not their servers.....

Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read.