Windows の管理

Windows Vista カーネルの内部 : 第 3 部

Mark Russinovich

 

概要:

• 信頼性
• 回復
• セキュリティ

このシリーズでは、これまでプロセス、I/O、メモリ管理、システムの起動とシャットダウン、および電源管理に関係する Windows Vista カーネルの強化点について説明してきました。シリーズの最終回にあたるこの第 3 部

では、信頼性、回復、およびセキュリティの分野における機能と機能強化を見ていきます。

今回のシリーズで説明しなかった機能の 1 つにユーザー アカウント制御 (UAC) があります。UAC は、レガシ アプリケーション向けのファイル システムとレジストリの仮想化、管理者権限にアクセスするための権限昇格の同意、管理者権限で実行されるプロセスと同じアカウントで実行される権限の低いプロセスを分離するための Windows® 整合性レベル メカニズムなど、いくつか異なるテクノロジから成り立っています。UAC の内部情報については、TechNet Magazine の今後の記事で詳しく説明する予定です。**

Windows Vista™ では多くの新機能や機能強化により、システムの信頼性と、システムやアプリケーションの問題を診断する機能が向上しています。たとえば、Windows イベント トレース (ETW) のカーネル ロガーが常時アクティブになっていて、ファイル、レジストリ、割り込みなどの各種アクティビティのトレース イベントを循環バッファに生成しています。問題が発生すると、新しい Windows 診断インフラストラクチャ (WDI) によりこのバッファのスナップショットが取得され、これをローカルに分析したり、トラブルシューティングを行うために Microsoft サポートにアップロードすることができます。

ユーザーは、新しい Windows 信頼性とパフォーマンス モニタを使用して、クラッシュやハングなどのエラーと、システム構成に行った変更とを相互に関連付けることができます。ブートできないシステムをオフラインで回復するための回復コンソールに代わって、優れた System Repair Tool (SRT) が用意されています。

システムに対するカーネル レベルの変更に依存する分野は 3 つあります。そのため、この記事を詳しく調べるメリットがあります。この 3 つの分野とは、カーネル トランザクション マネージャ (KTM)、強化されたクラッシュ処理、および以前のバージョンです。

カーネル トランザクション マネージャ

ソフトウェア開発において退屈な作業の 1 つは、エラー状態の処理です。このことは、アプリケーションで一連の高度な操作を行っていく中で、ファイル システムやレジストリを変更する 1 つ以上のサブタスクを既に完了している場合に特に当てはまります。たとえば、アプリケーションのソフトウェア更新サービスでレジストリをいくつか更新し、アプリケーションの実行可能ファイルの 1 つを置き換えた後に、2 つ目の実行可能ファイルを更新しようとしたときに、アクセスが拒否されたとします。このサービスでは、このような結果としてアプリケーションを一貫性のない状態のままにしておくことができない場合、行ったすべての変更を追跡して、それらを元に戻す準備を行う必要があります。エラーを回復するコードのテストは困難で、その結果としてテストがスキップされることもよくあるので、回復コードのエラーによって、それまでの作業が無効になる可能性もあります。

Windows Vista 向けに作成されたアプリケーションでは、カーネル トランザクション マネージャによる NTFS とレジストリの新しいトランザクション サポートを使用して、ほとんど作業をする必要なしに、エラーの回復機能を利用できます。アプリケーションで関連性のある多くの変更を行う必要があるときは、分散トランザクション コーディネータ (DTC) と KTM トランザクション ハンドルを作成するか、直接 KTM ハンドルを作成して、ファイルやレジストリ キーの変更をトランザクションに関連付けることができます。すべての変更が正しく行われると、アプリケーションはトランザクションをコミットして、その変更を適用しますが、トランザクションを任意の時点までロールバックして、変更を破棄することもできます。

また、トランザクションがコミットされるまで、他のアプリケーションからはトランザクション内で行われる変更を確認できないことや、Windows Vista およびまもなくリリースされる Windows Server® "Longhorn" で DTC を使用するアプリケーションはトランザクションを SQL Server™、Microsoft® メッセージ キュー サーバー (MSMQ) などのデータベースと調整できることも大きなメリットです。したがって、KTM トランザクションを使用するアプリケーション更新サービスでは、アプリケーションが一貫性のない状態で残ることがなくなります。Windows Update とシステムの復元がどちらもトランザクションを使用している理由はこの点にあります。

KTM では、トランザクション サポートの中心部として、NTFS やレジストリなどのトランザクション リソース マネージャがあり、アプリケーションで行われる変更の特定のセットに対してその更新を調整できます。Windows Vista では、NTFS はトランザクションのサポートに TxF という拡張機能を使用します。レジストリは、同様のサポートに TxR という拡張機能を使用します。ユーザー モードのリソース マネージャが DTC を使用して、複数のユーザー モード リソース マネージャ間でトランザクションの状態を調整するのとまったく同様に、カーネル モードのリソース マネージャは KTM と連携動作して、トランザクションの状態を調整します。サードパーティも KTM を使用して、独自のリソース マネージャを実装できます。

