今度の Windows の脆弱性 (DLL ハイジャックの脆弱性) はいろんな意味で激ヤバか !?

実証コードが次々と...

先月初めのショートカット アイコン読み込みの脆弱性に続き、先週 (20/10/8/23) に公開されたセキュリティ アドバイザリもまた、すべての Windows バージョンに影響する (たぶん) だけに、IT 管理者やアプリケーション開発者の方々は、しっかりと情報収集し、最新情報を注視して追跡したほうがよいでしょう (昨日英語版が更新されていることに注意)。


マイクロソフト セキュリティ アドバイザリ (2269637) - 安全でないライブラリのロードにより、リモートでコードが実行される (2010/8/24 公開)
http://www.microsoft.com/japan/technet/security/advisory/2269637.mspx
http://www.microsoft.com/technet/security/advisory/2269637.mspx (英語、8/31更新)

この脆弱性、正確には Windows ではなく、アプリケーション側の脆弱性です。しかし、脆弱性を生み出してしまった原因は、それを排除してこなかった Windows API 側にもあるでしょう。アドバイザリは小難しくなっていますが、脆弱性のほうはいたってシンプルな手法であり、脆弱性を持つたくさんのアプリケーションが、実証コード (Exploit Code) とともに次々と公開されています。誰でも簡単に見つけられます。

さて、レガシー OS & アプリ 撲滅推進委員会 （自称）として、レガシー Windows に影響があるかどうかについて、いつもは“たぶん”とか表現があいまいになりますが、今回は明確にできそうです。なにしろ、攻撃手法がシンプルだし、実証コードの多くは数行なので、プログラミングの知識も必要ありません。

セキュリティ アドバイザリの「影響をソフトウェアおよび影響を受けないソフトウェア」は現在、「マイクロソフトはマイクロソフトのアプリケーションがライブラリを安全にロードしない脆弱性の影響を受けるかどうかについて調査中であり、お客様を保護するために適切な措置を講じます。」となっています。“マイクロソフトのアプリケーション”が調査対象となっており、サードベンダーのアプリケーションや自社開発のアプリケーションは、開発者側での調査が必要ということになります。そして、“適切な措置”は、サポート ライフサイクルの期間内にある Windows XP SP3 以降、Windows Vista SP1 以降、Windows 7、および Windows Server 2003 以降の Windows Server を対象に行われることになるでしょう。

DLL ハイジャック攻撃 (DLL プリロード攻撃) と呼ばれるゼロデイ攻撃のおそれがある今回の問題は、DLL (ダイナミック リンク ライブラリ) の読み込みを、完全修飾パスを使用せず、パス指定なしで Windows API の関数 (LoadLibrary や LoadLibraryEx や SearchPath) の検索に任せているアプリケーションに存在する場合があります。詳しいことは、こちら (DLL プリロード攻撃を防止するためのライブラリの安全な読み込み) を見ていただくとして、脆弱性のあるアプリケーションは、正しい DLL ファイルが検索される前に、作業ディレクトリ (カレント ディレクトリ) にある同名の不正な DLL を読み込んでしまうと、DLL ハイジャックが成功してしまいます。

レガシー Windows も確実に影響を受ける

攻撃者は、脆弱性のあるアプリケーションを見つけ (既に実証コードとともに多数明らかになっています)、そのアプリケーションに関連付けれれた拡張子を持つファイルを、不正なコードを含む DLL ファイルと一緒にネットワーク共有や WebDAV フォルダーに置いておくだけでよいのです。わざと脆弱性を持たせた、ちゃんと動くアプリケーションを広く配布して、不正な DLL を別の方法で呼び出させて攻撃することもできるでしょう。

Windows XP SP3 で検証済みの実証コードの 1 つを、7 月にサポート期限が切れた Windows 2000 Professional SP4 で試してみました。Media Player Classic (Windows Media Player ライクなフリーの再生ソフト) に .mp3 を関連付け、ネットワーク共有上のファイルをダブルクリックして再生しようとすると、同じ場所に配置した不正 な DLL が読みだされ、ハイジャックが成功しています。Windows Millennium Edition でも試してみましたが、同じ結果でした。


DLL 検索順序に起因する DLL プリロード攻撃の危険性は古くから知られていた !?

DLL 検索順序の変更に関する MSDN Library の文書
”Development Impacts of Security Changes in Windows Server 2003”
(Michael Howard, Security Windows Initiative, June 16, 2003)

LoadLibrary や LoadLibraryEx  が既定の DLL 検索順序に従ってカレント ディレクトリ内を先に検索してしまうことからくる攻撃の可能性は、古くから認識されていたことだったようです。Windows XP SP1 および Windows Server 2003 からは、セキュリティ上の理由から検索順序が変更され、カレンとディレクトリがシステム ディレクトリ (%Windir%\System32 や %Windir%\System) や Windows ディレクトリ (%Windir%) より後の 5 番目にくるように変更されました。それ以前 (Windows XP RTM 以前) は、アプリケーションの存在するディレクトリの次の 2 番目がカレント ディレクトリの検索順序でした (SearchPath は現在でもこの順)。この検索順序の変更により、LoadLibrary や LoadLibraryEx によって、Windows のシステム ファイルの DLL がハイジャックされることはなくなりました。しかし、それ以外の場所 (例えば Program Files\Common Files\Microsoft Shared の下の DLL など) の DLL がハイジャックされる危険は残り、それが今回問題になっている脆弱性につながることになりました。現在もこれらの関数が残されているのは、互換性が大きな理由なのでしょう。DLL 検索順序の変更は、当時、一部のアプリケーションで問題を発生されたようです (その一例: Outlook が誤ったバージョンの GAPI32.DLL をロードしてしまう)。

