Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache Request Smuggling Vulnerability Found

Posted by CowboyNeal on from the web-jacking dept.

An anonymous reader writes "Whitedust is reporting on a HTTP request smuggling vulnerability in Apache. The flaw apparently allows attackers to piggy back valid HTTP requests over the 'Content-Length:' header, which can result in cache poisoning, cross-site scripting, session hijacking and other various kinds of attack. This flaw affects most of the 2.0.x branch of Apache's HTTPD server."

7 of 168 comments (clear)

  1. Fix-patch in 5...4...3... by Atario · · Score: 3, Insightful

    After all, it is Apache server.

    Anyway, it'll get a fix available likety-split. Go, OSS!

    --
    "A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
  2. Where to get fix... by seneces · · Score: 5, Insightful

    According to securityfocus, this bug does affect the 2.0.x branch as well as 2.1.x. It says that the 2.1.x version has been released to fix, and that a fix is available in the subversion repository for 2.0.x. I'd suspect that there will be a new version of 2.0.x out soon.

    Securityfocus article is here.

  3. eh? by Anonymous Coward · · Score: 5, Insightful

    How can request smuggling affect ONE product? I thought the attack was based on the different ways TWO or MORE different products interpret the same HTTP request.

    Example:

    Product A (web server) uses the FIRST content-length header.

    Product B (application server) uses the LAST content-length header.

    So you include two content-length headers, to slip by A and attack B.

    Replace A and B with whatever proxying whatever setup you can think up.

    So how does Apache by itself have this problem, and how can apache by itself SOLVE the problem?

    Btw, this is a great example of why "be liberal in what you accept" is BS. You should reject all out-of-spec data.

  4. .. so this is an apache vulnerability now. by drspliff · · Score: 5, Insightful

    Sure, this effects Apache, but this also effects just about all web servers where the request is first filtered through a cache or proxy...

    What we don't need is people running around like headless chickens screaming 'omg dat aprache server got r00ted.. wher3s the sploit!' as 90% of Apache servers on the internet will be completely uneffected by it.

    It seems the poster didn't read the (very intresting) Watchfire paper before submitting. And editors... do your job, otherwise you'll soon be replaced by monkeys trained to click the 'Accept Article' button all day.

  5. Re:Wait a sec.. by CaptainZapp · · Score: 1, Insightful
    The latest "bleeding-edge" version is often actually more stable.

    I think that the Debian folks may have an issue with this statement.

    --
    ich bin der musikant

    mit taschenrechner in der hand

    kraftwerk

  6. Re:Patch Available by HaydnH · · Score: 1, Insightful

    Damn you! I just tried that patch and now my security has plummeted!! Especially as I had to install Windows to get it to run!

    --
    Time is an illusion. Lunchtime doubly so. - Douglas Adams
  7. Re:Wait a sec.. by rylin · · Score: 2, Insightful

    I'm not sure what kind of company you work at, but we take precautions when upgrading software.
    For instance, we take a backup of the affected software before installing the new version.

    In other words; yes, I'd rather have my company's webserver down for the minute or two it takes to restore the recently-made backup, instead of having to worry about whether or not someone is trying to compromise our web platform.

    Maybe that's just me though?