TxF と TxR はどちらもファイル システム API とレジストリ API の新しいセットを定義します。これらの API は、トランザクション パラメータを含むことを除いて、既存の API と同じです。トランザクション内でファイルを作成するアプリケーションでは、まず、KTM を使用してトランザクションを作成します。その結果得られたトランザクション ハンドルを新しいファイル作成 API に渡します。

TxF と TxR は、どちらも共通ログ ファイル システム、つまり CLFS (%SystemRoot%\System32\Clfs.sys) の高速ファイル システムログ記録機能に依存します。CLFS は Windows Server 2003 R2 で導入されました。TxR と TxF は CLFS を使用して、トランザクションをコミットする前に、トランザクションの状態変化を永続的に保存します。そのため、電源が落ちた場合でも、トランザクションによる回復および保証を行うことができます。TxR では CLFS ログ以外に、図 1 に示すように、トランザクション変更を追跡するため、関連する複数のログ ファイルを %Systemroot%\System32\Config\Txr にあるシステムのレジストリ ファイルに作成します。併せてログ ファイルのセットをユーザーのレジストリ ハイブごとに分割します。TxF では、\$Extend\$RmMetadata というボリュームの隠しディレクトリに、ボリュームごとのトランザクション データを格納します。

図 1** システム レジストリ ハイブ TxR ログ記録ファイル **(画像を拡大するには、ここをクリックします)

クラッシュ サポートの強化

Windows では、不適切なデバイス ドライバ、ハードウェアの故障、オペレーティング システムなどが原因となる回復不可能なカーネル モードのエラーを検出すると、"死のブルー スクリーン" として知られる表示を行った後システムを停止し、ディスク上のデータが破損するのを防ごうとします。このとき、構成に応じて、物理メモリの一部またはすべての内容をクラッシュ ダンプ ファイルに書き込みます。クラッシュから再起動するときに、根本原因を探るため Microsoft Online Crash Analysis (OCA) サービスによってダンプ ファイルの分析が行われるので、ダンプ ファイルがあると役に立ちます。必要であれば、Microsoft Debugging Tools for Windows を使用してユーザー自身でもダンプ ファイルを分析できます。

ただし、以前のバージョンの Windows では、セッション マネージャ (%Systemroot%\System32\Smss.exe) が初期化済みのページング ファイルを処理するまではクラッシュ ダンプのサポートが有効になりませんでした。つまり、その時点よりも前にブルー スクリーンの原因となる重大なエラーが発生すると、ダンプ ファイルが存在しません。デバイス ドライバの初期化の大半は Smss.exe が開始する以前に行われるため、早い段階でクラッシュするとクラッシュ ダンプが行われず、原因の診断が極めて困難になります。

Windows Vista では、すべてのブート開始デバイス ドライバの初期化後、システム開始ドライバを読み込む前に、ダンプ ファイル サポートを初期化することによって、ダンプ ファイルが生成されない期間を短縮します。この変更により、起動プロセスの初期段階でクラッシュが発生した場合でも、システムでクラッシュ ダンプを取得でき、OCA が問題を解決するのを支援できます。さらに、Windows Vista ではデータが 64 KB のブロック単位にデータがダンプ ファイルに保存されます。それに対して、以前のバージョンの Windows では 4KB のブロック単位に書き込まれていました。この変更により、大きなダンプ ファイルの書き込みが以前に比べて 10 倍高速になります。

Windows Vista では、アプリケーションのクラッシュ処理も強化されています。以前のバージョンの Windows では、アプリケーションがクラッシュすると、ハンドルされない例外のハンドラが実行されました。このハンドラは Microsoft アプリケーション エラー報告 (AER) プロセス (%Systemroot%\System32\Dwwin.exe) を起動し、プログラムがクラッシュしたことを示して、エラー報告をマイクロソフトに送信するかどうかを問い合わせるダイアログ ボックスを表示します。しかし、プロセスのメイン スレッドのスタックが壊れ、ハンドルされない例外のハンドラが実行時にクラッシュすると、そのプロセスがカーネルによって終了させられ、プログラムのウィンドウが瞬時に消えて、エラー報告ダイアログ ボックスが表示されません。

Windows Vista では、エラー処理をクラッシュ プロセスのコンテキストから取り出し、Windows エラー報告 (WER) という新しいサービスに移行しました。このサービスは、サービス ホスト プロセス内部の DLL (%Systemroot%\System32\Wersvc.dll) によって実装されます。アプリケーションがクラッシュすると、依然としてハンドルされない例外のハンドラが実行されますが、このハンドラはメッセージを WER サービスに送信します。その後、WER サービスから WER フォールト報告プロセス (%Systemroot%\System32\Werfault.exe) が起動され、エラー報告ダイアログ ボックスを表示します。スタックが壊れ、ハンドルされない例外のハンドラがクラッシュすると、ハンドラはスレッドのスタック (スクラッチ メモリ領域) をすべて使い果たすまで実行とクラッシュを繰り返し、使い果たした時点でカーネルが介入して、クラッシュ通知メッセージをサービスに送信します。

図 2 と図 3 で、これら 2 つのアプローチを対比できます。この図では、Windows XP および Windows Vista での、クラッシュするテスト プログラム (Accvio.exe) のプロセス関係とエラー報告プロセスを緑色で強調表示して示しています。Windows Vista の新しいエラー処理アーキテクチャでは、マイクロソフトがエラー報告を取得し、ソフトウェア開発者がアプリケーションを改善する機会を得ることなくプログラムが自動的に終了することはなくなりました。

