關於CentOS/PCI DSS合規性的CVE-2011-1092

客戶端站點的安全掃描標誌着這樣一個事實，即由於他們運行的是PHP 5.3.3，因此他們很容易受到CVE-2011-1092（5.3中修復。 6及以上）。關於CentOS/PCI DSS合規性的CVE-2011-1092

通常我會說backporting會處理這個問題，因爲他們的PHP已經被多年支持到5.3.27，但是在changelog中沒有跡象表明這個特定的CVE已經被解決了。

看https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1092和https://access.redhat.com/security/cve/CVE-2011-1092指示明確，這個問題沒有在PHP隨RHEL和CentOS的版本得到解決，因爲RHEL不認爲這是一個安全問題。

這使得客戶面臨兩難困境 - 他們的PCI DSS合規掃描公司（Trustwave）不會接受RHEL關於「這不是安全問題」的陳述，稱「正在訪問[上面鏈接的RHEL頁面]以表明RedHat尚未解決CVE-2011-1092。由於此發現影響PCI DSS合規性，因此需要確認已採用某種方式進行解決。「

有沒有人有任何建議如何進行此？是否可以通過以某種方式修補文件來直接解決問題？

在此先感謝，有任何建議。

來源

2014-05-07 Giles Bennett

這就是PCI-DSS行業的工作方式 - 經過培訓的猴子對應用程序運行自動掃描軟件，然後在變紅時跳起來。試圖與猴子進行推理不起作用，因爲他們只理解紅色和綠色。不要誤會我的意思 - 在大多數這些工具中編寫代碼的人都非常聰明 - 但他們不是你必須處理的人。不幸的是這些猴子被賦予了很多權力。問題的存在並不意味着問題是可以利用的。

公平的猴子，NIST put the risk as 'high'。但是我同意Redhat的觀點 - 唯一可以被利用的方法是有人可以訪問php代碼，或者如果您將用戶提供的值直接傳遞給lowe級別的函數。

如果我是你的鞋子，那麼我會做的第一件事就是檢查代碼是否使用共享內存 - 如果沒有將相關函數添加到php.ini中的disable_functions設置。雖然證明該漏洞無法被攻擊者利用並且在代碼中使用該函數是困難的，但可以證明，如果該函數不可訪問，則該漏洞不能被利用。當然，這是否會安撫猴子是另一回事。

來源

2014-05-07 08:28:25 symcbean

有點像扔他們香蕉？ ;-) –

該漏洞隻影響功能shmop_read()。你有可能disable functions in the php.ini;如果你這樣做並且沒有錯誤發生，你的代碼就不會使用這個函數，所以你很安全。

來源

2014-05-07 08:13:01 Sebb

據我所知，我可以禁用每個域的功能。如果這個域是一個Magento安裝，有什麼方法可以知道Magento的任何部分是否依賴於shmop_read（）函數的可用性？ –

我只是想阻止它並查找錯誤，據我所知這不是一個常用的函數。如果這不是一個選項，請嘗試[使用grep搜索文件]（https://stackoverflow.com/questions/18100747/using-grep-to-find-function）。如果這不起作用，可能沒有簡短的解決方法。 – Sebb

祝你好運。就我個人而言，我會將任何對我的系統實施這種改變的人釘死在十字架上，並等待看到什麼破碎。OTOH，除非PHP代碼被編碼，否則掃描代碼以獲取函數名稱至少需要幾分鐘的時間（至少在Linux/Unix系統上） – symcbean

關於CentOS/PCI DSS合規性的CVE-2011-1092

回答

相關問題