PCI compliance Apache versions

Question

We are working with current version of Apache 2.4. 6 available in a Centos 7 repos. Installed with yum.

and we are dealing with the PCI compliance and the report says:

IP Address: x
Host: x
Path: 

THREAT REFERENCE

Summary: 
vulnerable Apache version: 2.4.6

Risk: High (3)
Port: 443/tcp
Protocol: tcp
Threat ID: web_server_apache_version

Details: Apache HTTP Server mod_proxy_fcgi Response Handling Vulnerability
11/21/14
CVE 2014-3583
Apache HTTP Server before 2.4.11 is prone to a vulnerability,
which can be exploited to cause a DoS (Denial of Service).
The vulnerability exists due to an overflow condition in mod_proxy_fcgi.
when handling responses from FastCGI servers. The vulnerability can be exploited by
sending a crafted response from a malicious FastCGI server, which could lead to a 
crash when reading past the end of a heap memory. 
Apache HTTP Server NULL Pointer Dereference Vulnerability
10/08/14
CVE 2014-3581
Apache HTTP Server 2.4.10 and earlier is prone to a vulnerability,
which can be exploited to cause a DoS (Denial of Service).
The vulnerability exists because the application contains flaw in
the cache_merge_headers_out() function which is 
triggered when handling an empty 'Content-Type' header value. 
Multiple Vulnerabilities Fixed in Apache HTTP Server 2.4.10
07/24/14
CVE 2014-0117
CVE 2014-0118
CVE 2014-0226
CVE 2014-0231
CVE 2014-3523
Apache HTTP Server before 2.4.10 is prone to multiple vulnerabilities,
which can be exploited to cause a DoS (Denial of Service).
The vulnerabilities exist because the application contains flaw in 
mod_proxy, mod_deflate, mod_status, and mod_cgid modules and
in the winnt_accept function of WinNT MPM. 
Note: the WinNT MPM denial of service vulnerability can only
be exploited when the default AcceptFilter is used.
Apache HTTP Server Two Denial of Service Vulnerabilities
03/19/14
CVE 2013-6438
CVE 2014-0098
Apache HTTP Server before 2.4.9 is prone to two vulnerabilities,
which can be exploited to cause a DoS (Denial of Service).
The first vulnerability exists due to an error in the mod_log_config module when logging 
with truncated cookies. The second vulnerability is due to a boundary error in the mod_dav 
module when removing leading spaces.
HTTP-Basic Authentication Bypass Vulnerability
08/14/09
Apache 2.2.2 and prior are prone to an authentication-bypass vulnerability 
because it fails to properly enforce access restrictions on certain requests to a site that requires authentication.
An attacker can exploit this issue to gain access to protected resources, 
which may allow the attacker to obtain sensitive information or launch further attacks.
Apache HTTP Server OS Fingerprinting Unspecified Security Vulnerability
11/03/08
Apache 2.2.9 and prior is prone an unspecified security vulnerability.

Information From Target:
Service: https
Received: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.6.13

We update the server once a week "yum update"

but when i do: rpm -q --changelog httpd | grep CVE i can see this:

• core: fix chunk header parsing defect (CVE-2015-3183) and ap_force_authn hook (CVE-2015-3185)
• core: fix bypassing of mod_headers rules via chunked requests (CVE-2013-5704)
• mod_cache: fix NULL pointer dereference on empty Content-Type (CVE-2014-3581)
• mod_cgid: add security fix for CVE-2014-0231 (#1120608)
• mod_proxy: add security fix for CVE-2014-0117 (#1120608)
• mod_deflate: add security fix for CVE-2014-0118 (#1120608)
• mod_status: add security fix for CVE-2014-0226 (#1120608)
• mod_cache: add secutiry fix for CVE-2013-4352 (#1120608)
• mod_dav: add security fix for CVE-2013-6438 (#1077907)
• mod_log_config: add security fix for CVE-2014-0098 (#1077907)

How can i apply the patches that the security scan is asking for? i cannot find rpms to do it.

thanks in advance.

Regards.

Answer 1

This is one of the problems (or benefits depending how you see it!) of using package managers.

On the one side they are typically older versions of apps so are open to vulnerabilities (as well as not having the latest features) but on the other hand they are stable. However a lot of vendors (including Red Hat, and CENTOS which is based in that) typically back port necessary fixes to these versions but this might not be obvious to vulnerability scan.

It could be argued that a report like yours is a bit lazy in that they assume you have not applied patches purely based on version number when it could easily be seen that (or asked if) you use a package manager and then could be tested to see if it has applied the patches. Then again it depends how the scan was done and how they determined the versions you were on. If they had access to your servers then I'd say they could have confirmed this. If they did this by any other way such as based on your HTTP Headers you return then I would say they cannot verify if you have patched so they are right to raise (and btw as an aside you probably shouldn't be returning specific version numbers in your HTTP Headers if you are!).

Finally you should realise this report is often a list of possible issues and you are fully within your right to go back with evidence of how you believe those issues have been addressed or mitigated - such as the evidence you have given in your question and the fact you have a regular patching schedule... Etc. There is still a risk here (e.g. for any risks that come out between patches and/or if you forget to patch for a long while) and any report is right to highlight that risk, but they normally reduce errors to warnings on a report to highlight this as a reduced risk.