今回のコラムでは,最近明らかにされた Internet Explorer(IE)およびWindows NT/2000のセキュリティ・ホールについて,著者らが実施した検証実験の結果を報告したい。実験の結果,セキュリティ・ホールを悪用する攻撃が日本語環境に対しても可能なことが明らかとなった。コラムを読んで,対策の必要性を改めて認識してもらえれば幸いである。また,最近報告された「Apple QuickTime Player」のセキュリティ・ホールについても解説する。

HTTPヘッダー情報の取り扱いに問題

 まずは,マイクロソフトから2001年12月14日に「MS01-058」として公開された,IEのセキュリティ・ホールについて検証してみた。これは,WebページやHTMLメールを閲覧しただけで,任意のファイルを自動でダウンロードあるいは実行してしまうという,深刻なセキュリティ・ホールである(関連記事)。発見者はJouko Pynnonen 氏で,セキュリティ・ホールの詳細については,フィンランドのセキュリティ・ベンダー「Oy Online Solutions」から2002年1月14日に公開されている

 IEには,HTTPのヘッダー情報である「Content-Dispositionヘッダー」と「Content-Typeヘッダー」の取り扱いに問題があるため,このセキュリティ・ホールは発生する。

ユーザーをあざむくセキュリティ・ホール

 RFC 2183 で定義されているContent-Disposition ヘッダーは,HTML フォームからマルチパート・データをアップロードするときなどに,しばしば使用されるヘッダーである。マルチパート・データとは,1つのコンテンツ中に,複数種類のデータ(例えば,テキストと画像,など)を含むデータを指す。アップロードしたデータをファイルとしてローカルに保存する場合のファイル名などを,このヘッダーで指定する。

 Oy Online Solutionsの情報によれば,このContent-Dispositionヘッダーに“細工”を施すことで,ユーザーをだまして,任意のファイルをダウンロードあるいは実行させることが可能になるという。

 具体的には,ユーザー(クライアント)のリクエストに対して,悪意あるWeb サーバーがContent-Disposition ヘッダーに「README.TXT%00MALCIOUS.EXE」というファイル名を設定して,レスポンスを返すとする。すると,IE は「%00」より前の文字列だけしか,ダウンロードのダイアログ・ボックスに表示しない。つまり,ダウンロードしようしているファイルが,実際には「README.TXT%00MALCIOUS.EXE」という実行形式ファイルであるにもかかわらず,ユーザーには「README.TXT」というテキスト・ファイルであると思わせることができる。

 上記の場合には,ユーザーが表示にだまされたとしても,実行しない限りは問題はない。しかし,次に述べる Content-Type ヘッダーのセキュリティ・ホールを悪用すれば,勝手に実行させることが可能になってしまう。

勝手にファイルを実行してしまうセキュリティ・ホール

 Content-Type ヘッダーとは,Webサーバーがブラウザにコンテンツの内容を伝えるためのヘッダーである。例えば,コンテンツがHTMLファイルであれば,

Content-Type: text/html

となる。

 Content-Disposition ヘッダーの取り扱い同様,IEにはContent-Type ヘッダーの取り扱いにも問題がある。そのため,Content-Disposition ヘッダーに例えば「README.TXT%00MALCIOUS.EXE」がセットされ,Content-Type ヘッダーに「text/css」がセットされている場合,コンテンツを閲覧しようとしただけで,Content-Disposition ヘッダーに指定されたファイルが,何の警告もなく勝手に実行されてしまう。つまり,Webページ上のリンクをクリックしただけで,任意のプログラムが実行されてしまう恐れがあるのだ。

