Office 2010 のファイル検証機能
こんにちは、Office Security チームの David B Heise です。Office ファイル検証 (コード名 : Gatekeeper) 機能のテスティングをしています。Microsoft Office 2010 の新しいファイル検証機能については、いくつか誤解があるようです。ここでは、それらの誤解を解いて、ファイルを検証する理由とその方法について説明します。
バイナリ ファイルを検証する理由
ここ数年来、Office のバイナリ形式は必然的に発展し、規模が大きくなって複雑さを増しました。Office のバイナリ形式が複雑な理由は、これまでに他の場所で十分に議論されてきました (Joel Spolsky 氏の記事を参照) ので、ここではその話題には触れません。Office のバイナリ形式の詳細については、こちらの記事をご覧ください。バイナリ ファイルは悪意のある攻撃者によって標的のユーザーを感染させるための攻撃媒介として使用されることが判明し、対応を検討する必要がありました。私たちのチームでは、Office ファイル形式を使用した新手の攻撃がマイクロソフトに報告されるたびに、検証機能を使用して検証し、このような攻撃を防御できるかどうかを確認しています。今までのところ、成果は上々です。
Gatekeeper とは
Office のファイル検証機能は、そもそも、Publisher の PUB ファイルを検証するために Publisher 2007 で導入された機能です。この機能は、特定のバイナリ ファイルがアプリケーションの期待値に適合しているかどうかを検証します。Office 2010 ではこの機能が大幅に拡張され、Word、Excel、PowerPoint 用のバイナリ形式も対象となりました。ただし、この機能はバイナリ形式 (PUB、DOC、XLS、PPT など) 専用です。XML ベースのドキュメント (DOCX、XLSX、PPTX など) は検証しません。また、マクロや他のカスタム項目も検証しません。この検証機能は、ファイルの構造を検証するものです。たとえば、ifnt 値が 4 (特定のアイテムに対して無効な値) に設定されている FONTINDEX 構造を持つ XLS ファイルは、検証に失敗します。
動作のしくみ
信頼されていないバイナリ ファイル (信頼できる場所になく、信頼済みドキュメントでもない) が Word、PowerPoint、または Excel によって読み込まれるたびに、そのファイルは検証され、有効なファイルであるかどうかをチェックされます。このチェックでは、アプリケーションが分析しようとしているファイルの特定のビット、つまり関連のある OLESS ストリームが調べられます。有効であると判定された場合、そのファイルは通常のファイルとして開かれます。その場合は、何の問題もないので操作を進めてください。無効なファイルと判定された場合は、既定で保護されたビューに送られます。
このテキストをクリックすると、Backstage ビューが表示されます。このビューでは、ファイルをフル アプリケーションで開くかどうかを選択できます。この操作を行うと、このファイルは信頼済みドキュメントとしてマークされ、次回からこのファイルを開いても検証されなくなります。
このファイルでの作業を終えてアプリケーションを終了した後に、次のようなプロンプトが表示されることがあります。
このプロンプトは、検証に失敗したファイルを Windows エラー報告経由でマイクロソフトに送信するかどうかを選択できるように、(アプリケーションごとに) 多くて 2 週間おきに表示されます。もちろん、失敗したファイルの情報を共有したくない場合には、ファイルを削除していただいてかまいません。ただし、問題のファイルをマイクロソフトにお送りいただいて解析を受けることで、Office ファイルの検証機能を向上させることができます。
管理方法
ポリシーを使用した検証
多くの管理者 (またはセキュリティ意識の高いユーザー) は、検証に失敗したファイルを開くという考えには賛成しないでしょう。このため、ファイルの検証に失敗した場合の既定の動作を指定するグループ ポリシーが用意されています。これらのポリシーは、アプリケーション設定ごとに、アプリケーションのグループ ポリシー テンプレート内の "オプション\セキュリティ\セキュリティ センター\保護されたビュー" に用意されています。
レジストリを使用した検証
Office ファイル検証のさまざまな側面を制御できるように、各種のレジストリ キーが用意されています。
共通キー
HKCU\Software\Microsoft\Office\14.0\Common\Security\FileValidation \ReportingInterval - DWORD 値。Windows エラー報告にファイルを送信するように勧めるダイアログを表示する日数を制御します。
HKCU\Software\Microsoft\Office\14.0\Common\Security\FileValidation\DisableReporting - DWORD 値。1 に設定された場合、Windows エラー報告のダイアログの表示が無効になります (結果的に、ファイルの送信も無効になります)。
アプリケーション固有のキー
この例では Excel を使用しますが、これらのキーは "PowerPoint" と "Word" でも機能します。
HKCU\Software\Microsoft\Office\14.0\Excel\Security\FileValidation\EnableOnLoad - DWORD 値。0 に設定された場合、Office はファイルを検証しません。
HKCU\Software\Microsoft\Office\14.0\Excel\Security\FileValidation\DisableEditFromPV - DWORD 値。1 に設定された場合、検証に失敗したファイルの編集は許可されません。
Excel 固有のキー
HKCU\Software\Microsoft\Office\14.0\Excel\Security\FileValidation\PivotOptions - DWORD 値。ピボット キャッシュがあるファイルで、ピボット キャッシュの検証に関連する特定のオプションを制御します。
0 = ピボット キャッシュを検証しない
1 = 次の場合にピボット キャッシュを検証する: (1) ファイルがインターネットから開かれていて、そのファイルがインターネットからのものであるとプラットフォームによってローカルでマークされた場合。(2) ファイルが Microsoft Outlook 電子メールの添付ファイルの場合。(3) ユーザーが明示的に、保護されたビューでファイルを開いた場合。(4) インターネット コンテンツがキャッシュされている、既知の "安全でない可能性のある場所" でファイルがローカルに開かれているか、またはユーザーが特別に定義した信頼できない場所でファイルが開かれている場合。ただし、安全でない可能性のある場所にあるファイルを保護されたビューで開く設定が (別の) レジストリ キーを通じて無効になっている場合を除く。(5) ファイルが開いていて、読み込み時にピボット キャッシュが解析される場合。
2 = すべてのピボット キャッシュを常に検証する
スクリプティングを使用した検証
Office を基に構築されたカスタム ソリューションの場合は、そのセッションの間ファイル検証を無効にするアプリケーション オブジェクトに追加された、いくつかの興味深いプロパティがあります。また、Excel には追加のオプションがあり、ピボット キャッシュ (例: ファイルにキャッシュされているピボットテーブルとグラフ用のデータ) の検証を制御できます。以下に、これらの 2 つのオプションを Excel に設定する方法を示す PowerShell スクリプトの例を示します (ただし、FileValidation プロパティは Word と PPT にも適用されます)。
$excel = New-Object -comobject Excel.Application
# valid values are:
# msoFileValidationDefault = 0
# msoFileValidationSkip = 1
$excel.FileValidation = msoFileValidationSkip
# valid values are:
# xlFileValidationPivotDefault = 0 (do whatever you’d normally do, i.e. follow registry & default settings),
# xlFileValidationPivotRun = 1 (validate all pivot caches),
# xlFileValidationPivotSkip = 2 (don’t validate any pivot caches)
$excel.FileValidationPivot = xlFileValidationPivotSkip
すばらしい機能のようですが、効果はあるのでしょうか
ファイル検証機能は大幅に進歩し、従来より高速になりました。もちろん、ファイル検証を行うことでファイルを開くのに時間がかかるようになりますが、数ミリ秒程度のことです。実際には、検証に 1 秒以上かかる標準サイズのファイルを見つけるのに苦労することでしょう。大半のファイルは、1 ～ 100 ミリ秒で検証されます。もちろん、サイズが極端に大きく非常に複雑な構造を持つファイルなどで、従来でもそのファイルを開くのに 1 時間かかっていたとすれば、ファイル検証付きで開く場合にはさらに 1 秒以上余計にかかることでしょう。しかし、この場合は、その程度の時間増は気にならないでしょう。また、非常に複雑なファイルを開こうとしてファイル検証に 5 秒以上かかった場合は、検証を取り消して、保護されたビューで直接表示することができます。結局、そのようなファイルを普通に開いてもらうわけにはいかないのです。そうした場合、ハッカーは非常に複雑なファイルを作るだけで、みなさんのコンピューターを乗っ取ってしまうかもしれません。それこそが、このファイルの検証機能が阻止したいことなのですから。
さらに、検証に長い時間がかかるファイルに対しては必ず、ファイルが検証に失敗した場合に表示されるのと同じ Windows エラー報告プロンプトが表示され、解析のためにマイクロソフトにファイルを送るかどうかを選択できます。そのファイルが検証に成功したか、失敗したか、検証をスキップしたかどうかには関係ありません。
まとめ
ある日、開発者と話しているときに、こんな風に会話が進むとします。
「何を開発しているの」
「Office のファイル検証機能さ」
「それは何なの?」
「Office ファイルをチェックして、問題ないかどうか確認する作業だよ」
「じゃあ、この 2 年間というもの、ブール関数を書いてたってわけ?」
「そうだけど...でも、すごく重要な関数なんだよ!」
結局のところ、Office ファイル検証は、アプリケーションにそのファイルが有効かどうかを伝える Yes/No 関数に過ぎません。しかし、この関数は非常に重要なのです。実際、これが本当に複雑な関数であることは、ファイル形式の仕様をちょっと見るだけですぐにわかります。Office ファイル検証では、バイナリ ファイルをチェックしてファイルの大半のビットが有効であることを保証します。ファイルが無効という検証結果が信じられない場合、ユーザーの皆さんはそのファイルを信頼することも、私たちにご一報くださることもできます!
原文の投稿日: 2009 年 12 月 16 日 (水曜日) 午後 2:52 投稿者: OffTeam
これはローカライズされたブログ投稿です。原文の記事は、https://blogs.technet.com/office2010/archive/2009/12/16/office-2010-file-validation.aspx をご覧ください。