SearchFilterHost.exeの暴走原因はXml爆弾

以前記事にしたSearchIndexHost.exeの暴走がWindows 8.1でも発生することに気付いた。今回は暴走を引き起こしているファイルを特定できた。それはXml爆弾（またはBillion laghs）である。

/*-----------  -----------*/

暴走原因になったファイルを特定する方法

正確に言うと、暴走するのはWindows Searchサービスで、以下３種類のプロセスで構成されている。

これはWindows Sysinternals Suiteに含まれるProcess Explorer (procexp.exe) の画面である。なお右クリックから「管理者として実行」を選ばないと下側のリストが表示されないので注意が必要だ。

英語版のWikipediaの記事によれば、これらプロセスの内インデックス作成対象のファイルにアクセスするのはSearchProtocolHost.exeである。他のプロセス、SearchIndexer.exeはインデックス・データーベースの管理とAPIの提供を司り、SearchFilterHost.exeはインデックス作成対象の内容を解釈する役割を担っている。従ってSearchProtocolHost.exeが開いているファイルを監視すれば原因を特定できる。なおこれらの情報は英語版のWikipediaの記事に明記されているが、日本語版では省略されてしまっている（2014/5/5現在）。

少し調べてみて分かったのだが、暴走すると原因になったファイルを開いたままにしてしまうようなので、付っきりで監視する必要は無い。暴走したのが分かってから調べても十分間に合う。

プロセスが開いているファイルはProcess Explorerでも確認できるが、これだと要な情報と不必要な情報を目で見て区別しなければならない。同じくSysinternals Suiteに含まれたコマンドラインツールhandle.exeを使えば、findコマンドと組み合わせてある程度情報の絞り込みが可能である。

まず「コマンドプロンプト（管理者）」を開く。これには様々なやり方があると思うが、私は左下の窓アイコンを右クリックする方法を使っている。たぶん手数が一番少なくて済む。

handle.exeは名前の通り様々なハンドル情報を表示するが、今ほしいのはファイルに関するものだけなのでfindコマンドを使って情報を絞り込む。

「C:\Windows...」で始まっているものはSearchProtocolHost.exeが使うライブラリーなどを読み込むために開いたハンドルだと考えられるので、「E:\...」で始まっているのが暴走の原因となった可能性のあるファイルを開いているハンドルだ。２行あるが、どちらも同じファイルlol2.xmlに対して開かれている。

これだけでlol2.xmlが暴走の原因と断定するには根拠が弱いが、以下を確認できれば断定して良いはずだ。

1. lol2.xmlをインデックス作成対象になっていないフォルダーに移動すると暴走しなくなる。
2. lol2.xmlをインデックス作成対象のフォルダーにコピーすると再び暴走する。

暴走の原因がlol2.xmlだけとは限らない。他に原因があれば 1. の確認中に明らかになるから、それらも同様に扱えばすべての原因が特定できる。

lol2.xmlの正体

「E:\!UserData\Downloads\」は場所を変更した「ダウンロード」フォルダーである。ディフォルトの場所は「ユーザー」フォルダーの下なので、ディフォルトでインデックス作成対象に入っているはずだ。私の場合場所を移動した際に自動的にインデックス作成対象として別途登録されたらしい。「E:\!UserData\Downloads\GraphicsMagick-1.3.17\」は、場所を変更した「ダウンロード」フォルダーの下にGraphicsMagicのソース・パッケージを展開したサブフォルダーだ。lol2.xmlはそのパッケージに同梱されたlibxml2ライブラリー用のテストファイルの一つである。

「test\recurse\」フォルダーにはXml爆弾系のテストファイルが集められている。これらのテストファイルを扱うtestrecurse.cをザッと見ると、lol*.xmlファイルを解釈しようとしたときXML_ERR_ENTITY_LOOPエラーを返してxmlドキュメントの解釈を打ち切るのがlibxml2の正しい動作、と言うことらしい。これがlibxml2バージョン2.7以降はxml爆弾対策済であると言われることの実態である。

