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 を指示しましたが、回答として受け入れられません。
どうすればいいですか？
アップデート
私はこの機能を使用しておらず、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 は同じポリシーを持っているようです。「サポートしない」というのは不適切な表現ですが、これらすべてのディストリビューションは、本質的に欠陥のあるセキュリティ メカニズムの欠陥は問題ではないという意見です。
ただし、それはおそらく無関係です。 を確認してくださいphp.ini。open_basedirそこにない場合は、このバグは がopen_basedir提供するセキュリティ制限のバイパスであるため、このセキュリティ問題の影響はまったくありません。
ただし、監査担当者がこの点で特に苦手な場合は、使用している PHP のバージョンを監査担当者に表示しないようにするのが最善策かもしれません。バージョン文字列のチェックは、脆弱性評価を行う方法としては最悪です。バージョン文字列を表示する Apache Web サーバーの場合は、ServerSignature Offと を指定しますServerTokens Prod。
送信された応答をメモして編集します...
現在このシステムで実行されている PHP のバージョンでは、ユーザーが指定した入力が適切にサニタイズされないことが判明しました。
このバグは入力のサニタイズとは関係なく、サンドボックス化の仕組みの欠陥です。
このシステムでは「open_basedir」が無効になっているにもかかわらず、攻撃者はこの問題を悪用して、影響を受けるアプリケーションのコンテキスト内で wsdl ファイルを書き込む可能性があります。
私は決して PHP の内部構造の専門家ではありませんが、これは脆弱性の重大な誤解のように思えます。このバグについて私が言えることは、攻撃者が WSDL キャッシュ機構を使用して、ルート以外のディレクトリの場所open_basedir(ただし、おそらく 内でsoap.wsdl_cache_dir、デフォルトは/tmp) から WSDL をロードできるという問題です。
これが問題になるには、実際にこの方法でターゲットにできるファイルと、キャッシュをトリガーするアクセス方法 (Web サーバーでのディレクトリ トラバーサルなど) が必要です。
いずれにせよ、システム上に既に存在するコンテンツに基づいてキャッシュされた WSDL の作成をトリガーすることは、Web アプリケーションにファイルを書き込むこととは大きく異なります。
その結果、「soap.wsdl_cache_dir」ディレクティブは、SOAP 拡張機能がキャッシュ ファイルを配置するディレクトリ名を設定します。「open_basedir」を無効にしても、1) 既存のキャッシュ ファイルが削除されたり、2) 新しいキャッシュ ファイルが任意のディレクトリに配置されなくなることはありません。
CVE では「任意のディレクトリ」と書かれていますが、実際には「構成された WSDL キャッシュ ディレクトリ」を意味しているようです。この脆弱性は、ディレクトリ トラバーサル コンポーネントが含まれていれば、さらに深刻になります。実際には、変更されたのは、キャッシュ ディレクトリが 内にあることを確認する検証を追加しただけですopen_basedir。ここ。
'open_basedir' を無効にしても、実際にはそれ以上のことは起こらない。根本的な問題にここで対処すべきである。
それはナンセンスです。これは、WSDL キャッシュ ディレクトリが 内にあることを適切に検証しなかったバグですopen_basedir。 を設定していない場合open_basedir、脆弱性全体はまったく無関係です。セキュリティ上の利点を追加するための変更は一切行われていません。