Outlook Express 5.5に，テキスト・メールに埋め込まれたスクリプトを実行してしまうセキュリティ・ホールが見つかった。「HTMLメールを開かなければ，スクリプトを実行することはない」というのが“常識”であるため，メールがテキストなのかHTMLであるのかをチェックしてから開いているユーザーも多いと思う。今回のセキュリティ・ホールを悪用すれば，そんなユーザーの裏をかくことができてしまう。他のセキュリティ・ホールと組み合わせることも容易なので，設定変更するなどして対策を施しておく必要がある。

　上記のセキュリティ・ホールに加え，今回のコラムでは「ActivePerl」および「CDE（Common Desktop Environment）」のあるプログラムで見つかったセキュリティ・ホールについても解説する。対象となる製品（プログラム）のユーザーは早急に対策を施してほしい。

テキスト・メールにスクリプトを埋め込めてしまうぜい弱性

　セキュリティ情報を公開するWebサイト「penetration technique research site」を主催する Eiji James Yoshida 氏は 11月18日，Outlook Express 5.5 のセキュリティ・ホールを公表した。Outlook Express 5.5 は，テキスト・メール（具体的には，「Content-Type」 が「text/plain」であるメール）に書かれた，JavaScriptなどのスクリプトを勝手に実行してしまう恐れがある。

　スクリプトはHTMLメール中に記述しなければ，メーラーによって実行されることはない。テキスト・メール中に書いても，それは単なるテキストとして表示されるだけである。しかしながら，Outlook Express 5.5 はそれまでもスクリプトとして解釈してしまう。

　発見者である Yoshida 氏は，この問題について次のように語ってくれた。

　「不意打ちには“もってこい”のぜい弱性と言えるでしょう。『スクリプトが埋め込まれている恐れがあるので HTMLメールは開きたくない。しかし，HTML メールを解釈しないようなメーラーに移行するのは面倒』というユーザーの中には，メールを開く前に『プロパティ』メニューから『Content-Type』をチェックして，テキスト・メールなら（具体的には，『text/plain』なら）開封するというユーザーも少なくないでしょう。そのようなユーザーに影響を与える恐れがあります」

　ただし，このセキュリティ・ホールを悪用するには制限がある。同氏のアドバイザリによると，メールの本文が60文字（正確には60バイト）を超えると，スクリプトを実行しないという。そのため，複雑なスクリプトを実行させることはできない。

　しかし，このことがセキュリティ・ホールの影響度を下げることにはならない。メール中には，あるWebページを表示させるようなスクリプトだけを記述しておいて，リンク先のWebページに悪質なスクリプトを用意しておくことなどが可能であるからだ。この場合，メールを開いたときにはInternet Explorer（IE）が立ち上がるだけだが，リンク先のページがIEで表示されたときに，深刻な被害を受けることになる。

　さらに，他のセキュリティ・ホールと組み合わせることで，より深刻な影響を与えることが可能となる。例えば「不正なドットなし IP アドレスにより Web ページがイントラネット ゾーンで処理されてしまう (MS01-051)」が考えられる。

　メールに仕込んだスクリプトで，強制的に「不正なドットなし IP アドレス」のWebサイトのページへとジャンプさせるようにする。こうすることで，リンク先のページを「イントラネットゾーン」のセキュリティ設定で表示させることができてしまう（「不正なドットなし IP アドレス」については「今週のSecurity Check」[Windows編] を参照のこと）。

　やり方によってはいくらでも悪用が可能であるため，深刻なセキュリティ・ホールの一つであると言える。Outlook Express 5.5 のユーザーは対策を施す必要がある。この問題を回避するための具体的な手順を以下に示す。

　まず，Outlook Express の[ツール] メニューから [オプション] を選択し，開いたウインドウの [セキュリティ] タブを選択する。そして，「使用する Internet Explorer セキュリティゾーンを選択してください」の項目を「制限付きサイトゾーン」に設定する。加えて，IE の [インターネットオプション] から ，「制限付きサイトゾーン」のアクティブスクリプトを無効にする。IE 5.01 SP2/5.5 SP2/6.0 についてはデフォルトで無効になっているが，これ以外のバージョンでは有効になっているので，設定変更する必要がある。

　また，当然のことながら，別のメーラーに乗り換えることも，有効な回避策の一つである。

　なお， Outlook Express 6.0 にも同様の問題があることが報告されている。しかしながら，こちらについてはデフォルト設定では再現しない。それに対して，今回公表された問題はデフォルトで再現されるので，十分注意が必要だ。

