Forgot your password?
typodupeerror
Security Apache

"Apache Killer" Web Server Hole Plugged 48

Posted by samzenpus
from the shields-up dept.
CWmike writes "The Apache open-source project has patched its Web server software to quash a bug that a denial-of-service (DoS) tool has been exploiting. Apache 2.2.20, released Tuesday, plugs the hole used by an 'Apache Killer' attack tool. On Aug. 24, project developers had promised a fix within 48 hours, then revised the timetable two days later to 24 hours. The security advisory did not explain the delay."
This discussion has been archived. No new comments can be posted.

"Apache Killer" Web Server Hole Plugged

Comments Filter:
  • Isn't this serious enough to warrant a 2.0.65 release that patches this too? There are still some applications that won't support the 2.2 branch.
  • The fix is called 'Hiawatha'.

  • by robot256 (1635039) on Thursday September 01, 2011 @11:59PM (#37282572)
    Thanks to this post, my server, at least, is fully patched now. How many years will it be before all the production systems in the world have this installed?
    • by Anonymous Coward

      Sony doesn't have to worry about this bug. Everything over their is protected by their start of the art text-based captcha [sony.com]

      • Anyone who wants to put in a little effort to scan/parse the html produced can read the characters of that captcha? It's stunning that this is what Sony considers 'security'.
  • by mzs (595629) on Friday September 02, 2011 @12:27AM (#37282688)

    http://mail-archives.apache.org/mod_mbox/www-announce/201108.mbox/%3C85111090-501E-4C80-AA8F-DD11B94FDF7C@apache.org%3E [apache.org]

    * SECURITY: CVE-2011-3192 (cve.mitre.org)
      core: Fix handling of byte-range requests to use less memory, to avoid
      denial of service. If the sum of all ranges in a request is larger than
      the original file, ignore the ranges and send the complete file.
      PR 51714.

    I remember reading how people had all sorts of ideas like sorting the ranges, ignoring gaps of less than 80 bytes, noticing that it went afoul of the standard. Around the same time nginx also did a release with the approach of sending back the entire file if the sum of the ranges was more. That was so simple, and it's okay according to RFC 2616 a server MAY ignore the range header, so it's clever too! Glad all the memory handling was fixed-up too though.

  • I got bitten by this moving our SSL server from 2.2.9 to 2.2.20 - they changed the config processor and our SSL config broke.

    Apache claim that a given "stable" series will keep a constant ABI. They seem utterly unable to comprehend that config files count as part of the ABI. Note that binary modules work the same all the way across 2.2.x ... that doesn't help when a "nothing's changed" upgrade breaks stuff.

    The changes are typically tightening the rules and disabling technical violations of them. That's a noble aim, but you need to save it for the next version - you can't pull that shit midstream in a "stable" series!

    We previously got bitten by Apache's incomprehension on this point when we went from Tomcat 6.0.16 to 6.0.29.

    So, before upgrading anything "stable" from the Apache Foundation: Thoroughly test the result, and make sure you can back out at a minute's notice.

    • by asdf7890 (1518587)

      The changes are typically tightening the rules and disabling technical violations of them. That's a noble aim, but you need to save it for the next version - you can't pull that shit midstream in a "stable" series!

      If your configuration file contains violations of the rules then your configuration is at fault, not the change that tightens the implementation of those rules. By using a configuration that doesn't match the rules (despite the fact the implementation lets you get away with it) you are relying on undefined behaviour and can not expect any guarantee that the behaviour won't change even in a stable branch. Defined/documented behaviours should not change in a stable branch unless there are exceptional circumst

  • by jker (1967318)

    On Aug. 24, project developers had promised a fix within 48 hours, then revised the timetable two days later to 24 hours. The security advisory did not explain the delay."

    I don't get this part. Even if we everything in the previous statement, 2d + 2d + 1d = 5 days. The 24 was 9 days ago.

    What did I miss?

    Debian, on the other hand, gave a fix 5 days later (4 days ago), way before the upstream.
    http://www.debian.org/security/2011/dsa-2298 [debian.org]

  • I haven't looked at this fix in detail, but from the sounds of it, I'm not convinced that the fix is complete.

    The attacker, for example, could request 999,999 individual one byte ranges of a 1,000,000 byte document. In a partial range response, each individual partial range gets wrapped into a separate MIME entity. The response from the server is basically a multipart MIME document. There's significant overhead per MIME section. Each single byte of the document gets attached to a header that, perhaps would

    • by ledow (319597)

      As the fecking article says, the patch:

      "weeds out or simplifies requests deemed too unwieldy."

      Otherwise, it wouldn't be much of a patch because it wouldn't fix this problem at all.

Computers are unreliable, but humans are even more unreliable. Any system which depends on human reliability is unreliable. -- Gilb

Working...