php - 关于 Centos/PCI DSS 合规性的 CVE-2011-1092

Question

对客户端站点的安全扫描表明，由于它们运行的​​是 PHP 5.3.3，它们容易受到 CVE-2011-1092(在 5.3.6 及更高版本中修复)的攻击。

通常我会说反向移植会解决这个问题，因为他们的 PHP 多年来一直被反向移植到 5.3.27，但是在变更日志中没有迹象表明这个特定的 CVE 已经得到解决。

看https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1092和 https://access.redhat.com/security/cve/CVE-2011-1092明确表示此问题没有在 RHEL 和 Centos 附带的 PHP 版本中已解决，因为 RHEL 不认为这是一个安全问题。

这让客户进退两难——他们的 PCI DSS 合规扫描仪公司 (Trustwave) 不会接受 RHEL 的“这不是安全问题”的声明，称“访问 [上面链接的 RHEL 页面] 似乎表明 RedHat 已经未解决 CVE-2011-1092。由于此发现会影响 PCI DSS 合规性，因此确实需要确认已以某种方式解决。

有人对如何进行此操作有任何建议吗？是否可以通过以某种方式修补文件直接解决问题？

在此先感谢您的任何建议。

Answer 1

这就是 PCI-DSS 行业的工作方式——训练有素的猴子对应用程序运行自动扫描软件，然后如果它变红就会上下跳跃。试图与猴子推理没有任何用处，因为它们只了解红色和绿色。不要误会我的意思——在大多数这些工具中编写代码的人非常聪明——但他们不是你必须处理的人。不幸的是，猴子被赋予了很大的权力。问题的存在并不意味着该问题是可利用的。

公平地说，NIST put the risk as 'high' .但我同意 Redhat - 可以利用的唯一方法是由有权访问 php 代码的人，或者如果您将用户提供的值直接传递给低级函数。

如果我站在你的立场上，那么我要做的第一件事就是检查代码是否使用了共享内存——如果没有，则将相关函数添加到 php.ini 中的 disable_functions 设置中。虽然很难证明启用了该功能并在代码中使用的攻击者无法利用该漏洞，但如果无法访问该功能，则可以证明该漏洞无法被利用。当然，这是否会安抚猴子是另一回事。