Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fix For Apache DoS Bug In the Pipes

Posted by timothy on from the gurgling-through dept.

Trailrunner7 writes with the report that "The Apache Software Foundation plans to have a fix available in the next day or so [Note: that means today, now. --Ed.] for the denial-of-service problem in Apache that was publicized late last week. The bug, which in some forms has been under discussion for more than four years, involves the way that the Web server handles certain overlapping range headers. The vulnerability is a denial-of-service bug, but it is considered serious because a remote attacker can essentially take a targeted server offline with little effort and resources. The Apache Software Foundation, which maintains the popular open-source Web server, updated its advisory on the vulnerability, saying that it expects to have a full fix available for the vulnerability within the next 24 hours."

11 of 49 comments (clear)

  1. Apache has an excellent security record. by Anonymous Coward · · Score: 4, Interesting

    The one thing that I've found really astounding about this whole ordeal is how despicably some members of the open source community have acted towards Apache and its developers. The pure hatred they have spewed is absurd. For such a large and widely-used piece of software, Apache has a superb record of being secure and reliable. The ridicule it has received lately, especially from the open source community, is disheartening.

    Somewhat surprisingly, this criticism has been coming from PHP, Ruby and JavaScript programmers. Many of these people likely don't even know C. Yet they still feel it necessary to belittle the Apache developers for making what is actually a very obscure mistake many years back. Of course, these people delivering the criticism won't admit that their own software is far buggier and insecure than Apache. The developers of PHP would never break a critical security-related function like crypt(), right?

  2. Not just an Apache bug by Kickasso · · Score: 5, Insightful

    It's a protocol bug. Any server that implements the protocol to the letter is vulnerable. And it's not just about overlapping ranges. If the server can send a ten megabyte file, an attacker can ask it for ten million of one-byte ranges. The processing overhead will bring most servers to their knees. If the server can compress the output, an attacker can ask for ten million of compressed one-byte ranges. An attempt to execute such a request will kill just about anything. The protocol should have limited the number of ranges per request to, say, 10.

    1. Re:Not just an Apache bug by raynet · · Score: 2

      It all depends how you implement it but yes, it would have been wiser to let the server discard some of the ranges if needed and ask the client to do another request later.

      --
      - Raynet --> .
    2. Re:Not just an Apache bug by amorsen · · Score: 2

      The protocol does not require the server to answer at all. The server can just send an error response if it gets too many ranges in a request. The protocol designers cannot know how many resources a given server has available. The most they could do was add a specific error response for "too many ranges, resubmit as individual requests".

      --
      Finally! A year of moderation! Ready for 2019?
    3. Re:Not just an Apache bug by perlchild · · Score: 2

      If Apache doesn't return an error code it will have to keep the connection open, and you're back at the "consuming so many resources it's denying legitimate traffic" part of the denial of service.

    4. Re:Not just an Apache bug by jevan · · Score: 2

      Apache's implementation problems go beyond the protocol specs. The sample attack codes includes invalid ranges in the request (E.g start at 5, end at 0). So the protocol specs aren't the only thing to blame. Also, the fact that apache is the only server to be crippled by this issue is a strong data point against putting all blame on the protocol.

    5. Re:Not just an Apache bug by ivoras · · Score: 2

      65535 connections for TCP (minus a few) per server...

      To be pedantic, that's 65535 per (client_ip,port) pair...

      --
      -- Sig down
    6. Re:Not just an Apache bug by Kickasso · · Score: 2

      How did you test? nginx does honor Range requests. The Apache killer will report that nginx not vulnerable, so what, it misreports PHP-based Apache installations too. However, this attack can be performed in more than one way. Maybe you should know that nginx maintainers have released a patch today. I wonder why.

      I have read that IIS is vulnerable to this too, not sure if this is true, I have no IIS installations that I can check.

      I'm not sure what Cherokee does so I can't comment here.

  3. Offensive by Anonymous Coward · · Score: 2, Interesting

    From the article:

    "This problem is so obvious, my grandmother could identify it."

    As a 49 yo grandmother, C programmer of 20+ years, and a feminist this offends me. They wouldn't have said grandfather.

  4. Re:I hear... by digitalchinky · · Score: 5, Informative

    I am utterly lazy, but a few moments in google and I added the following to my domains:

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
    RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
    RewriteRule .* - [F]

    It certainly makes the exploit fail which is good enough for me until Apache gets a fix going.

  5. Re:I hear... by thebjorn · · Score: 2

    Request-Range is also affected, better turn it off: RequestHeader unset Request-Range