我正在尝试获得 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.htmlUbuntu 的回应是“我们不支持 open_basedir 的用户”，并且所有版本都被标记为忽略。
我不知道该怎么办。我已将这个 URL 发送给我的扫描公司，但他们不接受并给出答复。
我应该怎么办？
更新
我没有使用此功能，并且 php.ini 中的 open_basedir 指令已禁用。但是，他们认为这不是一个合适的解决方案。
以下是他们对于我提出的异议的否认的回应：
根据提供的关于如何处理这一发现的信息，我们驳回了这一争议。目前发现，该系统上运行的 PHP 版本没有正确清理用户提供的输入。尽管该系统已禁用“open_basedir”，但攻击者可以利用此问题并在受影响的应用程序上下文中写入 wsdl 文件。此外，还发现其他攻击也是可能的。因此，“soap.wsdl_cache_dir”指令设置了 SOAP 扩展将放置缓存文件的目录名称。禁用“open_basedir”不会 1) 删除已存在的缓存文件和/或 2) 阻止将新缓存文件放入任意目录的可能性。
请查阅https://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controls补偿控制的定义。除其他事项外，“补偿控制必须：……‘超出’其他 PCI DSS 要求（而不仅仅是符合其他 PCI DSS 要求）”，禁用“open_basedir”并没有真正超出范围，真正应该在这里解决的是根本问题。同样，扫描报告中列出的要求是升级系统或利用提到的补偿控制（在这种情况下，禁用 open_basedir 是不够的）。
对于在 PCI DSS 合规范围内的系统上检测到的任何问题，都需要对所有不符合 PCI 合规性的问题进行补救（任何涉及存储、处理和/或传输信用卡持有人数据的系统，以及任何直接连接到涉及此类过程的网络的系统，但这些系统没有适当的网络分段）。
请查看扫描报告并按照“补救措施”栏下方的建议进行操作，然后在漏洞得到补救后执行另一次扫描，以清除下一份扫描报告中的发现。
如果此后仍然检测到漏洞和/或您已经执行了此操作，那么请随时重新对此漏洞提出异议，并解释为解决该发现所采取的措施。
答案1
Ubuntu 似乎“不支持”现有的 PHP 配置指令，因为他们之前已经修复了它的 bug（例如）。
编辑：实际上，Debian 和 Red Hat 似乎有相同的政策 - “不支持”是错误的措辞，但所有这些发行版都认为，固有有缺陷的安全机制中的缺陷并不令人担忧。
由于这些原因，“安全模式”和“open_basedir”选项中的错误，或者 PHP 解释器或扩展中的任何允许脚本绕过这些选项的错误，都不会被视为安全敏感。
但是，这可能无关紧要。检查php.ini一下open_basedir- 如果它不在那里，那么您完全不会受到此安全问题的影响，因为该错误是绕过open_basedir提供的安全限制。
但是，如果您的审计员在这方面特别差，那么您最好的做法可能就是停止向他们展示您使用的 PHP 版本 - 无论如何，版本字符串检查是一种糟糕的漏洞评估方式。如果是显示其版本字符串的 Apache Web 服务器，请给它ServerSignature Off并ServerTokens Prod。
对他们发给您的回复进行编辑并附上注释......
发现当前在该系统上运行的 PHP 版本无法正确清理用户提供的输入。
这个错误与清理输入无关，而是沙盒机制的一个缺陷。
尽管该系统上已禁用“open_basedir”，但攻击者可以利用此问题并在受影响应用程序的上下文中写入 wsdl 文件。
我绝不是 PHP 内部机制方面的专家，但这似乎是对漏洞的严重误解。据我所知，该漏洞的问题是攻击者可以使用 WSDL 缓存机制从根目录之外的目录位置加载 WSDL open_basedir（但可能仍在 内soap.wsdl_cache_dir，默认为/tmp）。
为了使这一点变得重要，您必须拥有可以通过这种方式实际定位的文件和触发其缓存的访问方法（也许是 Web 服务器中的目录遍历？）
无论如何，根据系统上已有的内容触发缓存 WSDL 的创建与将文件写入 Web 应用程序有很大不同。
因此，“soap.wsdl_cache_dir”指令设置了 SOAP 扩展将放置缓存文件的目录名称。禁用“open_basedir”不会 1) 删除已存在的缓存文件和/或 2) 阻止将新缓存文件放入任意目录的可能性。
虽然 CVE 确实提到了“任意目录”，但它真正的意思似乎是“配置的 WSDL 缓存目录”。如果此漏洞包含目录遍历组件，则其严重性会大得多。实际上，所做的所有更改只是添加了验证以确保缓存目录位于 内open_basedir。请参阅这里。
禁用“open_basedir”并没有真正起到什么作用，根本问题应该在这里得到解决
这简直是胡说八道。这是一个错误，WSDL 缓存目录没有正确验证它是否在 内open_basedir。如果您没有配置open_basedir，整个漏洞就完全无关紧要了 - 没有进行任何其他更改来提供任何额外的安全优势。