IIS用のPerlプログラムにバッファ・オーバーフロー

　次に，「ActivePerl」に含まれる，Internet Information Server/Services（IIS）用の ISAPI Extension「perlIS.dll」で見つかったセキュリティ・ホールについて解説する。

　ActivePerl とは，米ActiveState によって開発された，Perlの実行環境を提供するソフトウエア・パッケージである。Perlのインタプリタやライブラリなどで構成される。その中に含まれる perlIS.dll を IISサーバーにインストールしておけば，「.pl」拡張子を持つ Perlのスクリプト・ファイルがリクエストされた際に，そのファイルを解釈実行して，その結果をユーザーに返す。

　今回のセキュリティ・ホールを発見した，中国のセキュリティ・ベンダー「NSFOCUS Information Technology」によると，Windows 用の ActivePerl 5.6.1 build 629 以前のバージョンに含まれている perlIS.dll には，バッファ・オーバーフローのセキュリティ・ホールが存在するという。

　perlIS.dll は，IIS から渡されたリクエストの文字列を，固定長のバッファ領域へそのままコピーしてしまう。そのため，異常に長い URL を含むリクエストを受け取った場合には，バッファ・オーバーフローが発生してしまう。このバッファ・オーバーフローを悪用すれば，リモートから任意のコードをサーバー上で実行することが可能となる。任意のコードは，IIS 5.0 であれば「IWAM_マシン名」の権限で， IIS 4.0 であれば Local System 権限で実行されることになる。

　同社のアドバイザリを受けて，筆者が所属する「LAC SNS Team」では，以下の環境で再現性を調べてみた。

  • Windows NT 4.0 Server 日本語版
  • 日本語版 Windows NT 4.0 Service Pack 6a
  • 日本語版 IIS 4.0
  • ActiveState ActivePerl 5.6.1 build 629 (.msi パッケージからのデフォルトインストール)

　その結果，上記環境のデフォルト設定では，再現しないことが判明した。詳しく調べてみると，Windows において， [インターネットサービスマネージャ] -> [アプリケーションの拡張子マッピングの追加/編集] -> [ファイルの存在を確認する] のチェックが有効になっている場合には，再現しないようである。このチェックはデフォルトで有効になっている。このチェックを外して試したところ，確かに再現した。

　デフォルト設定で未然に防がれているとはいえ，問題があるプログラムを使い続けるのは決して得策ではない。この問題は ActivePerl 5.6.1 build 630で解消されているので，アップグレードすることを強くお勧めする。

CDEで使われる「dtprintinfo」プログラムにセキュリティ・ホール

　最後に，筆者らが発見した「dtprintinfo」のセキュリティ・ホールを紹介する。dtprintinfoは，米IBM の AIX OS に付属するプログラムで，パスは「/usr/dt/bin/dtprintinfo」である。CDEで使用されるプログラムで，具体的には「CDE Print Manager」ウインドウを開くためのプログラムである。通常 SUID root の権限（パーミッション）でインストールされる。

　同プログラムには「-session」というオプションが用意されており，このオプションとセッション・ファイル名を指定することで，デスクトップ環境をセッション前の状態に復元できる。今回の問題は，この「-session」オプションで発生する。「-session」オプションで指定するファイル名が異常に長い文字列である場合，dtprintinfo は バッファ・オーバーフローを発生させてしまう。したがって，この問題を悪用すれば，ローカルのユーザーはdtprintinfoの権限で，すなわち root権限で，任意のコードを実行できてしまう。

　この問題を修正するためのパッチ（efix）を米IBMは既に用意している。同社サイトから入手可能なので，対象ユーザーは早急に適用することをお勧めする。

　このセキュリティ・ホールをリモートから悪用することはできない。対象マシンにログインできる一般ユーザーが，権限を昇格できるだけである。しかしながら，決して軽視できない。このセキュリティ・ホールに限らず，ローカルからの権限昇格の問題は軽視されがちであるが，一般ユーザーでの侵入手段を見つけられ，そこからローカルの問題を悪用して root 権限を取得するというシナリオは，ごくありふれたものである。

　例えば，安易なパスワードを使用している一般ユーザーを見つけ出し，そのユーザーになりすましてリモートからログインし，ローカルからの権限昇格を悪用して root権限を取得することは十分可能である。決して軽視せず，きちんと対策を施すことが不可欠である。

謝辞

　本稿執筆にあたって，Outlook Express のぜい弱性に関するコメントを快く寄せていただいた Eiji James Yoshida 氏に，この場を借りて感謝いたします。

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

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