Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Bug Security The Internet Apache

Fix For Apache DoS Bug In the Pipes 49

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Fix For Apache DoS Bug In the Pipes

Comments Filter:
  • by Anonymous Coward on Saturday August 27, 2011 @08:46AM (#37227160)

    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?

    • Offensive (Score:2, Interesting)

      by Anonymous Coward

      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.

      • by Anonymous Coward
        Calm down dear. They were simply taking an example of someone who isn't good with computers, which in most people's cases could equally be the grandfather.
    • 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

      Let me ask, is mixing free and non-free software acceptable to you? The FLOSS community promotes using open source above all else, for the sake of more people using open source. If "shut up if you can't program" was their motto, its user base should be a tiny fraction of what it is. Unless you think people like being told to "shut up and use it anyway."

      You wouldn't DARE tell me, not-a-programmer, use open source "just because", and do not complain about it, in anything short of suicidal fantasies. UNIX

      • by bgat (123664)

        Grow up folks, buy software when it works.

        You let me know how that works out for you.

        In particular, I'd love to know what browser you are using to produce your rant, cause I'm not aware of any browser implementation available today that "works" in the manner you suggest they should.

        In the meantime, I'll stick with what "reasonably works, and coincidentally works better than the commercial alternatives". You know, like, Apache.

    • by bonch (38532) *

      Your entire post is basically that you don't like seeing Apache criticized on message boards. So what? You even end with a pointless remark about programmers you assume don't know C, as if that has anything to do with anything. Apache brought criticism onto themselves. The bug is more than four-and-a-half years old.

      • Apache brought criticism onto themselves. The bug is more than four-and-a-half years old.

        This memory allocation bug is distinct from Zalewski's bandwidth multiplying bug.

        Indeed, both stem from "silly" Range handling, but they are still different bugs. I.e., the bug is not 4+ years old.

  • by Kickasso (210195) on Saturday August 27, 2011 @08:46AM (#37227164)

    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.

    • by Jamu (852752)
      Obviously Apache isn't doing so at the moment, but is there any reason it couldn't just take a long time to fulfil the request?
      • by perlchild (582235)

        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.

        • by tepples (727027)

          If Apache doesn't return an error code it will have to keep the connection open

          What part of the HTTP spec bans issuing a 400 Bad Request when something looks like a DoS? And is there a reason why Apache can't hand off thousands of connections to a separate, lightweight "penalty box" server process?

          • 65535 connections for TCP (minus a few) per server... as long as each connection stays open, poof, no more room at the inn.
            • I was thinking on the order of 10,000 connections handled by the penalty box. A server under attack might randomly choose to use 400 Bad Request, use 503 Service Unavailable, or handle the connection slowly, with the frequency of error-code responses increasing as the penalty box fills up.
            • by ivoras (455934)

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

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

    • by raynet (51803)

      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.

    • by amorsen (7485)

      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".

    • by jevan (104286)

      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.

  • the sound of millions lazy sysadmins compaining!

  • This is the main exploit used by the Jester for attacks on Apache servers?
  • Next 24 hours puts this fix release on Sunday. I, myself, can't wait to let my Apache source compiles rip upon release.

    All jokes aside, what baffles me is even if you're clueless when it comes to Apache webserver security, there's plenty of best practices out there, especially using mod_security with some tuned SecRule's. The mitigation steps Apache provided (using mod_rewrite) almost identically mirror the out-of-the-box SecRule's provided at gotroot.com [gotroot.com]. This isn't a soapbox plug, I just think that thi

    • by Anonymous Coward

      Yeah, once this hits our change control procedures - gets through an internal review or three, jumps through our unreliable release process (after getting munged by several git merge conflicts) it'll fly right on out to our 2k machines RSN. Oh yeah, did I mention how we wouldn't be bothering to test to make sure it doesn't cause any problems in QA?

"Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John Von Neumann

Working...