日本語環境でも再現

 筆者と LAC SNS チームのメンバーは,日本語版環境下でこの問題の再現を試みた。すると,「Windows 2000 Professional 日本語版 + IE 5.5」では,「Content-Type: audio/midi」とすると,リンクをクリックしただけで,Content-Dispositionで指定したファイルが自動的にダウンロードされ,かつ実行されることを確認した。

 また,「Windows 2000 Professional 日本語版 + IE 6」の環境では,「Content-Type: text/css」とセットすることで,同様の現象を確認できた。

 このセキュリティ・ホールは,ウイルスやワームの感染拡大に悪用され得る(関連記事)。例えば,特定Webサイトに置いたウイルス・ファイルを勝手にダウンロードして実行するようなリンクをHTMLメールに仕込んで配信することで,多数のユーザーを感染させることが可能となる。その場合,そのWeb サイトからウイルス・プログラムが消去されるまでの間は,感染が広がり続ける。

 このように,非常に深刻なセキュリティ・ホールである。そして,日本語環境でも再現されることが明らかとなった。IE にパッチを適用するか,さもなくば他のブラウザに乗り換えるなどして,対策を施すことが不可欠である。

「MS01-058」のパッチでは修正されないダイアログ・ボックス

 しかしながら,マイクロソフトが公開した「MS01-058」の修正パッチには欠陥があった。これを適用すれば,任意のファイルが勝手に実行されることは防げるが,ダイアログ・ボックスに表示されるファイル名を変更できてしまうセキュリティ・ホールはふさげない。

 この情報は,セキュリティ関連のメーリング・リスト「Bugtraq」で報告された。パッチを適用しても,「Content-Type: application/hta」としておくと,ダイアログ・ボックスには「%00」の前の文字列だけがファイル名として現れる。

 この問題についても,筆者らは実験を実施した。その結果,日本語環境下で再現することを確認した。

 この問題は,最近リリースされた「MS02-005」のパッチで修正できるようになったので,IEユーザーは早急に適用する必要がある*

* ただし,このパッチでも解消されない問題が複数あることが指摘されている。可能であれば,完全な修正パッチがリリースされるまでは,別のブラウザへ乗り換えるという手段もある。

Windows NT/2000 の TCP/IP の実装に DoS の問題

 次に,Windows 2000 および NT のDoS(サービス妨害)問題について実施した実験結果を解説する。この問題は,「3APA3A」氏が1月28日に Bugtraq メーリング・リストで報告したものだ

 これは,Windows NT/2000 の TCP/IP の実装に関する問題で,ACK フラグと FIN フラグがセットされた空の TCP パケットが,NetBIOS セッション・サービス用のポート (TCP 139番ポート)へ送信された際に発生する。

 Windows NT/2000マシン(システム)がこのパケットを受信すると,システムはメモリー・リーク(アプリケーションによって確保されたメモリー領域が,そのアプリケーション終了後も開放されないまま残ること)を発生させ,システムがブルー・スクリーンを表示してしまう。

 同氏は報告の中で,この問題が発生するかどうかは,標的にされたシステムに実装された物理メモリーの量,ネットワーク・ルーティングの状態,攻撃元との間のネットワーク帯域幅に依存するとしている。

 この問題の影響を受けるのは,Windows NT および 2000であるが,Windows 2000 については,そのサービスパック 2 (SP2)によって解消できる。そこで,筆者らは,パッチなどが公開されていない Windows NT についてのみ検証実験を実施した。

こちらも日本語環境で再現

 実験には,3APA3A 氏が公開している検証用プログラムを使用した。実験環境は,下記の通りである。

  • 日本語版 Windows NT Server 4.0
  • 日本語版 Internet Information Server(IIS)4.0
  • Windows NT 4.0 サービスパック 6a(SP6a)
  • 攻撃元ホストと標的ホスト間のネットワーク: 10Base-T

 以上の環境の場合,検証用コードによってメモリー・リークが発生することを確認した。ブルー・スクリーンは表示されなかったが,手動でシステムのシャットダウン を行うことが不可能となった。また,検証用プログラムを停止した後でも,メモリー・リークは解消されなかった。

 筆者は,NetBIOS セッション・サービス以外のポートにも,この問題が発生するのではないかと考え,IIS を稼働させている 80 番ポートへ,検証用プログラムを実行してみた。すると,同様にメモリー・リークが発生した。さらに,プログラムを停止した後でも,ブラウザで IIS へアクセスすることはできなかった。

 次に,この環境に Windows NT 4.0 セキュリティロールアップパッケージ(SRP) を適用し,TCP 139番ポートに向けて同様の実験を実施した。すると,いくらかのメモリー消費が認められたが,システムをシャットダウンさせることは可能であった。ただし,SRP適用前と同様に,消費されたメモリーは,検証用プログラムを停止した後でも解放されることはなかった。

 SRP適用後,TCPポート80番への実験も実施した。するとTCP 139番ポートの場合と同様に,いくらかのメモリーの消費が認められ,プログラム停止後もこのメモリーは開放されなかった。検証プログラムの実行中は,SRP適用前と同様,ブラウザで IIS へアクセスできなかったが,プログラム停止後はアクセスできた(きちんとトップ・ページが表示された)。

 以上の結果から,SRPを適用すれば,メモリー・リークの“程度”は減少するが,問題を解消するには至らなかった。