図 2a** Windows XP でのアプリケーション エラー処理 **(画像を拡大するには、ここをクリックします)

図 2b(画像を拡大するには、ここをクリックします)

図 3a** Windows Vista でのアプリケーション エラー処理 **(画像を拡大するには、ここをクリックします)

図 3b

ボリューム シャドウ コピー

Windows XP では、ディスク ボリュームの特定の時点のスナップショットを作成するボリューム シャドウ コピーというテクノロジが導入されました。バックアップ アプリケーションでは、このようなスナップショットを使用して一貫性のあるバックアップ イメージを作成できますが、それ以外の場合はスナップショットが表示されず、バックアップ プロセスの間のみ保持されます。

実際には、スナップショットはボリュームの完全なコピーではありません。正しくは、ライブ ボリューム データが、前回スナップショットが取得された以降に変更されたボリューム セクタのコピーでオーバーレイされる構成の、以前の時点からのボリュームのビューです。Volume Snapshot Provider ドライバ (%Systemroot\%System32\Drivers\Volsnap.sys) がボリュームを対象とした操作を監視し、セクタを変更する前に、セクタのバックアップ コピーを作成します。このとき、ボリュームのシステム ボリューム情報ディレクトリのスナップショットに関連付けられたファイルに元のデータを格納します。

Windows Server 2003 では、共有フォルダのシャドウ コピーにより、スナップショット管理がサーバーの管理者およびクライアント システムのユーザーに公開されます。この機能により、スナップショットの保存が有効になります。ユーザーは、エクスプローラでサーバーのファイル共有にあるフォルダやファイルの [プロパティ] ダイアログ ボックスを開き、[以前のバージョン] タブからこの保存したスナップショットにアクセスできます。

Windows Vista の以前のバージョン機能では、すべてのクライアント システムでこのサポートを利用でき、通常 1 日に 1 度、ボリュームのスナップショットが自動的に作成されます。このスナップショットには、共有フォルダのシャドウ コピーと同じインターフェイスを使用して、エクスプローラの [プロパティ] ダイアログ ボックスからアクセスできます。これにより、間違って変更または削除したファイルやディレクトリの以前のバージョンを表示、復元、またはコピーできます。技術的には新しいテクノロジではありませんが、ボリューム シャドウ コピーの Windows Vista の以前のバージョンの実装では、クライアント デスクトップ環境で使用するために、Windows Server 2003 の同等の機能が最適化されています。

Windows Vista では、ユーザーとシステムのデータ保護を一体化し、余分なバックアップ データの保存を避けるためにも、ボリューム スナップショットが利用されています。アプリケーションのインストールや構成への変更が不適切な動作や望ましくない動作につながる場合は、システムの復元 (Windows XP で Windows NT® 系列のオペレーティング システムに導入された機能) を使用して、復元ポイントが作成された時点に存在していたのと同じ状態にシステム ファイルやデータを復元できます。

Windows XP では、システムの復元により、ファイル システムのフィルタ ドライバ (ファイル レベルで変更を確認できるドライバの一種) を使用して、変更が行われた時点のシステム ファイルのバックアップ コピーを作成できます。Windows Vista では、システムの復元はボリュームのスナップショットを使用します。Windows Vista のシステムの復元ユーザー インターフェイスを使用して復元ポイントに戻ると、実際には、変更されたシステム ファイルの以前のバージョンが、復元ポイントに関連付けられたスナップショットからライブ ボリュームにコピーされています。

BitLocker

Windows Vista は、これまでにリリースされた Windows のバージョン中で最も安全な製品です。Windows Vista には Windows Defender スパイウェア対策エンジンが含まれているだけでなく、BitLocker™ フルボリューム暗号化、カーネル モード コードのコード署名、保護されているプロセス、Address Space Load Randomization、Windows サービス セキュリティとユーザー アカウント制御に対する強化など、さまざまなセキュリティや多層防御の機能が導入されています。

オペレーティング システムは自身がアクティブな間しかセキュリティ ポリシーを適用することができません。したがって、システムのセキュリティが物理的に侵害されるときや、オペレーティング システム外からデータがアクセスされるときに備えて、データを保護する別の手段が必要です。不正アクセスを防ぐためによく使用されるハードウェアベースのメカニズムには、BIOS パスワードと暗号化の 2 つのテクノロジがあります。こうしたテクノロジは、特に盗難や紛失の危険性が高いラップトップで使用されています。

Windows 2000 で導入された暗号化ファイル システム (EFS) は Windows Vista に引き継がれ、パフォーマンスの向上、ページング ファイルの暗号化サポート、スマート カードへのユーザー EFS キーの保存など、以前の実装を上回る多くの機能強化が行われています。しかし、レジストリ ハイブ ファイルなど、システムの重要な領域へのアクセスを保護するために EFS を使用することはできません。たとえば、グループ ポリシーで、ドメインに接続していない場合でもラップトップにログオンすることを許可している場合、ドメインの資格情報検証がレジストリにキャッシュされます。そのため、攻撃者はツールを使用してドメイン アカウントのパスワード ハッシュを取得でき、そのハッシュを使用して、パスワード クラッカーによりパスワードの取得を試みることができます。パスワードを入手した攻撃者は、アカウントと EFS ファイルにアクセスできることになります (スマート カードに EFS キーを格納していなかったことを前提としています)。

