PCI Compliance And Back Ports

I was recently hired to do a PCI compliance scan and complete the remedial work to bring it up to standard. This was on a CentOS5 box. The tool I was using to do the scanning was pretty good, but like all scanning tools plays “the numbers game.” This means it simply looks at the versions of certain services and flags it if that version is known to be vulnerable. In my case, Apache and PHP were causing the most red flags. There were some XSS (cross-site scripting) vulnerabilities addressed in Apache 2.2.8 and my server header was showing 2.2.3. PHP was the same story, with several DoS and code execution vulnerabilities fixed in 5.2.7, and I was apparently running 5.2.6. Obviously vulnerable, right? No and yes. I’ll explain why this is the case, and how you can tell what you’re really vulnerable to.

Linux distributions such as Red Hat (RHEL, Fedora, CentOS) sometimes rely on “back ports” or patching the existing version of the service, fixing the hole without updating the version number. This means a lot of false positives on the scan, which you can clear up with the rpm tool, grep and a web browser. Let’s start with Apache – the scanner says I am running 2.2.3, which is obviously vulnerable to some cross-site scripting (XSS) attacks. Being vulnerable to XSS is a PCI compliance fail. So I checked out the changelog for Apache 2.2 and saw that CVE-2008-2939 was fixed in version 2.2.10. We then run:

[root@steve ~]# rpm -q --changelog httpd | grep CVE-2008-2939
- add security fixes for CVE-2008-2364, CVE-2008-2939 (#468840)

This shows that someone from RedHat applied the patch to fix this vulnerability, but the version number wasn’t updated. This is a clear false positive. If you don’t find the CVE number listed in the changelog, pipe the output to less and look for anything mentioning the affected module or an upgrade to a version that includes the fix. For example, in my case, PHP 5.2.7 fixed a bunch of security problems in prior versions, some of which are a PCI fail.

When I looked through the PHP rpm changelog, the last thing I found was the update to 5.2.6 with no mention of 5.2.7 or patches for the issues addressed. Checking out the PHP changelog showed a lot of security fixes for 5.2.7. I ended up using a PHP 5.2.8 rpm from atomicrocketturtle.com which included the fixes. Using a third-party repository isn’t particularly ideal, but given the choice between that and either building from source or applying patches to a source rpm, I picked the third-party.

A few final thoughts:

  • You may find it easier to disable a module or service than patch it. If a module or service isn’t required, then disable it. This is good security practice.
  • For those services that are only required locally, such as database and mail services, bind them to the localhost interface and firewall them.
  • Don’t put all your faith in automated scanning – they are a tool, not an absolute solution. You will need to go through the results yourself, or hire someone to help you.

If you’re looking to hire someone to set up a PCI compliant LAMP stack or audit an existing one, please contact me for an estimate.