英語版のマイクロソフト セキュリティ アドバイザリ (2269637) が 8/31 に更新されていることに触れましたが、 9/1 に日本語のページにも反映されていました。前回は 8/31 更新の大きな変更点を見逃していました。KB2264107 の更新プログラムに Fix It ボタン (Microsoft Fix it 50522) が追加されていたことです。前回も利用した脆弱性のあるアプリケーション (Media Player Classic) とその実証コードで効果のほうを検証してみました。
まず、この Fix It が、KB2264107 の更新プログラムを適用したコンピューターに対してのみ有効であることに注意してください。KB2264107 の更新プログラムは、LoadLibrary と LoadLibraryEx の既定の DLL 検索順序を制御する新しいレジストリエントリ CWDIllegalInDllSearch のサポートを OS に追加するもので、CWDIllegalInDllSearch のレジストリは作成してくれません。つまり、KB2264107 の更新プログラムを適用しただけでは、既定の DLL 検索順序は以前と全く変わりません。
Fix It は、レジストリに CWDIllegalInDllSearch を作成し、その値を“ある値”に設定して、既定の DLL 検索順序を変更します。CWDIllegalInDllSearch に設定可能な値はいくつかあるため、企業などで安易に Fix It を展開してしまうと、思わぬ副作用が出てくるかもしれません。Fix It を展開する前に、KB2264107 で説明されている CWDIllegalInDllSearch の動作をよく理解しておくべきです。
まずは実証コードで実証
前回使用したのと同じアプリケーション (Media Player Classic) と実証コードを、未対策の Windows XP SP3 で試してみました。拡張子 .mp3 を、デスクトップ上にコピーした mplayerc.exe (この実行ファイルは脆弱性はあっても、正当なもの) に関連付け、UNC パス上のMP3 ファイルをダブルクリックします。もしくは、MP3 ファイルを選択して「プログラムから開く」で mplayerc.exeを選択します。すると、MP3 ファイルと同じ UNC パス上にある、実証コードからコンパイルした DLL ファイル (隠しファイルにすれば見えません) がロードされます。これで DLL ハイジャックの脆弱性が実証されました (実証されたのは Windows ではなく、mplayerc.exe の脆弱性です)。
Fix It で対策後は DLL ハイジャックを回避
DLL ハイジャックされずに音楽再生♪ |
Fix It による対策後、同じ MP3 ファイルから mplayerc.exe を実行してみます。不正な DLL はロードされず、mplayerc.exe で音楽の再生が始まります。
これで一安心、いや、そうとも言えません。
Fix It で対策後も DLL ハイジャック !?
Fix It したのに DLL ハイジャックに成功しちゃった! |
Fix It の対策によって、DLL ハイジャックをブロックできた方は、ローカル (デスクトップ上のコピー) に存在する mplayerc.exe が実行されています。DLL ハイジャックが成功した方は、不正な DLL ファイルとは別の場所にある、UNC パス上の mplayerc.exe です (デスクトップ上のアイコンは UNC パスへのショートカットです)。
Fix It による対策は緩い !?
Fix It により作成されたレジストリ エントリを確認してみましょう。Fix It を実行すると、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 内に REG_DWORD 型の CWDIllegalInDllSearch が作成され、値に「2」が設定されていました。このレジストリ エントリは、Fix It 実行前は存在しませんでした。KB2264107 の説明によると、アプリケーションの存在するパスによって、次のように DLL 検索順序が変更されます。
(1) ローカルのアプリケーション ・・・ 現在の作業ディレクトリ (カレント ディレクトリ) がリモート (UNC または WebDAV) の場合、カレント ディレクトリからの DLL 読み込みをブロックする。
(2) UNC パス上のアプリケーション ・・・ 現在の作業ディレクトリ (カレント ディレクトリ) がリモート (UNC または WebDAV) の場合、カレント ディレクトリからの DLL 読み込みを許可する。
(3) WebDAV フォルダー上のアプリケーション ・・・ 既定の DLL 検索順序を使用する。
先ほどの例では、前者は (1) の効果で DLL ハイジャックを回避できましたが、後者は (2) に相当するため、MP3 ファイルと同じ UNC パス内 (カレント ディレクトリ)の不正な DLL ファイルの読み込みが許可されてしまったというわけです。試してはいませんが、mplayer.exe を WebDAV フォルダーに置いた場合は、DLL 検索順序は以前と変わらないため、別の WebDAV フォルダー パスや UNC パスに配置した不正な DLL ファイルによる DLL ハイジャックは成功するでしょう (たぶん)。
作業フォルダでカレント ディレクトリを設定できる |
アプリケーションのメンテナンスを簡単にするため、あるいはクライアントへの配信作業を省略するために、アプリケーションを UNC パスに配置するというのは、古くからよく使う方法です。アプリケーションのフォルダーは常に最初に検索されるので、(2) をブロックしても (正規の) DLL を読み取れないということにはなりません。しかし、カレント ディレクトリは、ショットカット ファイル (.lnk) を使えば明示的に指定できます。プログラムの本体とは別にの UNC パスに DLL を配置して、カレント ディレクトリで参照するような運用が無いとも限りません。
CWDIllegalInDllSearch を 0xFFFFFFFF にしてみた
0xFFFFFFFF に設定しても UNC パスのアプリは起動可能 |
既定の DLL 検索順序からカレント ディレクトリが削除されると、UNC パス上のアプリケーションが起動できなくなるのではと心配するかもしれません。必要な DLL が実行ファイルと同じパス内にある限り、カレント ディレクトリが検索順序から削除されても、問題はないと思います。既定の DLL 検索順序のトップは、アプリケーションの存在するフォルダーです。
しかしながら、ショートカット ファイルでのカレント ディレクトリの指定など、DLL 検索順序は複雑です。既定の検索順序の変更がアプリケーションにどんな影響を与えるかは、それぞれのアプリケーションでテストしてみるしかないでしょう。問題が発生した場合は、HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<application binary name> に CWDIllegalInDllSearch を作成して、例外の動作を設定できます。でも、できますが、大変な作業です。
Fix It で対策できるのはネットワーク経由のみ
Fix It では、USB メモリは対策できない |
CWDIllegalInDllSearch によって変わるのは、SMB または WebDAV がカレント ディレクトリの場合に限られます。USB メモリなど、リムーバブルメディアは引き続き検索対象のままですので、攻撃の媒介に悪用される可能性があります。何の危険性もないメディア ファイルと、不正な DLL ファイルが ZIP ファイル形式でまとめられて、電子メールに添付されてくるかもしれません。ZIP ファイルをローカルに展開したら、そこはローカルのパスです。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。