Home / server / Questions / 375195
Accepted
ServerBloke
Asked: 2012-03-31 01:51:24 +0800 CST

Apache httpOnly Cookie Information Disclosure CVE-2012-0053

  • 772

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?

centos apache-2.2 security

4 Answers

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

    • 2

  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.

    • 2

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

    • 1
  4. Best Answer

    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.

    • 1