Windows Vista では、すべてのシステム ファイルやデータを含めてブート ボリューム (Windows ディレクトリのあるボリューム) 全体を容易に暗号化できるように、Windows BitLocker ドライブ暗号化というフルボリューム暗号化機能を導入しました。NTFS ファイル システム ドライバによって実装され、ファイル レベルで操作する EFS とは異なり、BitLocker は 図 4 に示すように、フルボリューム暗号化 (FVE) ドライバ (%Systemroot%\System32\Drivers\Fvevol.sys) を使用して、ボリューム レベルで暗号化を行います。

図 4** BitLocker FVE フィルタ ドライバ **(画像を拡大するには、ここをクリックします)

FVE はフィルタ ドライバなので、最初に BitLocker を使用するように構成されていれば、NTFS がボリュームに送信する I/O 要求をすべて自動的に監視し、そのボリュームに割り当てられたフルボリューム暗号化キー (FVEK) を使用して、書き込まれるブロックを暗号化し、読み取られるブロックの暗号化を解除します。既定では、128 ビット AES キーと 128 ビット ディフューザ キーを使用して、ボリュームが暗号化されます。I/O システムでは暗号化と復号化が NTFS の配下で行われるため、ボリュームは暗号化されていないかのように NTFS に表示され、NTFS は BitLocker が有効になっていることを認識する必要さえありません。ところが、Windows 外からボリュームのデータを読み取ろうとすると、ランダムなデータのように見えます。

FVEK はボリューム マスタ キー (VMK) で暗号化され、ボリュームの特殊なメタデータ領域に格納されます。BitLocker を構成するときに、システムのハードウェア機能に応じて、VMK を保護する方法に多くのオプションがあります。システムがトラステッド プラットフォーム モジュール (TPM) 仕様の v1.2 に準拠する TPM を備え、TPM が BIOS サポートに関連付けられていれば、TPM を使用して VMK を暗号化する (システムは TPM に格納されたキーと USB フラッシュ デバイスに格納されたキーを使用して VNK を暗号化します) か、TPM に格納されたキーとシステム ブート時に入力する PIN を使用してキーを暗号化できます。システムが TPM を備えていない場合、BitLocker では外部 USB フラッシュ デバイスに格納されたキーを使用して VMK を暗号化するオプションを提供します。どのような場合でも、暗号化されていない 1.5GB の NTFS システム ボリュームが必要になります。このボリュームには、ブート マネージャとブート構成データベース (BCD) が格納されます。

TPM を使用する利点は、BitLocker が TPM 機能を使用して、BitLocker が有効になった以降に BIOS やシステム ブート ファイルが変更される場合に、VMK の暗号化が解除されたり、ブート ボリュームのロックが解除されたりしないことを保証することです。システム ボリュームを初めて暗号化するとき、および上記のコンポーネントのいずれかで更新が行われるたびに、BitLocker はこうしたコンポーネントの SHA-1 ハッシュを計算し、各ハッシュ (計測値といいます) を、TPM デバイス ドライバ (%Systemroot%\System32\Drivers\Tpm.sys) の支援を受けて、TPM の異なるプラットフォーム構成レジスタ (PCR) に格納します。その後、TPM を使用して VMK をシールします。シールとは、TPM に格納された秘密キーを使用して、VMK と PCR に格納された値を、BitLocker から TPM に渡されるその他のデータと共に暗号化する操作のことです。BitLocker はシールした VMK と暗号化した FVEK をボリュームのメタデータ領域に格納します。

システムはブート時に独自のハッシュと PCR 読み込みコードを計算し、そのハッシュを TPM の最初の PCR に書き込みます。次に、BIOS のハッシュを計算し、その計測値を適切な PCR に格納します。続いて、BIOS がブート シーケンスの次のコンポーネント、つまりブート ボリュームのマスタ ブート レコード (MBR) のハッシュを計算します。このプロセスを、オペレーティング システム ローダーが計測されるまで続けます。それぞれ実行する後続のコードで、そのコードで読み込むコードの計測を受け持ち、計測値を TPM の適切なレジスタに格納します。最後に。ユーザーが起動するオペレーティング システムを選択するときに、ブート マネージャ (Bootmgr) がボリュームから暗号化された VMK を読み取り、シール解除を TPM に依頼します。オプションの PIN も含めてすべての計測値が VMK をシールした時点の値と同じである場合のみ、TPM は正しく VMK の暗号化を解除します。

この方式は、ブート シーケンスの各コンポーネントが次のコンポーネントを TPM に説明する、検証のチェーンと考えることができます。すべての説明が、TPM が受け取った元の説明と一致する場合のみ、TPM はその機密を開示します。そのため、ディスクが取り外され、別のシステムに設置された場合、システムが別のオペレーティング システムで起動された場合、またはブート ボリュームの暗号化されていないファイルが侵害された場合でも、BitLocker は暗号化されたデータを保護します。

コードの整合性検証

