レガシーPHPのセキュリティ対策、大丈夫ですか?

第7回未修正の脆弱性(4)

今回も引き続き未修正の脆弱性とパッチを適用しない場合の対処を順次紹介していきます。繰り返しになりますが、脆弱性の危険度の順ではなくパッチファイル名の順番に紹介します。紹介する脆弱性情報は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の解説が必要な方はそちらをご覧ください。

escapeshellcmd関数の問題

適用

必須

CVEではescapeshellcmd関数のみ記載されていますが、実際にはescapeshellargs関数にも影響があります。

回避策

入力バリデーションで不正な文字エンコーディングを拒否します。

リスク

攻撃が成功するかどうかはシステムやシステム設定によって異なりますが、日本のサーバーでのリスクは高いと考えられます。

EXIFモジュールのバッファオーバーフロー

適用

オプション

ExifとはJPEGファイルなどに含まれているメタデータです。画像のアップロードを許可しているアプリケーションなどではよく利用されている機能です。

回避策

PHPスクリプトでイメージファイルのヘッダを読み込み不正なデータが含まれていないか解析することもできないことはないですが、あまり現実的とは言えません。問題を回避するにはExifモジュールを利用しないようにします。

リスク

メモリ内容の漏洩とバッファーオーバーフローが発生するため、攻撃されるリスクは高いと考えられます。

explode関数の不正メモリ参照

適用

必須

このexplode関数の不具合を利用した具体的な攻撃コードが存在します。複数のユーザがシステムを共有する環境での影響は大きいです。

回避策

リモートからの攻撃では有効な攻撃は難しいと考えられます。

リスク

共有環境でユーザが実行できる機能を制限していても、その機能を回避されます。WebサーバがSSL対応の場合、メモリ上に保存された秘密鍵を盗まれる可能性があります。

まとめ

レガシーPHPには確実にリスクが潜んでいます。アップグレードが最良ですが、さまざまな理由でできない場合もあるでしょう。少なくとも既知の脆弱性の影響を受けないようこの情報を活用してください。

おすすめ記事

記事・ニュース一覧