UbuntuPCI-DSSコンプライアンスの問題
PCIに準拠しようとしていますが、PCIスキャン会社がUbuntu 12.04 PHP 5.3.10-1ubuntu3.9 for CVE-2013-1635）にフラグを立てています。 http： //people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.html Ubuntuの応答は「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非準拠の問題を修正する必要があります（これは、ストレージ、処理、および/または送信に関与するシステムです）。クレジットカード所有者データ、および適切なネットワークセグメンテーションが実施されていないそのようなプロセスに関与するネットワークに直接接続されているシステム）。
スキャンレポートを確認し、[修正]列の下にある提案に従ってください。次に、脆弱性が修正されたら別のスキャンを実行して、次のスキャンレポートからの結果をクリアしてください。
この時点以降も脆弱性が検出され続ける場合、および/またはすでにこれを実行している場合は、この脆弱性について再度異議を唱え、発見に対処するために何が実行されたかを説明してください。
Ubuntuは以前にバグを修正したことがあるので（ たとえば ）、ストックPHP構成ディレクティブを「サポートしていない」のではないかと思われます。
Edit：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内）のディレクトリの場所からWSDLをロードできることです。デフォルトは/tmp）です。
これがまったく問題になるには、実際にこの方法でターゲットにできるファイルと、キャッシュされるようにトリガーするアクセス方法が必要です（Webサーバーでのディレクトリトラバーサルなど）。
いずれにせよ、すでにシステム上にあるコンテンツに基づいてキャッシュされたWSDLの作成をトリガーすることは、Webアプリケーションにファイルを書き込むこととは大きく異なります。
その結果、「soap.wsdl_cache_dir」ディレクティブは、SOAP拡張子がキャッシュファイルを配置するディレクトリ名を設定します。「open_basedir」を無効にしても、1）既存のキャッシュファイルが削除されたり、または2）新しいキャッシュファイルが任意のディレクトリに配置される可能性をなくしました。
CVEは「任意のディレクトリ」と言っていますが、実際には「構成されたWSDLキャッシュディレクトリ」を意味しているようです。この脆弱性は、ディレクトリトラバーサルコンポーネントが含まれている場合、はるかに深刻になります。実際には、変更されたのは、キャッシュディレクトリがopen_basedir内にあることを確認するための検証を追加することだけでした。 ここ を参照してください。
'open_basedir'を無効にすることは、実際にはそれ以上のことではありません。根本的な問題は、ここで実際に対処する必要があります。
それはナンセンスです。これは、WSDLキャッシュディレクトリがopen_basedir内にあることを適切に検証しなかったバグです。 open_basedirが構成されていない場合、脆弱性全体はまったく関係ありません。セキュリティ上の利点を追加するために他の変更は加えられていません。