既定の DLL 検索順序が現在のものになったのは、正確に言うと、Windows XP SP2 および Windows Server 2003 からです。この変更は、Windows XP SP1 および Windows 2000 SP4 にも含まれますが、SafeDLLSearchMode というレジストリ エントリを作成する必要があります (参考: Dynamic-Link Library Search Order)。Windows XP RTM および Windows 2000 SP3 以前は、古い検索順序 (カレント ディレクトリが 2番目) なので、Windows のシステム ファイルの DLL をハイジャックされる危険があるぶん、危険性はさらに高くなるでしょう。

回避策は有効か?

セキュリティ アドバイザリでは、脆弱性の影響を緩和する 3つの回避策が示されています。

1 つは、カレント ディレクトリがネットワーク共有 (SMB) や WebDAV (HTTP) パスの場合に、DLL 検索順序からこれらのパスを削除するツールです。このツール (更新プログラム KB2264107) をインストールしただけでは、何の対策にもならないことにご注意を。既定の検索順序を制御するレジストリが利用可能になるだけで、その使い方はあなた次第というものです。たぶん、既定でネットワーク共有や WebDAV パスの検索を行わないように設定して、アプリケーションごとに必要に応じて例外を許可するという対応になると思います。また、このツールが提供されるのは、当然ながらサポート ライフサイクル期限内の Windows バージョンのみです。Windows 2000 以前はこの対策を講じることはできません。サポート対象の Windows バージョンを使用している場合でも、簡単に対策を講じることはできません。使用中のアプリケーションへの影響を十分に調査しなければ、アプリケーションの実行に支障をきたすかもしれません。既定の DLL 検索順序の動作を期待して意図的に作られたアプリケーションもあるはずです。

WebClient を無効にすると Web や SharePoint へは保存できなくなる

2 つ目の回避策は、WebClient サービスの無効化です。WebClient サービスのスタートアップを無効にすると、WebDAV クライアントは機能しなくなるので、WebDAV 経由の攻撃の試みをブロックできるというわけです。しかし、この対策による影響を考慮する必要があります。たとえば、Microsoft Office 2010 には Windows Live SkyDrive や SharePoint サイトに直接ファイルを保存できる新機能があります。この機能は、WebDAV を利用しています。

Windows 2000 で WebDAV を無効にしてみる

ユーザーの操作性を犠牲にしてでも、WebDAV の使用はやめましょうと決めたとします。それでも、Windows 2000 以前をどうするかという問題が残ります。Windows 2000 には WebClient サービスがありません。実は、Windows 2000 や Windows 9x は、Web フォルダー (msdaipp.dll) が WebDAV クライアントの機能を提供しています。WebDAV クライアントを無効にする正しい方法であるかどうかはわかりませんが、レジストリの登録を解除 (regsvr32 /u msdaipp.dll) することで機能しなくなります。ただし、WebDAV 以外への影響はわかりません。

3 つ目の回避策は、SMB (139/TCP、445/TCP) をファイアウォールでブロックすることです。これは、インターネットとの境界のルーターやファイアウォールにおける措置のことを言っているのだと思います。SMB のトラフィックをインターネットに流す、あるいは受信するようなファイアウォール構成で運用しているところは、まさか存在しないでしょう (そう思いたい)。家庭用のルーターも、NBT (NetBIOS over TCP) のTCP/UDP ポートと 445/TCP は既定でブロックされているはずです。問題は、不正な DLL が社内のネットワーク共有に入り込んでしまった場合です。企業内のネットワークでSMB のポートをブロックしたら、共有機能や認証機能、多くの管理機能が利用できなくなってしまうため、この回避策はとれません。また、SMB をブロックしたとしても、USB メモリなどのリムーバブル メディアを介した方法はブロックできません。

今回の問題は、効果的な対策を迅速に講じるというのが非常に難しいのがやっかいです。それも、どうやら Windows API がこの世に生まれたときから、時限爆弾のスイッチは押されていたようです。脆弱性のあるアプリケーションがどれくらいあるか、想像もできません。最終的にWindows 側に根本的な対策が講じられるのか、それともアプリケーションごとの対応になるのかについても、現時点ではわかりません。

似たような問題に ActiveX Kill Bit の更新があります。Visual Studio のあるバージョンに含まれていた問題のある ATL (Active Template Library) が原因で、脆弱性のある ActiveX コンポーネントが生まれてしまったという問題です。脆弱性については、対策済みの ATL を使用して再コンパイルするだけで解消するのですが、既にインターネットに配布されてしまった ActiveX コントロールは回収できません。そのため、脆弱性のある ActiveX コントロールが見つかるたびに、Internet Explorer のセキュリティ機能である「ActiveX Kill Bit」を利用してそのコントロールを無効にするように、問題のコンポーネントの識別子 (CLSID) をレジストリに登録する更新プログラムが、これまで幾度となくリリースされています。

さて、今回の問題は、どのような形で終息に向かうことになるのでしょうか。そして、レガシー Windows は、また一つ大きなセキュリティ問題を抱えてしまいました。