CVE-2011-1092 on Centos / PCI DSS compliance

Question

A security scan of a client's site flagged up the fact that, since they were running PHP 5.3.3, they were vulnerable to CVE-2011-1092 (fixed in 5.3.6 and above).

Normally I'd say that backporting would have dealt with this, as their PHP has been backported over the years to 5.3.27, but there's no indication in the changelog that this specific CVE has been addressed.

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1092 and https://access.redhat.com/security/cve/CVE-2011-1092 indicates expressly that this issue hasn't been addressed in the version of PHP shipped with RHEL and Centos, because RHEL don't think it's a security issue.

That leaves the client with a dilemma - their PCI DSS compliance scanner company (Trustwave) won't accept RHEL's statement of "this is not a security issue", saying "Visiting [the RHEL page linked to above] appears to show that RedHat has not addressed CVE-2011-1092. Since this finding affects PCI DSS Compliance, it does need to be confirmed to have been addressed in some fashion."

Does anyone have any suggestions how to proceed on this? Is it possible to address the issue directly by patching the files in some way?

Thanks in advance, for any suggestions.

Answer 1

This is the way the PCI-DSS industry works - trained monkeys run automated scanning software against applications then jump up and down if it turns red. Attempting to reason with the monkeys serves no useful function as they only understand red and green. Don't get me wrong - the guys who wrote the code in most of these tools are very smart - but they are not the people you have to deal with. And unfortnautely the monkeys have been given a lot of power. The existence of an issue does not mean that the issue is exploitable.

In fairness to the monkeys, NIST put the risk as 'high'. But I agree with Redhat - the only way this could be exploited is by someone with access to the php code or if you pass user supplied values direct to lowe level functions.

If I were in your shoes then the first thing I'd do would be to check if the code uses shared memory at all - and if not add the relevant function to the disable_functions settings in php.ini. While proving that the bug is not exploitable by an attacker with the function enabled and in use in the code is difficult, it's provable that the bug cannot be exploited if the function is not accessible. Whether that will pacify the monkeys is another story of course.

Answer 2

The vulnerability only affects the function shmop_read(). You have the possibility to disable functions in the php.ini; if you do this and no errors are thrown, your code doesn't and can't use the function, so you are safe.