I'm trying to get PCI compliant and the PCI scanning company is flagging our Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 for CVE-2013-1635. According to http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.html the Ubuntu response is "We do not support the user of open_basedir" and all version have been marked as ignored.
I'm at a loss for what to do here. I've pointed my scanning company to this same URL, but they don't accept that as and answer.
What should I do?
Update
I do not use this functionality and the open_basedir directive is disabled in php.ini. However, they do not consider this a proper solution.
Here is their response to their denial of my dispute:
We have denied this dispute based on the information provided regarding how this finding has been addressed. The version of PHP that is currently running on this system has been found to not properly sanitize user-supplied input. Despite the fact that 'open_basedir' is disabled on this system, an attacker can exploit this issue and write wsdl files within the context of the affected application. Also, it has been found that other attacks are also possible. As a result, the 'soap.wsdl_cache_dir' directive sets the directory name where the SOAP extension will place the cache files. Disabling 'open_basedir' has not 1) removed cache files that already exist and/or 2) ceased the possibility of new cache files from being placed into an arbitrary directory.
Please review https://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controls for the definition of a compensating control. Among other things "Compensating controls must:…Be “above and beyond” other PCI DSS requirements (not simply in compliance with other PCI DSS requirements)", and disabling 'open_basedir' does not really go above and beyond, the underlying issue should really be addressed here. Again, the requirements as listed within the scan report are to upgrade the system or utilize the compensating controls mentioned (which, disabling open_basedir would not be sufficient in this case).
Any issues detected on a system that is in scope for PCI DSS compliance would need to have all PCI non-compliant issues remediated (which is any system involved in the storage, processing, and/or transmission of credit card holder data and any system directly connected to a network involved in such processes which does not have proper network segmentation in place).
Please review the scan report and follow the suggestions found underneath the “Remediation” column and then perform another scan when the vulnerability has been remediated to clear the finding from your next scan report.
If the vulnerability continues to be detected after this point and/or if you have already performed this then please feel free to re-dispute this vulnerability and explain what was performed to address the finding.
Answer
It seems suspect that Ubuntu "doesn't support" a stock PHP configuration directive, since they've fixed bugs with it before (for instance).
Edit: Seems that Debian and Red Hat have the same policy, actually - "don't support" is bad wording, but all of these distros are of the opinion that flaws in an inherently flawed security mechanism aren't a concern.
However, that's likely irrelevant. Check your php.ini for open_basedir - if it's not in there, then you're completely unaffected by this security issue, since the bug is a bypass of the security restrictions that open_basedir provides.
If your auditor is especially bad at this, however, your best course of action might just be to stop showing them what version of PHP you're on - version string checking is a terrible way to do vulnerability assessment, anyway. If it's an Apache web server showing its version strings, give it ServerSignature Off and ServerTokens Prod.
Edit with notes on the response they sent you...
The version of PHP that is currently running on this system has been found to not properly sanitize user-supplied input.
This bug doesn't have anything to do with sanitizing input, it's a flaw in a sandboxing mechanic.
Despite the fact that 'open_basedir' is disabled on this system, an attacker can exploit this issue and write wsdl files within the context of the affected application.
I'm by no means an expert in the internals of PHP, but that seems like a serious misinterpretation of the vulnerability. From what I can tell about this bug, the issue is that an attacker can use the WSDL caching mechanic to load a WSDL from a directory location outside of the open_basedir root (but probably still within the soap.wsdl_cache_dir, which defaults to /tmp).
For this to matter at all, you'd have to have files that could actually be targeted in this way and an access method to trigger it being cached (directory traversal in your web server, maybe?)
At any rate, triggering the creation of a cached WSDL based on content already on the system is very different from writing files into your web application..
As a result, the 'soap.wsdl_cache_dir' directive sets the directory name where the SOAP extension will place the cache files. Disabling 'open_basedir' has not 1) removed cache files that already exist and/or 2) ceased the possibility of new cache files from being placed into an arbitrary directory.
While the CVE does say "arbitrary directory", what it seems to really mean is "the configured WSDL cache directory". This vulnerability would be much more serious if it included a directory traversal component. In reality, all that was changed was adding validation to make sure that the cache directory is within the open_basedir. See here.
disabling 'open_basedir' does not really go above and beyond, the underlying issue should really be addressed here
That's nonsense. This is a bug where the WSDL cache directory didn't properly validate that it was within open_basedir. If you don't have an open_basedir configured, the entire vulnerability is completely irrelevant - no other changes were made to provide any additional security benefit whatsoever.
Comments
Post a Comment