Vulnerability Scans¶
If you handle payment details on your server, you’ve likely had to take part in the PCI circus and get an automated scan ran against your solution.
The scans check for common issues like software versions and unnecessary open ports, things that may point to deeper security issues on a server.
At the end of a scan, a PDF is generated that lets you know how you’ve scored and points out anything that needs changing before your server can be used for storing payment information. The issues that need resolving are typically flagged as critical
or high
.
Running one of these scans against a CentOS or Red Hat server will likely return a worrying amount of software outdated
issues, and the main point of this article is to let you know that it’s not as bad as it looks due to the Red Hat backporting policy
Backported fixes¶
Red Hat’s backporting policy is outlined on the link below:
https://access.redhat.com/security/updates/backporting/?sc_cid=3093
The gist of it is that due to Red Hat/CentOS being an enterprise, LTS style, operating system one of the main features is that the major version numbers that ship with a release won’t change for the duration. Just refusing to update packages isn’t really a viable option, as this would leave Red Hat systems vulnerable to any security issues found during the operating systems lifecycle. Instead, Red Hat take the security fixes from higher versions of the packages and include them in their own releases, whilst leaving out any new features that may change how the program fundamentally operates.
To illustrate this, here’s a fictitious example:
CentOS 5 launches with the package widgets
, running version 9.1.20
.
After launch of CentOS 5, a disclosure points out a number of vulnerabilities in widgets-9.1.20
and the widgets team push out a series of security patches.
Whilst they push out their updates, they take the opportunity to implement some new functionality that changes how widgets handles it’s plugins and call it widgets-9.2.0
This breaks a few of the older clients that interface with widgets-9.1.20
Instead of putting widgets-9.2.0
in the CentOS repositories, CentOS release a new package called widgets-9.1.21
that contains the security fixes but not the new plugin changes.
This way, CentOS can be sure that implementations of widgets will continue to work on CentOS 5.
Confusion arises when a PCI scan checks for the widget version. In that example, it would spot widgets-9.1.21
, see that it’s lower than widgets-9.2.0
and flag up that the version of widgets on that server hasn’t had critical security patches applied.
CVE Numbers¶
Each failure on a PCI report should come with an accompanying CVE number, in the following format:
CVE-1999-0067
These numbers relate to a vulnerability, which can be looked up here:
https://web.nvd.nist.gov/view/vuln/search
Our main reason for being interested in them is that we can crosscheck a CVE with Red Hat to see if the issue was resolved with a backport, or if we actually need to take action on it.
Each CVE can be checked against the Red Hat website https://access.redhat.com/security/cve/ like so:
https://access.redhat.com/security/cve/CVE-2014-0160
From that page, you can see that the vulnerability described in CVE-2014-0160
didn’t affect various versions of Red Hat, though to a PCI scan it would probably flag as a failure.
To rectify this with your scanning agency, simply sending them that Red Hat CVE page, the backporting link from earlier and the version of the software in question should be enough to get them to revoke the failure.
Checking against RPM¶
A quick way to check whether or not a package has had the backport applied is to view the change log of the package. On Red Hat-based operating systems you can use the below command where [PACKAGE] is the name of the package you would like to check.
rpm -q --changelog [PACKAGE]
You can then search through this by using the grep
command. For example to search whether or not PHP has had a backport applied for CVE-2016-1903 you would use the below command.
rpm -q --changelog php | grep CVE-2016-1903