1

A PCI compliance scan, on a CentOS LAMP server fails with this message. The server header and ServerSignature don't expose the Apache version.

Apache httpOnly Cookie Information Disclosure CVE-2012-0053

Can this be resolved by simply specifying a custom ErrorDocument for the 400 Bad Request response? How is the scanner determining this vulnerability, is it invoking a bad request then looking to see if it's the default Apache 400 response?

Improve this question

4 Answers 4

Reset to default
1

This page suggests that it is mitigated by supplying a custom ErrorDocument and that it is resolved in Apache 2.2.22.

Your best bet for verifying this is to make your own ErrorDocument or upgrade Apache and run the scan again.

Improve this answer
1
  • I have set an ErrorDocument 400, is there any way to invoke a bad request to verify my custom doc is returned?
    – ServerBloke
    Mar 30, 2012 at 10:18
2

Just struggled with a similar issue. I think many people will start searching for Apache 2.2.22 these days, due to the new PCI requirement.

In my case it turns out upgrading to 2.2.3-63 would fix CVE-2012-0053. Check out: http://rpmfind.net/linux/RPM/centos/updates/5.8/i386/RPMS/mod_ssl-2.2.3-63.el5.centos.1.i386.html

So you might not need to upgrade 2.2.22.

Once you upgrade to 2.2.3-63 or later, you should receive your approval, if you do not receive the approval in your first submission, ask for a manual consideration on this particular issue and refer them to the patch you applied.

Here is a good question which is pretty similar: How to upgrade Apache from 2.2.3 to 2.2.21 Check out the answers there.

Improve this answer
2
  • thanks for the info. I ended up doing a full Apache upgrade to 2.2.22. I could not resolve the problem using a custom ErrorDocument because it turns out Apache will not serve a custom 400 doc for requests that are largely malformed (PCI scanner was sending a huge oversized cookie to invoke the 400).
    – ServerBloke
    Apr 5, 2012 at 16:43
  • That's good too. Just to let the other readers of this question know: We received our PCI confirmation today. 2.2.3-63 was approved without any issues.
    – Haluk
    Apr 5, 2012 at 18:33
2

Guys it is not true that the only way to fix this is by upgrading. All you need to do is ErrorDocument 400 "some message here"

Good Luck.

Improve this answer
1
  • I have tested this with Apache 2.2.2. Setting ErrorDocument 400 "Bad request" solves this issue and we were able to pass the PCI scan. Upgrading to 2.4.x is still better solution due to some big fixes to Apache in 2.4.x.
    – Sunil Karkera
    Sep 5, 2012 at 0:05
1

No, it is a moderate flaw in apache core itself. When getting malformed or long request apache exposes certain information about its version and operating system. This information hypothetically can be used by culprits to craft an attack on your server using any other know or unknown vulnerabilities in your operation system and server software. By itself it is not doing anything harmful, only telling curious minds little bit more than usually they should know. It can be resolved only by upgrading apache to version 2.2.22.

Improve this answer
3
  • I appreciate findind the Apache version is key info for an attacker. Is there any info to say it's still vulnerable even with a custom 400 response? Your link seems to suggest the vuln only exists with the default Apache 400 document.
    – ServerBloke
    Mar 30, 2012 at 10:21
  • Yes, it was reported that custom ErrorDocument 400 solves the issue. You can try to rerun the test and find out if it is true =)
    – Dada
    Mar 30, 2012 at 10:33
  • Turns out a custom 400 ErrorDocument doesn't solve this because Apache won't serve a custom 400 doc for largely malformed requests, such as huge cookies.
    – ServerBloke
    Apr 5, 2012 at 16:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .