引き続き未修正の脆弱性とパッチを適用しない場合の対処を順次紹介していきます。繰り返しになりますが、脆弱性の危険度の順ではなくパッチファイル名の順番に紹介します。紹介する脆弱性情報はSRA OSS Inc日本支社にてPHP4セキュリティ保守サービスとして提供しているものです。パッチ類は筆者の会社であるエレクトロニック・サービス・イニシアチブが、現状サポートされているPHPからレガシーPHPにバックポートしています。パッチの説明文を引用して脆弱性を解説します。パッチそのものの紹介は含みませんのでご了承ください。
PHP 4.3.9の評価は、PHPプロジェクトが配布しているソースコードではなくRedHat Enterprise Linux 4で提供されているPHPのSRPM（ソースRPM）のソースコードがベースになっています。PHP 5.1.6についてはPHPプロジェクトが配布しているソースコードがベースとなっています。このため、RedHat Enterprise Linux 5で修正されている問題も含まれていることがあります。
CVE/NVDについては第2回目の「CVEの読み方」で紹介しました。CVE/NVDの解説が必要な方はそちらをご覧ください。
allow_url_includeの追加
解説
PHP5にはallow_url_includeオプションが追加され、php.iniからinclude／require文がURLで指定されたスクリプトファイルにアクセス可能か設定できるようになりました。この仕様追加はセキュリティ上非常に大きな意味を持ちますが、PHP 4にはバックポートされていません。このパッチはPHP 5のallow_url_include php.iniオプションを追加します。ただし、このパッチでは完全にリモートコードの実行を防止できません。POSTメソッドによりデータを送信し、実行するスクリプトを標準入力から読み込むことによりリモートからのコード実行が可能です。
php.ini設定のallow_url_fopen設定はスクリプトからも変更可能な設定でしたが、システムレベルでのphp.iniのみにより変更可能な設定に改変されています。このため、リモートファイルにアクセスしたい場合、必要な箇所のみリモートファイルアクセスを許可するコーディングが行えません。
古いPHPはこの設定をスクリプト中からも変更可能でした。このパッチが無い場合、古い仕様に頼っていたスクリプトはより低い安全性で動作していることになります。
このパッチにはCVE番号はありません。PHPがWebサーバやFTPサーバ上の外部スクリプトを呼び出せる機能は脆弱性ではなく「仕様」だからです。
回避策
include／require文にユーザ入力を含むパラメータを利用する場合、確実にバリデーションを行う。
リスク
パッチ適用済みのPHPの場合、リモートスクリプトの実行は防げます。しかし、ローカルスクリプトの実行は防げません。パッチ適用済みのPHPであってもユーザー入力を含むパラメータをinclude／require文に利用する場合、バリデーションを行わなければなりません。
ZTSモードでのcrypt関数の脆弱性
回避策
独自にロックを行いレースコンディションを避けるようにします。
リスク
CVSSのスコアからはリスクが高い脆弱性にみえますが、実際のWebアプリケーションを外部から攻撃する場合、有効な攻撃は難しいです。
BDAデータベースに対するDoS攻撃
DBAモジュールのdba_replace関数にNULL文字を利用すると、データベースを操作できる権限を持っている場合、データベースを空にできてしまう脆弱性です。
回避策
入力となるキー名にNULL文字が含まれていないかチェックします。
リスク
DBAのデータベースを利用する場合、変更権限を有するアプリケーションが場合が多いと考えられます。このため、入力パラメータのバリデーションが不十分なアプリケーションは攻撃される可能性が高いと考えられます。
PCREモジュールのバッファオーバーフロー
CVE-2008-2371はPHPの脆弱性ではありません。PHPにバンドルされているPCREライブラリの脆弱性です。PHPのデフォルトではバンドルされたPCREライブラリが利用されます。Fedora／RedHat系のディストリビューションではバンドルされたPCREライブラリが利用されます。Debian系のディストリビューションではシステムにインストールされたPCREライブラリが利用されます。
pcre_compile.cのヒープ領域のオーバーフローであるとされているので、攻撃は正規表現の検索対象ではなく細工した正規表現を利用して攻撃するものと考えられます。
回避策
ユーザ入力をPCRE正規表現に利用しない。
リスク
CVEでは任意コード実行の可能性が指摘されています。脆弱性攻撃の複雑性も低いと評価されているので、ユーザ入力をPCRE正規表現に利用しているアプリケーションのリスクは高いと考えられます。
まとめ
レガシーPHPには確実にリスクが潜んでいます。アップグレードが最良ですが、さまざまな理由でできない場合もあるでしょう。少なくとも既知の脆弱性の影響を受けないようこの情報を活用してください。
