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

fprint整数オーバーフロー

printfのフォーマット文字列の添字数、幅、精度が内部的にはint型と宣言されいました。このため、64bitアーキテクチャの場合は整数オーバーフローが発生して必要なバッファ用のメモリが確保できない場合がありました。この問題は64bit環境でのみ発生します。

パッチではオーバーフローする変数をlong型（64bit）に拡張することにより脆弱性を修正しています。PHP 5.2以降では別の方法で修正され、32bit整数がオーバーフローした場合は無効にとなるように修正されています。

回避策

printf関数などのフォーマット文字列にユーザ入力を利用しない。利用する場合は範囲、形式などを合理的なものに制限（バリデーション）する。

リスク

CVSSのインパクトスコア 6.4、攻撃容易性 10.0（最高）と評価されています。非常に高いリスクのように思えますが、スクリプトが信頼できる環境であれば、つまり攻撃用スクリプトが簡単に設置できるような環境でなければCVSSのスコアと関係なくリスクはそれほど大きくありません。ただし、これらのレガシーPHPはファイルインクルードバグに対しても脆弱なので、不特定多数がスクリプトを設置できる環境ではないからといって安心できるものでもありません。

fnmatchバッファーオーバーフロー

fnmatch関数のファイル名にシステムがサポートする以上の長いファイル名を渡した場合、バッファーオーバーフローが発生します。システムのfnmatch関数に渡すファイルの長さをチェックしていないことが原因です。

回避策

fnmatch関数に渡すファイル名、パターンにユーザから送信された値を利用しない。利用する場合はファイル名、パターンが合理的な長さかバリデーションする。

リスク

一般のアプリケーションでfnmatch関数にユーザから送られてきた値を利用することはあまり無いと思われます。ただし、利用している場合は必ずバリデーション処理をした値を利用しないと攻撃されるリスクがあります。

URLスキャナの不具合でJavaScriptインジェクションが可能となる

trans_sid（URLベースのセッション管理）を利用した場合にURLスキャナが利用されます。細工した文字列を送信することによりJavaScriptなどの不正なスクリプトやHTMLタグなどを挿入できます。

回避策

trans_sidを利用しない。output_add_rewrite_var関数もURLスキャナを利用するので利用しない。リライト対象となるユーザ入力（trans_sidの場合はセッションID）をバリデーションする。

リスク

携帯用サイトではクッキーが利用できないため、trand_sidを利用しているサイトも存在します。このようなサイトではリスクがあります。

脆弱な乱数

最近ではあまり見かけなくなりましたが、脆弱な乱数もセキュリティ上の脅威となります。さまざまなプログラムで類似の脆弱性が見つかりました。PHPにはrand関数とmt_rand関数の二種類がありますが、単純な乱数関数であるrand関数は非常に脆弱でした。

回避策

mt_rand関数を利用する。古いPHPではseedが必要なのでseedも忘れない。

リスク

古いrand関数は非常に脆弱です。使うべきではありません。CSRF対策の鍵などに利用している場合、予想される可能性が高くなります。

まとめ

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