Download.Ject問題の根はIEの「セキュリティモデル設計」にある

マイクロソフトは「Download.Ject」による攻撃を防ぐためのセキュリティアップデートを公開したが、これだけで完全に問題を防ぐことはできないとする指摘が相次いでいる。

[高橋睦美，ITmedia]

　マイクロソフトは7月3日、「Download.Ject」による攻撃を防ぐためのセキュリティアップデートを公開した（7月3日の記事参照）。だがインターネット上では、このアップデートだけでは完全に問題を防ぐことはできないとする指摘が相次いでいるほか、実際に、別の手法を用いた攻撃の実証コードが公開されている。

　Download.Jectは、いったんInternet Information Services（IIS）に侵入し、そこにアクセスしてきたクライアントのコンピュータにInternet Explorer（IE）経由で入り込み、バックドアを仕掛けるトロイの木馬だ。6月24日以降活動が確認され、いくつかの大手サイトにこのコードが仕掛けられているとして、複数のセキュリティ企業／組織が注意を呼びかけてきた（6月26日の記事参照）。平行して攻撃の拠点となっていたロシアのWebサーバも突き止められ、閉鎖されている（6月28日の記事参照）。

　Download.JectはIE経由でクライアントに侵入する際に、ハードディスクに対してファイルの読み書きを行う「ADODB.Stream」オブジェクトとクロスゾーンスクリプティングの脆弱性を利用する。このADODB.Streamは、IEが備えるクロスドメイン セキュリティ モデル（後述）をかいくぐり、セキュリティ制限を受けることなく、Download.Jectが仕掛けた任意のファイルをローカルディスクに書き込んでしまうという。しかも注意すべきは、結果的に悪用されたとはいえ、ADODB.Streamのこのときの動作は、本来意図されたとおりの正常なものであるという点だ。

　これを踏まえてマイクロソフトが公開した修正プログラムは、レジストリキーを変更し、IEからADODB.Streamオブジェクトの実行を行えないようにするというものだ。これにより、ひとまずDownload.Jectによる侵入の試みはブロックすることができる。

　問題は、IEが備えるセキュリティモデルをかいくぐることができる方法は、ADODB.Streamオブジェクトだけではないという点だ。結局のところ、今回マイクロソフトが公開した修正プログラムは、症状を抑える役割は果たしても、問題を本質的に解決する――体質改善につながるものとは言えないようだ。問題の緊急性を重視し、ひとまず侵入を食い止める目的でリリースされたものである以上、仕方のないことかもしれないが。

　事実、別のあるActiveX オブジェクトを通じても、ADODB.Streamオブジェクトを利用する場合と同じように攻撃を仕掛けることが可能であり、実証コードも公開されている。このコードによる攻撃は、たとえマイクロソフトが公開したばかりの修正プログラムを適用してADODB.Streamを利用できないようにしていても、避けることは困難だ。

　WindowsとIEを利用しているエンドユーザーとしては、修正プログラムを適用し、ウイルス対策ソフトをこまめにアップデートして最新の状態に保ち、一方でマイクロソフトが紹介している手順に沿ってIEのセキュリティレベルを「高」に設定するほか、スクリプトやActive Xコントロールを無効にするといった対策で自衛するしかない。また、不審なURLはクリックせず、HTML形式で届いたメールもテキスト形式で確認するようにすれば、被害に遭う確率を下げることができるだろう。信用できないサイトはIE以外のWebブラウザを利用してアクセスするというのも1つの手だ。

根本的な問題は……

　こういった状況を踏まえ、セキュリティ関連メーリングリストへの投稿者らは、IEがよって立つところのセキュリティモデルの設計にこそ問題があるのではないかと指摘している。

　IEはドメインとゾーンに基づくセキュリティモデルを実装している。これに従えば、あるWebサイトを表示させているウィンドウから、別の異なるドメインのWebサイトの情報へアクセスすることはできない。つまり、ドメインをまたいでの（クロスドメインの）情報へのアクセスは行えないようになっている。ユーザーのローカルファイルシステムも1つのドメインとして認識されるため、Webブラウザに表示されているページとローカルシステムとの間では、ファイルの読み書きをはじめとするさまざまな操作が行えないよう制限が加わることになる。

　また、これらWebコンテンツは、信頼度に応じていくつかのゾーンに分けて管理される。IEの「ツール」-「インターネットオプション」を見れば分かるとおり、「インターネット ゾーン」「制限付きサイトゾーン」ではローカルリソースへのアクセスをある程度制限する、といった具合に、ゾーンごとにセキュリティレベルや挙動を設定できる。

　だが、この制限を越えてローカルリソースへのアクセスを実行できる「クロスドメインの脆弱性」の存在は、過去からたびたび指摘されてきた（2003年2月6日の記事参照）。こうした脆弱性を突かれると、本来ならば制限つきのゾーンで実行されるはずのスクリプトが、制限の緩いローカルマシンゾーンの権限で実行されてしまう。

　既にパッチが提供されているMHTMLの脆弱性やCHMファイル（HTMLヘルプファイル）の脆弱性も同種の問題だ（4月14日の記事参照）し、6月初めにもパッチ未公開の脆弱性が指摘されている。またこの問題は、IEだけに存在するわけではなく、Operaなど他のブラウザでも指摘されたことがある。

　こうした経緯を踏まえてある投稿者は、IEのセキュリティモデルの設計が問題であり、あまりに簡単にシステム内のコンポーネントへのアクセスを許していることが根本的な原因だと指摘している。

　脆弱性につながっている機能は、Webアプリケーションを提供する側にとっては便利なものだ。たとえばADODB.Streamは、フォームのダウンロード／送信といった機能に利用されている。したがって、マイクロソフトが提供する修正プログラムを適用すると、Webアプリケーションの挙動に副作用が生じることは避けられない。そもそも、IEのセキュリティレベルを「高」に設定し、各種スクリプトやActiveXコントロールを無効にするとまともに閲覧できるサイトは少なく、Windows Updateでさえ例外ではない（この場合は必要に応じて「信頼済みサイト」に追加することで対応できる）。

　だが、Webブラウザの多機能化が、攻撃者に付け入られる脆弱性を増やし、さまざまな問題を引き起こしていることも事実である。セキュリティと利便性の間で、Webブラウザには果たしてどういった挙動を許すべきかについて、開発者、ユーザー、そしてベンダーがともに、今一度考え直すべき時期に差し掛かっていると言えるだろう。