ルートキットなど、カーネル モードのデバイス ドライバとして実装されるマルウェアは、カーネルと同じ特権で実行されるため、識別や削除が最も困難です。このようなマルウェアは、事実上不可視になるように、カーネルやその他のドライバの動作を変更できます。Windows Vista のカーネル モード コード機能向けコードの整合性は、カーネル モードのコード署名 (KMCS) としても知られ、少数の証明機関 (CA) の 1 つによって検査を受けた開発者が発行およびデジタル署名したデバイス ドライバのみの読み込みを許可します。64 ビット向けの Windows Vista では、KMCS が既定で適用されます。

証明機関は自社のサービスを有償で提供し、ビジネスの整合性検証などの基本的なバックグラウンド チェックを実行するため、64 ビットの Windows Vista で実行される匿名のカーネル モード マルウェアを作成するのは困難です。さらに、検証プロセスを何とか擦り抜けたマルウェアでも、侵害されたシステムでそのマルウェアを発見したときに、作成者にたどりつく糸口を残す可能性があります。ドライバにユーザーのシステムをクラッシュするバグや、高品位のマルチメディア コンテンツのロックを解除する (後で簡単に説明します) バグが含まれている疑いがある場合、KMCS には、Windows Online Crash Analysis チームの連絡先を提供するような、補助的な使い方もあります。

KMCS は、Windows で 10 年間以上採用されてきた公開キー暗号化テクノロジを使用し、カーネル モード コードに信頼される証明機関の 1 つによって生成されたデジタル署名を含むことを要求します。発行者がドライバを Microsoft Windows Hardware Quality Laboratory (WHQL) に送り、そのドライバが信頼性テストに合格すると、マイクロソフトがそのコードに署名する証明機関の役割を果たします。ほとんどの発行者は WHQL を通じて署名を取得しますが、ドライバの WHQL テスト プログラムがない場合、発行者がドライバを WHQL テストに送ることを望まない場合、システム起動時の早期に読み込まれるブート開始ドライバの場合などは、発行者自身がコードに署名する必要があります。自身で署名を行うには、まず、マイクロソフトがカーネル モードのコード署名に対して信頼できると認める証明機関の 1 つからコード署名証明書を入手する必要があります。作成者は、その後、コードのハッシュをデジタルに計算し、秘密キーで暗号化することでそのハッシュに署名して、証明書と暗号化したハッシュをコードに含めます。

ドライバの読み込みを試みると、Windows はコードに含まれるハッシュの暗号化を、証明書に格納された公開キーを使用して解除してから、そのハッシュとコードに含まれるハッシュが一致するかどうかを検証します。同じ方法で証明書の信頼性をチェックしますが、この場合は、Windows に含まれる証明機関の公開キーを使用します。

また、Windows は関連する証明書チェーンを、Windows ブート ローダーとオペレーティング システム カーネルに埋め込まれたルート証明機関までチェックします。運用システムでは未署名の 64 ビット ドライバの読み込みが試みられることは一切ありません。WQHL テストに合格していることを確認する署名が含まれないドライバの読み込みが指示されたときに警告ダイアログ ボックスを表示するプラグ アンド プレイ マネージャとは異なり、64 ビットの Windows Vista は 図 5 に示すように、イベントをコードの整合性アプリケーション イベント ログに自動的に書き込み、未署名のドライバの読み込みを常にブロックします。32 ビット Windows Vista でもドライバの署名はチェックされますが、未署名のドライバであっても読み込むことができます。未署名のドライバの読み込みをブロックしてしまうと、Windows XP に読み込まれていたドライバを必要とするアップグレードされた Windows XP システムが機能しなくなります。未署名のドライバを読み込めば、Windows XP のドライバしか存在しないハードウェアのサポートも可能になります。ただし、32 ビット Windows Vista も未署名のドライバを読み込むときに、イベントをコードの整合性イベント ログに書き込みます。

図 5** 未署名のドライバの読み込み試行イベント **(画像を拡大するには、ここをクリックします)

一般的に、コード署名はコードが厳密なテストに合格した公式リリースであることを示すために使用されるため、発行者は通常テスト コードに署名することは望みません。そのため、Windows Vista には Bcdedit ツール (TechNet Magazine** の 2007 年 3 月号の私の記事を参照) を使用して有効または無効にできるテスト署名モードがあります。このモードでは、社内の証明機関が生成したテスト証明書で署名されたカーネル モード ドライバが読み込まれます。このモードは、プログラマがコードの開発中に使用することを目的に設計されました。Windows がこのモードで実行されているときは、図 6 のようなマーカーがデスクトップに表示されます。

図 6** Windows Vista テスト署名モード **

保護されているプロセス

Advanced Access Content System (AACS) でライセンスが許可された HD-DVD、BluRay などのフォーマットの次世代マルチメディア コンテンツは、今後数年でさらに一般的になります。Windows Vista にはこのようなコンテンツを再生するために ACCS 標準によって要求される多くのテクノロジが含まれています。このようなテクノロジをまとめて Protected Media Path (PMP) と呼びます。PMP には Protected User-Mode Audio (PUMA) と Protected Video Path (PVP) があります。この 2 つを組み合わせてオーディオとビデオのドライバやメディア プレーヤー アプリケーション向けのメカニズムを提供し、未承認のソフトウェアやハードウェアが高品位形式のコンテンツをキャプチャするのを防ぎます。

