今日はNDSSの話題を休んで、2月の「Patch Tuesday」の話をしたいと思います。
米国では「第二火曜日」がパッチの日
先日はMicrosoftの定例パッチの日でした。日本では第二水曜日（正確には、第二火曜日の翌日）がパッチの日ですが、米国では時差の関係で火曜日になります。「Patch Tuesday」と呼ばれており、やはり米国でも多くのセキュリティ関係者がバタバタする日です。eEyeでも、脆弱性スキャナの監査モジュールやIDP製品の保護モジュールなどを提供しなければなりませんので、一部エンジニアはランチ時の外出が禁止になってしまいます(宅配ピザなどが届きますが)。
私もパッチ解析や脆弱性スキャナRetinaのアップデートを行っていますので、パッチの日が近づくと落ち着きません。リモートから能動的に攻撃可能な脆弱性が公開された場合は、すぐにパッチ差分解析を行って、非破壊の脆弱性検出手法を見つけなければなりません。この作業はリサーチ・チームの数名が一斉に取り掛かりますが、その日は帰れない事もあります。
さて先日のPatch Tuesdayでは、eEyeリサーチ・チームが発見したWindows Media Playerの脆弱性に対するパッチも公開されました。この公開に合わせて、eEyeのwebサイトにて技術的な情報を含むアドバイザリが昨日公開されました。また、日本のパートナーである住商情報システムからは、日本語版アドバイザリも公開されています。
この脆弱性は、攻撃者が用意した特殊なBMPファイルをWindows Media Playerで再生した場合、バッファ・オーバーフローが発生し、悪意のあるコードが実行されてしまうというものです。.asxファイルやActiveX、スキン・ファイルなど複数の手段でWindows Media Playerにて攻撃用BMP画像を処理させる事ができます。分類的には、マシン・コードが実行可能な、受動的攻撃を成立させる脆弱性となります。
整数オーバーフローとMS06-005の詳細
さて、バッファ・オーバーフロー脆弱性と言っても非常に多くの種類があり、攻撃手法やその安定性もさまざまです。バッファ・オーバーフローで典型的なものとして知られているのは、strcpy(szDstBuffer,szSrcBuffer) のような境界チェックの無い文字列コピーですが、ここ数年はさすがにこのようなものはあまり見かけません。ここ数年で見つかっているバッファ・オーバーフローは、整数オーバーフローに起因するものが非常に多くの割合を占めています。
これは、整数オーバーフロー脆弱性が増えているという訳ではなく、単に境界チェックの無い文字列コピーなど典型的なものが少なくなってきているという事を示しています。開発・検査プロセスの見直しや教育などが効果的に働いているためか、今では全体的な脆弱性の数は随分と減ってきているように見受けられます。筆者は90年代後半から様々なソフトウエアの監査を行ってきました。昔は典型的な脆弱性を簡単に発見する事ができましたが、今では、典型的なものを発見することはほとんどなくなりました。
しかし、整数オーバーフローなど、比較的注意深く解析しないと発見できない脆弱性はまだまだ存在しており、やはり「探せば出てくる」というのが現状です。今回発表されたWindows Media Playerの脆弱性も、整数オーバーフローに起因するバッファ・オーバーフローです。
整数オーバーフローに起因するバッファ・オーバーフロー脆弱性にもいくつかの代表的なパターンがありますが、最も多いのが「0バイトのメモリを確保し、そのバッファ対してメモリコピーを行う」という状況を意図的に発生させられるというものです。
今回の脆弱性は、まさにそのパターンです。BMPのヘッダに記述されているサイズ・フィールドを0にする事で、Windows Media Player内ではその値に従ったメモリ確保を行います(実質16バイト)。しかしコピー・サイズは、サイズ・フィールドからBMPヘッダ・サイズ(14バイト)を引いたサイズ、すなわち、0x00000000-0x0000000E=0xFFFFFFF2バイト(十進数で4,294,967,282バイト)という値となります。
今後の傾向
現在、典型的なバッファ・オーバーフローなどについては、ソースコード・レベルなら既存のツールでほぼ検出する事ができます。また、バイナリ・レベルでも様々な手法が研究されており、うまく組み合わせれば高い確度で脆弱性の自動検出が可能です。eEyeリサーチ・チームでは、今回のような整数オーバーフローによる脆弱性の自動検出についても研究を行っており、一部の脆弱性はツール化された手法により自動検出に成功しています。脆弱性の自動検出についても、折を見てお話したいと思います。
