PCI - Failure Report On CVE Vulnerabilities

Question

I received a bunch of CVE failures from a PCI scan that was done. Is my server insecure? 

Answer

Probably not.  Especially if the Common Vulnerabilities and Exposures (CVE) Identifier is old.  Most CVE's start with the year, so if you see CVE-2016-XXXX then chances are this is not an issue for you.  The PCI scanning company you are using is basing these purely off the version number of the software you're running.  

Both CentOS and CloudLinux operating systems are based on Red Hat Enterprise Linux (RHEL).  Redhat uses backporting for much of the software installed on the server, including but not limited to the kernel, bind, openssh, openssl, etc...   Backporting allows the operating system vendor to change (or patch) only the parts of the software that are directly affected by the vulnerability listed in the CVE.  In this way, it avoids the introduction of new features that developers may not have tested.  This process does not update the version number, so if a PCI vendor is only basing their report on the version number, then this is why you may receive a report stating your server is vulnerable.  

In many cases, you can simply check the changelog within RPM to see if the CVE is patched.  Let's check one as an example.  Let's use CVE-2016-1285 which is for BIND.  This was a denial of service flaw in the way BIND processed certain control channel input. A remote attacker was able to send a malformed packet to the control channel and could use this flaw to cause the name daemon (named)  to crash.

Checking the RPM changelog is easy.  Here's the command: 

# rpm -q --changelog bind | grep -1 'CVE-2016-1285'
* Tue Mar 08 2016 Tomas Hozza <thozza@redhat.com> - 32:9.9.4-32
- Fix CVE-2016-1285 and CVE-2016-1286

As you can see, the vulnerability was indeed patched.  

For Ubuntu, there is no RPM command so you would instead search the changelog using grep. The changelog is compressed so you would use zgrep.

# zgrep -E 'CVE-2020-8625' /usr/share/doc/bind9/changelog.Debian.gz
- debian/patches/CVE-2020-8625.patch: properly calculate length in
- CVE-2020-8625

OK, so what about if there is no entry in the changelog?

It does happen.  You may not find an entry in the changelog.  That still does not mean you are vulnerable though.  In those rare situations, you would need to check the RHEL website for that CVE to see if you are in fact affected or not.  For example, the CVE-2016-2853 vulnerability states that the aufs module for the Linux kernel 3.x and 4.x does not properly restrict the mount namespace, which might allow local users to gain elevated privileges by mounting an aufs filesystem on top of a FUSE filesystem.  

You won't find this in the changelog.

# rpm -q --changelog kernel | grep -1 'CVE-2016-2853'
# 

Why?  Because Red Hat Enterprise Linux developers have determined that they are not affected by this vulnerability.  See: CVE-2016-2853

For Ubuntu, you can visit https://ubuntu.com/security/CVE-2020-8625 for an explanation of the vulnerability and what (if anything) needs to be done. 

In those situations, you would simply show this information to your PCI vendor and let them know your kernel is not vulnerable.  

The information is briefly discussed in our documentation here: PCI Compliance and Software Versions