PUMA と PVP はオーディオとビデオのプレーヤー、デバイス ドライバ、およびハードウェアに固有のインターフェイスとサポートを定義しますが、PMP は Windows Vista で導入された、保護されているプロセスという一般的なカーネル メカニズムにも依存します。保護されているプロセスは、標準の Windows プロセス構成に基づきます。この構成は、実行中の実行可能イメージ、DLL、セキュリティ コンテキスト (プロセスを実行するアカウントとそのセキュリティ権限)、およびプロセス内のコードを実行するスレッドをカプセル化します。ただし、特定の種類のアクセスは防ぎます。

標準プロセスは、プロセスの所有者と "プログラムのデバッグ" 特権を持つ管理者アカウントにフルアクセスを許可するアクセス制御モデルを実装します。フルアクセスが許可されたユーザーは、プロセスにマップされたコードやデータを含めて、プロセスのアドレス空間を表示および変更できます。また、プロセスにスレッドを挿入することもできます。PMP では、高品位コンテンツおよびそのコンテンツを再生するプロセスに格納された Digital Rights Management (DRM) キーに未承認のコードからアクセスできないため、この種のアクセスは PMP の要件とは一貫性がありません。

保護されているプロセスでは、情報インターフェイスやプロセス管理インターフェイスの限定されたセットにアクセスが制限されます。このようなインターフェイスには、プロセスのイメージ名を照会するインターフェイスやプロセスを終了または中断するインターフェイスなどがあります。ただし、カーネルは保護されているプロセスの診断情報を作成します。この診断情報は、システム上のすべてのプロセスに関するデータを返す、汎用のプロセス クエリ機能を使用して入手できるため、プロセスに直接アクセスする必要はありません。メディアを危険にさらす可能性があるアクセスは、他の保護されているプロセスからのみ許可されます。

さらに、内部から危険にさらされることを防ぐために、実行可能イメージや DLL を含めて、保護されているプロセスに読み込まれるすべての実行可能コードには、保護された環境 (PE) フラグで Microsoft (WHQL) によって署名されているか、オーディオ コーデックの場合は、マイクロソフトから入手した DRM 署名の証明書で開発者によって署名されている必要があります。カーネル モード コードは、保護されているプロセスを含め、すべてのプロセスにフルアクセス許可を得られ、32 ビット Windows は未署名のカーネル モード コードを読み込むことができるため、カーネルでは保護されているプロセス用の API が用意されています。この API では、カーネル モード環境の "クリーン性" を照会し、その結果を使用して、未署名のコードが読み込まれていない場合のみプレミアム コンテンツのロックを解除します。

保護されているプロセスの識別

保護されているプロセスを具体的に識別できる API はありません。ただし、限定された情報しか入手できないことと、管理アカウントでもデバッグできないことを基に間接的に識別することができます。Content Scramble System (CSS) エンコードされた DVD の再生に使用するオーディオ デバイス グラフ アイソレーション プロセス (%Systemroot%\System32\Audiodg.exe) は、タスク マネージャのウィンドウで保護されているプロセスとして識別できます。これは、このプロセスが管理権限で実行されている場合でも、タスク マネージャがコマンド ライン、仮想化、データ実行防止の状態を取得できていないことからわかります。

audiodg の保護されているプロセスを表示するタスク マネージャ(画像を拡大するには、ここをクリックします)

Address Space Load Randomization

データ実行防止や高度なコンパイラ エラー チェックのような手段があるにもかかわらず、マルウェアの作成者は引き続きバッファ オーバーフローの脆弱性を探し、ネットワークに直接インターフェイスを持つ Internet Explorer® のようなプロセス、Windows サービス、およびサードパーティ アプリケーションに影響を与えて、システムへの足がかりを入手できます。ただし、プロセスへの侵入を成し遂げた後、ユーザー データを読み取ったり、ユーザー構成設定やシステム構成設定を変更して永久に存在したりという最終的な目標を実現するにはマルウェアは Windows API を使用する必要があります。

DLL が公開する API エントリ ポイントとアプリケーションとの接続は、通常、オペレーティング システム ローダーによって処理されます。ただし、この種のマルウェアに感染しても、ローダーのサービスの利点は得られません。これにより、特定の Windows リリースでは、システムの実行可能イメージと DLL が常に同じ場所に読み込まれ、マルウェアは API が固定アドレスに存在すると想定できるため生じていた以前のバージョンの Windows でのマルウェアの問題が引き起こされません。

Windows Vista Address Space Load Randomization (ASLR) 機能では、システムが起動されるたびにシステム DLL と実行可能ファイルを異なる場所に読み込むことによって、マルウェアが API の配置場所を把握できないようにします。メモリ マネージャはブート プロセスの早い段階で、ユーザー モードのアドレス空間の先頭にある 16 MB の領域の 64 KB 単位に整列された 256 個のアドレスの 1 つから DLL イメージの読み込みバイアスをランダムに選択します。イメージ ヘッダーに新しい動的再配置フラグを含む DLL がプロセスに読み込まれるとき、メモリ マネージャはその DLL をメモリに、イメージの読み込みバイアス アドレスから始めて、下位アドレス方向にパックします。

