Hebikuzure's Tech Memo

2012年3月5日

保護モードの昇格ダイアログを理解する

Filed under: Internet Explorer — hebikuzure @ 7:36 PM

Understanding the Protected Mode Elevation Dialog
http://blogs.msdn.com/b/ieinternals/archive/2009/12/01/understanding-internet-explorer-security-protected-mode-elevation-dialog.aspx

ずいぶん古い記事になりますが、今まで Windows XP 環境のユーザーが Windows 7 / Windows 8 の環境に更新するケースは今年多そうなので、改めて確認する意味でも意外と知られていない保護モードの動作についての話題を一つ訳してみました。特に「許可しない」をクリックしている限りはこのダイアログが永遠に出続ける、という話は興味深いですね。

以下の文章は EricLaw’s IEInternals の 2009/12/01 の記事 Understanding the Protected Mode Elevation Dialog を hebikuzure が私的に試訳したものです。翻訳については Microsoft Corporation および日本マイクロソフト株式会社とは無関係に hebikuzure が公開情報に基づき独自に行ったものであり、この文書の内容についての文責は公開者である hebikuzure にあります。翻訳の内容および技術的内容については正確を期すよう十分な注意を払っておりますが、誤りや不正確な部分が含まれている可能性がありますので、本文書を利用される際には原文も併せてご確認ください。


保護モードの昇格ダイアログを理解する

EricLaw [MSFT]

2009年11月30日 午後6時56分

Internet Explorer 7 では、ブラウザーとそのアドオンが最小限の権限のセットで実行される事を確実にする機能として、保護モードが導入されました。“権限低”のプロセスで実行されているコードには、皆さんのユーザー プロファイルやレジストリ キーに書き込む権限が無いため、悪意のある人がブラウザーやそのアドオンの脆弱性を見つけようと企んでも、被害が限定されるようになっています。

互換性を確実にするため、保護モード内のコードがその権限が制約された場合でも動作し続けるよう、システムの仮想化が保護モードで利用されています。

場合によっては、仮想化は予期しない結果をもたらします。Mark Russinovich が彼のブログ記事「The Case of the Phantom Desktop Files」で解説しているのはその一例です。そうしたびっくりはさておき、特定の機能は適切に仮想化する事ができません—例えば現在のユーザーのデスクトップの壁紙を変更する機能を提供したいとしたら、そのコードではどうしてもユーザー プロファイルに書き込む必要があります。

IE はこのセキュリティーと機能性のトレードオフをどのように解決しているのでしょうか? 答えは”ブローカーを使うこと”です。このアイデアでは、Internet Explorer (と Flash や Java のような一部のアドオン) は”権限中”のブローカー プロセスを起動し、コンテンツが保護モードのサンドボックス内で表示されている場合には通常禁じられている、現在のユーザー権限の利用が可能になります。ブローカー プロセスは (呼び出しコードに悪意がありサンドボックスを回避しようとする場合もあるので) 信頼できない呼び出しを受け付けないよう慎重に設計し、データをサニタイズし、セキュリティー センシティブな動作は変更を行う前に確認を行うようにする必要があります。

保護モード内で動作しているアドオンがブローカー プロセス (やその他の全てのプログラム) を起動する場合には、プロセスをどのように起動するべきかを確認するために ElevationPolicy レジストリ キー ({HKLM/HKCU}\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy) がチェックされます。四つのポリシー値のいずれかが指定されています:

ポリシー

結果

0

保護モードはプロセスを起動しない。

1

保護モードはブローカーを整合性レベル「低」でサイレントに起動する。

2

保護モードはユーザーにプロセスを起動する許可を求める。許可が得られれば、プロセスは整合性レベル「中」で起動される。

3

保護モードはブローカーを整合性レベル「中」でサイレントに起動する

ブローカー プロセスが昇格ポリシーを適切に登録していない場合、問題が生じます。ElevationPolicy が検知されなかった場合の既定のポリシーは #2 で、ユーザーにプロセスを起動する許可を求めるプロンプトが表示されます。ブローカー プロセスのこの動作は、ユーザー エクスペリエンスに混乱をもたらす場合があります。例えば、Flash のブローカーの昇格ポリシーがレジストリから欠落すると、Flash を使っているどのページでも以下のような表示が出てきます:

一般的なユーザー (と熟練ユーザーの大半) はブローカーが何であるか、またどうしてこのダイアログが表示されるのか分からないだろう事を忘れないでください。そうした人たちは、これをどうにかするためには “許可する” か “許可しない” のいずれかをクリックすればよい事は理解できるでしょう。しかしアドオンが次にブローカー プロセスを起動しようとした際、ユーザーにはこれと同じプロンプトがまた表示されます。簡単に想像できるでしょうが、これにはすぐにうんざりするでしょう。

“許可しない” ボタンのクリックに飽き飽きしたユーザー (実際にはブローカー プロセスが何であり、なぜ存在しているのか理解してはいないのですが) は、”許可しない”ボタンをクリックする前に”このプログラムについての警告を表示しない”チェックボックスをチェックするでしょう。

残念ながら、この行為は役に立ちません— “このプログラムについての警告を表示しない”チェックボックスは、”許可する”ボタンを押す場合にのみ有効です—このプロセスについて自動的にアクセスを拒否する事はできません。

どうしてでしょうか? これは意図に反していろいろと問題を生じさせ、その場合普通の人では何が問題であるかを確認し、それを修正する方法が無いからです。アドオンのブローカーを起動しようとする試みは常に失敗しますが、その試みは繰り返し行われる (そしてブラウザーをハングさせる) でしょう。しかもなお悪い事に、ユーザーが元に戻って考え方を変える方法が無いのです— HKCU ElevationPolicy レジストリ キーが更新された後で、それを反転できるようなユーザー インターフェイスを作成する、合理的で実現可能な方法はないのです。

アドオンの開発者は、アドオンのインストール時にそのブローカー プロセスに対する ElevationPolicy が適切に設定されるように確実を期してください (そしてブローカー プロセスがいつもアクセス拒否エラーで失敗する場合はそのプロパティを確認し、ユーザーにしかるべく通知する事を望みます)。

保護モードの昇格プロンプトが予期せず表示されるエンド ユーザーは、プロンプトの原因となったアドオン (多くの場合明確にわかります) を再インストールするか、不明であったり不必要であったりするアドオンを無効にする事を検討すべきです。攻撃の対象側面とプロンプトを減らすだけでなく、不要なアドオンの無効化は多くの場合ブラウザーのパフォーマンスを向上させます。

-Eric

コメントする »

まだコメントはありません。

RSS feed for comments on this post. TrackBack URI

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

WordPress.com で無料サイトやブログを作成.

%d人のブロガーが「いいね」をつけました。