ファイアウオールで回避

 それでは,問題を解消するにはどうすればよいだろうか。この問題は,ACK フラグと FIN フラグのセットされた空の TCP パケットを受信してしまうことで発生する。ということは,TCP 通信を行う 2 ホスト間の 「3 ウェイ・ハンドシェイク」*を管理できるファイアウオールであれば,“異常な”パケットをフィルタリングできるので,この問題を回避できる。

*TCPで接続を確立するための手順。クライアントからサーバーへは接続要求として「SYN」フラグをセットしたパケットを送り,サーバーは接続許可として「SYN」と「ACK」をセットしたパケットを送り返す。そして,クライアントが「ACK」をセットしたパケットを送信すれば,接続が確立する。

 3 ウェイ・ハンドシェイクを管理できるのは,コネクションの状態まで調べるファイアウオール (ステートフル・インスペクション型ファイヤウオール),あるいはアプリケーション・ゲートウエイ型ファイアウオールである。もちろん,これらのファイアウオールで使用されるOSは,この問題の影響を受けるものであってはならない。

 今回の問題に限れば,ファイアウオールを適切に利用することで,直接的な被害を回避できるだろう。

Apple QuickTime Player に バッファ・オーバーフロー

 最後に,2月9日に報告された,Apple QuickTime Player のバッファ・オーバーフロー問題について解説する。これは,セキュリティ・サイト「Shadow Penguin Security」を主催する「UNYUN」氏によって報告された

 同氏の報告によれば,Web サーバーからの応答に含まれる Content-Type ヘッダーに,異常に長い文字列がセットされていた場合,QuickTime Player はバッファ・オーバーフローを引き起こすという。そのため,WebページやHTMLメールのリンクを介して,そのようなContent-Type ヘッダーを送信するWeb サーバーへQuickTime Playerを接続させれば,バッファ・オーバーフローを発生させて,任意のコードをユーザーのマシン上で実行させることができる。

 さらに悪いことに,QuickTime Player は User-Agent ヘッダーを含むリクエストを Web サーバーに送信する。User-Agentは,ユーザーのブラウザやOSの種類をサーバーへ伝えるための,HTTPヘッダーである。つまり,攻撃を試みるWebサーバーへ対して,ユーザーのOS情報を伝えてしまうのである。

 なぜこれが“まずい”かというと,バッファ・オーバーフローを利用した攻撃コードは,対象のOSやそのライブラリといった環境に依存することが多いため,正確にこれらを把握できなければ,攻撃を“成功”させることはできないのである。QuickTime Player は User-Agent ヘッダーにOS情報などを含めてしまうため,攻撃者はその内容をチェックすることで,“適切な”攻撃コードを送り込むことができてしまうのだ。

 同氏によれば,この問題に対する対策は,IE を使用している場合は ActiveX を無効にすること。また, Web サーバー上に存在する「.mov」ファイルを QuickTime Player で開く場合は,事前にそのmovファイルをメモ帳等のエディタで開き,リンクが埋め込まれていないかどうかを確認することで回避できる。


新井悠 (ARAI Yuu)
株式会社ラック コンピュータセキュリティ研究所
y.arai@lac.co.jp


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。