Php CVE-2011-1092 on Centos/PCI DSS合规性

对客户端网站的安全扫描表明，由于他们运行的是PHP5.3.3，因此容易受到CVE-2011-1092的攻击（在5.3.6及以上版本中修复）

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

查看并明确指出，RHEL和Centos附带的PHP版本中未解决此问题，因为RHEL认为这不是安全问题

这让客户左右为难——他们的PCI DSS合规扫描公司（Trustwave）不会接受RHEL关于“这不是一个安全问题”的声明，即“访问[上面链接的RHEL页面]似乎表明RedHat尚未解决CVE-2011-1092问题。由于该发现影响PCI DSS合规性，因此需要确认已以某种方式解决。”

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

---

提前感谢您的建议。

此漏洞仅影响功能。你有可能；如果您这样做并且没有抛出错误，那么您的代码就不会也不能使用该函数，因此您是安全的。

这就是PCI-DSS行业的工作方式-训练有素的猴子针对应用程序运行自动扫描软件，然后在它变为红色时上下跳跃。试图和猴子讲道理并没有什么用处，因为它们只懂红色和绿色。别误会我的意思——在大多数工具中编写代码的人都很聪明——但他们不是你必须面对的人。不幸的是，猴子被赋予了很大的力量。问题的存在并不意味着问题是可利用的

公平地说，猴子们。但我同意Redhat的观点——唯一可以利用它的方法是有权访问php代码的人，或者如果您将用户提供的值直接传递给低级函数

---

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

我可以逐个域禁用该功能，大概是吧。如果这个域是一个Magento安装，有没有办法知道Magento的任何部分是否依赖于shmop_read（）函数的可用性？我会阻止它并查找错误，据我所知，它不是一个常用的函数。如果这不是一个选项，请尝试。如果这不起作用，可能没有短期的解决办法。祝你好运。就我个人而言，我会把任何把这种改变应用到我的系统中的人钉死在十字架上，然后等着看是什么东西坏了。OTOH，除非对PHP代码进行编码，否则扫描代码查找函数名（至少在Linux/Unix系统上）只需几分钟的时间。我正在考虑一个测试系统，并试图立即修复它。这是我添加第二种可能性的原因。第一个方法立即显示上下文，这就是为什么它是第一个；）有点像扔香蕉给他们？；-）