1

Recently I need to care a lot of false positive vulnerabilities in scanner results on Apache version. Example of false positive vulnerability:

Apache 2.2 < 2.2.16 Multiple Vulnerabilities

Our customers run scanners and they check Apache version related to the official Apache version numbering.

We use Centos, and the Apache version numbering is different from the official Apache version numbering.

For example now we install httpd-2.2.15-26.el6.centos.x86_64 and it includes all security patches released by Apache in recent versions.

The Centos Apache version numbering relies on the RedHat Apache version numbering and they do not change the base number (httpd-2.2.15) each update. But scanners do not “understand” this and check that 2.2.15 < 2.2.16.

Can you point me to the good document that explains the RedHat Apache version numbering?

Do you know if exist scanner that “understand” the RedHat Apache version numbering?

3

What you're experiencing is a common problem. Vulnerability scanners that rely upon service banners do not deal with vendors like Red Hat which backport security updates. They are also prone to making assumptions about configuration that lead to false positives.

You may be able to improve the accuracy of the scan by running an credentialed scan. If your scanner supports it, you can specify account credentials that it will use to log in and look at "internal" information. For example, it can use 'rpm' to determine which actual Apache package is installed, and base its verdict upon that rather than the banner that the service prints to external scanners. Such a scanner should have access to an up-to-date database that will tell it what the real issues are.

If your scanner won't do it, then the usual solution is to do it yourself. You would need to look up whether you're running the newest version. For example, @Rook points out that there are Apache vulnerabilities newer than the package you reference. Looking at those vulnerabilities, you can pull the CVE ID and look it up in Red Hat's CVE Database. For example, their entry for CVE-2013-1862 points you to the errata RHSA-2013:0815 which says that httpd-2.2.15-28 contains fixes for that CVE. It also points out that there's a newer RHBA release, so there's a newer package with bug (but not security) fixes. Repeat that process for any other CVEs that you're concerned with and you can make an educated decision about whether you're patched despite what the banner says. If the CentOS package is a direct correlation to the RHEL package, you should be fine - but the RHEL package was announced on 5/13, so I don't know how @Rook's cited 3/2 release date jibes with that.

(The shortest version, BTW, is "yeah, this stuff is a known PITA.")

1

All security tools produce false positives, and this should not be treated any differently. If you are having trouble with this report, I suggest seeking a different approach to testing, perhaps one that isn't dependent on a broken tool.

That being said httpd-2.2.15-26.el6.centos.x86_64 was released on March 2nd 2013, and there have been a couple of vulnerabilities found in Apache since March 2nd. It would be best to manually verify that you are not affected by these exposures.

  • Thanks, but it is our customers run scanners. I need to provide them a good explanation about Apache numbering. – Michael Dec 27 '13 at 17:20
  • @Michael but can you prove that this isn't a vulnerable version? CentOS has never impressed me... – rook Dec 27 '13 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.