我试图让PCI兼容，PCI扫描公司正在标记我们的Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9的CVE-2013-1635。 根据http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.html Ubuntu的回应是“我们不支持open_basedir的用户”，所有版本都被标记为忽略。
我不知道该怎么做。 我已经指出我的扫描公司这个url，但他们不接受作为和答案。
我该怎么办？
更新
我不使用这个function，并且在php.ini中禁用了open_basedir指令。 但是，他们不认为这是一个适当的解决scheme。
这是他们对我们的争端否认的回应：
我们根据所提供的关于如何解决这一调查结果的资料否认了这一争端。 目前在这个系统上运行的PHP版本被发现没有正确地处理用户提供的input。 尽pipe在此系统上禁用了“open_basedir”，但攻击者可以利用此问题并在受影响的应用程序的上下文中写入wsdl文件。 而且，已经发现其他攻击也是可能的。 因此，“soap.wsdl_cache_dir”指令设置SOAP扩展将放置caching文件的目录名称。 禁用“open_basedir”没有1）删除已经存在的caching文件和/或2）停止将新caching文件放置到任意目录中的可能性。
请查阅https://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controls来了解补偿控制的定义。 除其他事项外，“补偿控制必须：”超越“其他PCI DSS要求（不仅仅是符合其他PCI DSS要求）”，禁用“open_basedir”并不是真正的超越，底层的问题应该是真的在这里解决。 同样，扫描报告中列出的要求是升级系统或使用所提到的补偿控制（在这种情况下，禁用open_basedir是不够的）。
在符合PCI DSS规范的系统上检测到的任何问题都需要纠正所有不符合PCI规定的问题（即直接存储，处理和/或传输信用卡持有人数据和任何系统的任何系统连接到涉及这种没有适当的networking分段的过程的networking）。
请查看扫描报告，并按照“修复”列下的build议进行操作，然后在修复漏洞时执行另一次扫描，以清除下次扫描报告中的查找结果。
如果在此之后漏洞继续被检测到，并且/或者您已经执行了此操作，请随时重新解决此漏洞，并解释执行哪些操作来解决此问题。
似乎可疑的是，Ubuntu“不支持”一个股票的PHPconfiguration指令，因为他们之前已经修复了错误（ 例如 ）。
编辑 ：似乎Debian和Red Hat有相同的政策，实际上 – “不支持”是不好的措辞，但所有这些发行人都认为，本质上存在缺陷的安全机制中的缺陷并不是一个问题。
由于这些原因，“安全模式”和“open_basedir”选项中的错误，或PHP解释器或允许脚本跳过这些选项的扩展中的任何错误，都不会被视为安全敏感。
但是，这可能是无关紧要的。 检查你的php.ini的open_basedir – 如果它不在那里，那么你完全不受这个安全问题的影响，因为这个bug是绕过了open_basedir提供的安全限制。
但是，如果你的审计人员特别糟糕，那么你的最佳行动可能就是停止向他们展示你正在使用的PHP版本 – 无论如何，版本string检查是一种可怕的方式来进行漏洞评估。 如果它是显示其版本string的Apache Web服务器，请将其ServerSignature Off和ServerTokens Prod 。
编辑与他们发送给你的回复的笔记…
目前在这个系统上运行的PHP版本被发现没有正确地处理用户提供的input。
这个bug与input消毒没有任何关系，这是一个沙盒机制的缺陷。
尽pipe在此系统上禁用了“open_basedir”，但攻击者可以利用此问题并在受影响的应用程序的上下文中写入wsdl文件。
我绝不是PHP内部的专家，但这似乎是对这个漏洞的严重误解。 从我可以告诉这个bug的问题来看，问题是攻击者可以使用WSDLcaching机制从open_basedir根之外的目录位置加载WSDL（但可能仍在soap.wsdl_cache_dir ，默认为/tmp ） 。
对于这一点很重要，你将不得不有这样的文件，实际上是有针对性的和访问方法来触发它被caching（目录遍历在您的Web服务器，也许？）
无论如何，触发基于已经在系统上的内容创buildcaching的WSDL与将文件写入您的Web应用程序非常不同。
因此，“soap.wsdl_cache_dir”指令设置SOAP扩展将放置caching文件的目录名称。 禁用“open_basedir”没有1）删除已经存在的caching文件和/或2）停止将新caching文件放置到任意目录中的可能性。
虽然CVE确实说了“任意目录”，但是它的真正含义是“configuration的WSDLcaching目录”。 如果包含一个目录遍历组件，这个漏洞会更加严重。 实际上，所有这些改变都是为了确保caching目录在open_basedir 。 看到这里 。
禁用“open_basedir”并不是真正的超越，在这里应该真正解决底层的问题
这是无稽之谈。 这是WSDLcaching目录没有正确validation它在open_basedir内的错误。 如果您没有configurationopen_basedir ，则整个漏洞是完全不相关的 – 没有其他更改提供任何额外的安全性好处。