フラグ セットを含む実行可能ファイルも同様に扱われ、イメージ ヘッダーに格納された 16 MB のベース読み込みアドレス内の 64 KB 単位に整列されたランダムな位置に読み込まれます。さらに、特定の DLL または実行可能ファイルがそれを使用するすべてのプロセスによってアンロードされた後、再度読み込まれる場合、メモリ マネージャは読み込む場所をランダムに再選択します。図 7 に、32 ビット Windows Vista システムのアドレス空間レイアウトの例を示します。このレイアウトには、ASLR がイメージの読み込みバイアスと実行可能ファイルの読み込みアドレスを選択する元になる領域を含みます。

図 7** 実行可能ファイルの DLL の読み込みアドレスに関する ASLR の影響 **(画像を拡大するには、ここをクリックします)

動的再配置フラグは Windows Vista のすべての DLL と実行可能ファイルに含まれていますが、このフラグを含むイメージのみが再配置されます。これは、レガシ イメージを移動すると、開発者がイメージの読み込み場所に関して行っている内部的な想定に反する可能性があるためです。Visual Studio® 2005 SP1 では、このフラグの設定に関するサポートが追加されるため、サードパーティの開発者は ASLR を完全に利用できます。

DLL の読み込みアドレスとして 256 個の場所の中から 1 つをランダムに選択することで、マルウェアが API の正しい場所の推測が不可能になるわけではありませんが、ネットワーク ワームが伝播する速度を大きく制限し、システムに感染する機会を得ただけのマルウェアが確実に機能するのを防ぎます。また、ASLR の再配置方針は、アドレス空間が以前のバージョンの Windows よりも緊密にパックされるという二次的なメリットもあります。連続的なメモリ割り当ての大量の空きメモリ領域が作成され、アドレス空間レイアウトを監視するためにメモリ マネージャが割り当てるページ テーブル数が削減され、変換ルックアサイド バッファ (TLB) の不足が最小限に抑えられます。

サービスのセキュリティ強化

Windows サービスは、マルウェアの格好の攻撃対象になります。多くの Windows サービスは自身の機能にネットワークからアクセスできるようにしているため、遠隔地からシステムの攻撃に利用できるアクセス手段が公開される可能性があります。さらに、ほとんどのサービスが標準ユーザー アカウントよりも高い特権で実行されるため、マルウェアによって侵害できる場合は、ローカル システムでの特権を昇格する機会が与えられます。このため、Windows の進化が始まり、Windows XP SP2 では、サービスに割り当てられる特権とアクセスはサービスがその役割を果たすのに最低限必要なものに削減するように変更が行われました。たとえば、Windows XP SP2 にはローカル サービス アカウントとネットワーク サービス アカウントが導入され、以前サービスの実行に常に使用されていたローカル システム アカウントで利用できた特権のサブセットしか含まれていません。これにより、攻撃者がサービスを悪用したときに得られるアクセス許可が最小限に抑えられます。

ASLR の動作の確認

ASLR の効果は、Sysinternals の Process Explorer のようなツールを使用して、異なる 2 つのブート セッションのプロセスの DLL 読み込みアドレスを比較することによって、簡単に確認できます。次の 2 つのスクリーンショットは、異なる 2 つのセッションから取得したものであり、Ntdll.dll がエクスプローラに読み込まれる際、最初はアドレス 0x77A30000 に、次はアドレス 0x77750000 に読み込まれています。

ntdll.dll の異なるベース アドレス(画像を拡大するには、ここをクリックします)

ntdll.dll の異なるベース アドレス(画像を拡大するには、ここをクリックします)

前回の記事で、サービスをユーザー アカウントから分離し、独自のセッションで実行する方法を説明しましたが、Windows Vista でもほとんどのサービスに割り当てるファイル、レジストリ キー、およびファイアウォール ポートの特権やアクセス許可をさらに削減することによって、最小特権の原則の使用を拡張しています。Windows Vista では、各サービスに一意なサービス セキュリティ識別子 (SID) という新しいグループ アカウントを定義します。サービスは、そのサービスの SID のみがリソースにアクセスできるように権限を設定できます。その結果、サービスが侵害されても、同じユーザー アカウントで実行されている他のサービスにはアクセスできません。サービスの SID は、図 8 に示すように、sc showsid コマンドにサービス名を付けて使用することで確認できます。

図 8** サービス SID の表示 **(画像を拡大するには、ここをクリックします)

サービス SID では、特定のサービスが所有するリソースへのアクセスは保護されますが、既定では、サービスはそのサービスを実行するユーザー アカウントがアクセスできるすべてのオブジェクトに依然としてアクセス許可を所持します。たとえば、ローカル サービス アカウントで実行されるサービスは、ローカル サービスで実行される他のサービスが別のプロセス (ここでは、サービス SID を参照するオブジェクトが保護されます) に作成したリソースにはアクセスできません。ただし、ローカル サービス (および、サービス グループなど、ローカル サービスが所属する任意のグループ) がアクセス許可を持つすべてのオブジェクトの読み取りと書き込みは可能なままです。

