我正在嘗試獲得 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，但他們不接受該 URL 並回答。
我該怎麼辦？
更新
我不使用此功能，並且 open_basedir 命令在 php.ini 中已停用。然而，他們認為這不是一個合適的解決方案。
以下是他們對否認我的爭議的回應：
我們根據所提供的有關如何解決這一發現的資訊否認了這一爭議。已發現目前在此系統上執行的 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 配置指令，因為他們之前已經修復了它的錯誤（例如）。
編輯： Debian 和 Red Hat 似乎有相同的政策，實際上 - “不支持”是不好的措辭，但所有這些發行版都認為，固有缺陷的安全機制中的缺陷不是問題。
由於這些原因，「安全模式」和「open_basedir」選項中的錯誤，或允許腳本繞過這些選項的 PHP 解釋器或擴充功能中的任何錯誤，將不會被視為安全敏感的。
然而，這可能無關緊要。檢查您的php.ini是否存在open_basedir- 如果它不在那裡，那麼您完全不受此安全問題的影響，因為該錯誤是對所open_basedir提供的安全限制的繞過。
然而，如果您的審計員在這方面特別糟糕，那麼您最好的做法可能就是停止向他們顯示您所使用的 PHP 版本 - 無論如何，版本字串檢查是進行漏洞評估的一種糟糕方法。如果它是顯示其版本字串的 Apache Web 伺服器，請為其提供ServerSignature Off和ServerTokens Prod。
編輯他們發送給您的回覆的註釋...
已發現目前在此系統上執行的 PHP 版本無法正確清理使用者提供的輸入。
這個錯誤與清理輸入沒有任何關係，它是沙箱機制中的缺陷。
儘管該系統上禁用了“open_basedir”，但攻擊者仍可以利用此問題並在受影響的應用程式上下文中寫入 wsdl 檔案。
我絕不是 PHP 內部的專家，但這似乎是對該漏洞的嚴重誤解。據我所知，這個 bug 的問題是，攻擊者可以使用 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配置，則整個漏洞完全無關 - 沒有進行任何其他更改來提供任何額外的安全優勢。