libxml2のやり方が正しいxml爆弾対策として広く世間で認められているのだと思うのだが、Microsoftの見解は違うようだ。

Windows Searchサービスは「test\recurse\lol*.xml」ファイルの内lol1、lol3、lol4およびlol5の内容について何とかインデックスを作成してしまう。しかしlol2に加えてlol6ではCPUを占有する現象が発生し、インデックスの作成が止まってしまう。

Xml爆弾について

このMsdnの記事はコチラの英文記事の翻訳らしい。人手が入っているようなので、機械翻訳にありがちな致命的な誤訳は無さそうだ。

Xml爆弾でWindows Searchサービスが暴走した時、SearchFilterHost.exeプロセスがCPUを占有してしまうが、SearchIndexer.exeプロセスとSearchProtocolHost.exeプロセスはCPUをほとんど消費せず「待ち」になっている。これは英語版のWikipediaに記載されていた各プロセスの役割分担とつじつまが合っている。メモリーに関してはSearchFilterHost.exeプロセスの使用量が増加するが、数十MB止まりで、Msdnの記事にあるようなGB単位でメモリーが消費される状況は発生していない。

デュアルコアCPUの場合なので、CPU50％は当該プロセスが完全に1コア占有した状態である。

Windows Searchサービスが使っているxmlライブラリーにはある程度Xml爆弾対策が施されているが、十分ではない、と言うことではないだろうか。

悪意を持って細工したxmlファイルをダウンロードさせることによりWindows Searchサービスのインデックス作成処理を止めることができ、CPUリソースを異常に消費させることができる。影響は致命的ではないのかもしれないが、Windows SearchサービスにはDoS攻撃を可能にする脆弱性が存在する、と言えるだろう。

対策

上記Windows Searchサービスの脆弱性をMicrosoftが修正するのが本来の対策である。この脆弱性はVista以降Windows 8.1まで存在しているはずだ。しかし修正が実施されるまでの間、回避策が必要になる。

以前の記事ではxmlファイルをインデックス作成対象から外す回避策を提案した。これだと暴走する問題は起こらなくなるがxmlファイルは検索対象から完全に外れてしまう。問題はxmlファイルの内容を解釈する際に起こっているので、それを防げば良いはずである。

「ファイルの種類: xml」について、「このファイルのインデックスの作成方法」を「プロパティのみインデックスを作成する」に設定すれば問題を回避できる。これなら少なくともファイル名はインデックスを使った検索の対象になる。

今回問題の原因となっているファイルを特定できるようになったので、xmlファイル全体のインデックスの設定は変えずに問題を起こしているファイルにだけ対策を施すことも可能になった。「インデックスを作成する対象」に「含まれる場所」を変えるか、問題を起こしているファイルを「含まれる場所」以外に移動する方法が考えられる。またファイルのプロパティ「全般」タブの「詳細設定」で「このファイルに対し、プロパティだけでなくコンテンツにもインデックスを付ける」のチェックをクリアするのも回避効果がある。

なおスクリーンショットの上のほうに「このフォルダーに適用する設定を選択してください。」とあるが、今変更しようとしているものはファイル単位の設定である。同じフォルダー内の他のファイルには影響しない。ただし「属性の詳細」を変更したファイルを他のフォルダーにコピー・移動すると、上記設定は元に戻ってしまう（コピー・移動先のフォルダーの設定が優先される）。

Windows Searchサービスが暴走している状態では、どの回避策もうまく適用できない場合がある。操作に対して期待した反応が返ってこない状態になるのだが、私の経験ではWindows Searchサービスを再起動することで大抵の場合回復できた。ただしWindowsの再起動が必要になる場合もあるので、アプリはできるだけ終了しておくのが無難である。

今回のまとめ

Xml爆弾に対する脆弱性が原因でWindows Searchサービスが暴走してCPUを占有する現象が発生する場合がある。影響は致命的ではないのかもしれない。また利用者側での回避策もある程度可能だ。

しかしこれは本来Microsoftが脆弱性を修正すべき問題だ。長きにわたり放置されているのは残念なことである。