そのため、Windows Vista では書き込みが制限されるサービスという新しい制限付きのサービスの種類が導入され、サービスからの書き込みアクセスを、サービス SID、Everyone グループ、およびログオン セッションに割り当てられた SID にアクセスできるオブジェクトに限定して許可します。これを実現するため、Windows 2000 で導入された制限付き SID を使用します。オブジェクトを開いたプロセスが書き込みの制限されたサービスのときは、アクセス チェックのアルゴリズムが変更され、制限付き形式でも制限なし形式でもプロセスに割り当てられていない SID を使用して、そのプロセスにオブジェクトへの書き込みアクセスを許可することはできません。次のコマンドを使用してサービスが制限されているかどうかを確認できます。

sc qsidtype [service]

他にも、サービスが作成するオブジェクトに、同じアカウントで実行される他のアカウントからのアクセス防止を容易にする変更が行われています。以前のバージョンの Windows では、オブジェクトの作成者はオブジェクトの所有者でもありました。所有者は、所有するオブジェクトへのフルアクセスが許可され、オブジェクトのアクセス許可の読み取りと変更が可能です。Windows Vista では、新しく Owner Rights SID が導入され、オブジェクトのアクセス許可にこの SID が存在すると、所有者のアクセス許可を自身が所有するオブジェクトに制限でき、さらにアクセス許可の設定と照会が削除されます。

Windows Vista では、サービスのセキュリティ モデルがさらに強化され、サービスの開発者は、サービスをシステムに登録するときに、サービスの操作に必要なセキュリティ特権を正確に制限できます。たとえば、サービスが監査イベントの生成を必要とする場合は、監査特権を指定できます。

サービス コントロール マネージャは 1 つ以上の Windows サービスをホストするプロセスを開始するときに、そのプロセス用にプロセス内のサービスが必要な特権のみを含むセキュリティ トークン (プロセス ユーザー アカウント、グループ メンバシップ、およびセキュリティ特権を一覧するカーネル オブジェクト) を作成します。実行するアカウントで利用できない特権をサービスが指定すると、そのサービスは開始されません。たとえば、ローカル サービス アカウント プロセスで実行されるサービスの中にプログラムのデバッグ特権を必要とするサービスが存在しない場合は、サービス コントロール マネージャはそのプロセスのセキュリティ トークンからその特権を取り除きます。したがって、サービス プロセスが侵害されても、悪意のあるコードはそのプロセスで実行されるサービスが明示的に要求しなかった特権を使用することはできません。sc qprivs コマンドは、サービスが要求した特権を報告します。

まとめ

今回は、Windows Vista カーネルの変更点を紹介してきた 3 部構成の記事のまとめです。アプリケーション開発者向けの新しいワーカー スレッド プール、共有のリーダー ロックとライタ ロックのような新しい同期メカニズム、サービス スレッド タグ、NTFS のディスク チェックとボリュームのサイズ変更のオンライン サポート、Advanced Local Procedure Call (ALPC) という新しいカーネル IPC メカニズムなど、今回のシリーズで説明しなかった機能と機能強化があります。こうした機能やその他の機能の詳細については、2007 年末に発行を予定している『Windows Internals』の次回のエディションを参照してください。**

書き込みが制限されるサービスの表示

Windows Vista では、1 つのサービス ホスト プロセスのみが制限付きのサービスをホストします。Process Explorer のようなプロセス表示ツールを使用して、このプロセスを次のコマンド ラインを備えたプロセスとして識別できます。

svchost -k LocalServiceNoNetwork

このプロセス内で実行するように構成されたサービスには、ベース フィルタ エンジン、診断ポリシー サービス、Windows ファイアウォール、パフォーマンス ログと警告、および Windows Media® Center Service Starter があります。

この画面にはベース フィルタ エンジンのサービス SID が NT SERVICE\BFE という形式で、Restricted フラグ付きで 1 回、フラグなしで 1 回一覧されています。したがって、このプロセスは、そのアカウントがアクセスできるリソースにアクセスできます。ただし、ローカル サービス アカウントが通常アクセスできる他のオブジェクトにアクセスできるとは限りません。たとえば、NT AUTHORITY\SERVICE アカウントは、プロセス トークンに制限フラグ付きで表示されていないため、このプロセスは、そのアカウントに書き込みアクセスが許可されているオブジェクトを変更できません。これは、そのアカウントがトークン内で制限フラグの付いた他のアカウントでも同じです。

プロパティ ダイアログ ボックスの一番下に一覧されている特権は、ローカル サービス アカウントが使用できる特権のサブセットなので、このプロセスで実行されるサービスも特権が制限されます。

サービスの SID フラグ(画像を拡大するには、ここをクリックします)

Mark Russinovich は、Microsoft の Platform and Services Division に所属するテクニカル フェローです。また、『Microsoft Windows Internals』 (Microsoft Press、2004) の共同執筆者であり、Microsoft Tech•Ed や PDC などの、IT カンファレンスや開発者向けカンファレンスで頻繁に講演を行っています。**彼は、共同で設立した Winternals Software 社の Microsoft による買収に伴い、Microsoft に入社しましたが、Sysinternals の設立者でもあり、同社では Process Explorer、Filemon、Regmon など、多くの人気のあるユーティリティを発表しています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.