再会、EMET

震災の瞬間、筆者はスマートフォンのセキュリティについて解説するセミナーで講師を務めていた。免震の建物があれほど揺れるとは思わなかったし、講演終了後に、徒歩で会社に戻る必要があった。1時間半かかった。その最中、同じく徒歩で会社を目指す同僚の用意していたワンセグには刻々と被害の様子が伝えられていった。多くの人が犠牲になった今回の震災について、改めて被災者の方々、犠牲者の方々にお悔やみ申し上げます。

自分にできることと言えば、情報セキュリティにおいて震災で何が起こったのか? 情報セキュリティに携わる者として最初に書き伝えるべきだと思ったが、それは後々書き起こすとして、今回のテーマはEMETである。というのは、知人に再度調査して書いて欲しい! という熱いメッセージをいただいたためである(遅くなってすいません)。EMETは過去にふれた内容であるが、その後バージョンアップを重ね、いまやMicrosoftの公式サポート対象となっている。その上、後々書き起こすと宣言している内容に触れる事柄であるために、まずは先に対策について詳細に書き記す次第である。

EMETはメジャーバージョンが2となり、かつて筆者が紹介した頃とは機能的な面で改良が図られている。今回はその改良された面について解説を行う。よって、以前の解説の補強と位置づけていただいても結構である。

EMET2ならびに2.1での主な変更点は次のようなものだ。

1. 正式名称の変更(Enhanced Mitigation Evaluation ToolkitからEnhanced Mitigation Experience Toolkitへ)
2. GUIの追加
3. ASLRの強制(Mandatory ASLR)
4. EAF (Export Address Table Access Filtering)
5. Bottom-up Randomization

1.と2.は省略するとして、3.以降が主要なポイントといえよう。

ASLRは、Windows Vista以降でサポートされている機能である。これを使用することによって、バッファオーバーフローに代表される、メモリを緻密に操作する攻撃の成功確率を低減することができる。ただし、ASLRのサポート対象のEXEやDLLファイル毎にこの機能を明示的に使用する、とコンパイル時に設定しておく必要がある。よって、このASLR使用宣言の「抜け」が生じた場合には、そこを悪用される可能性がある。事実、Adobe ReaderのCVE-2010-2883の脆弱性を悪用するコードには、icucnv36.dllというASLRが適用されていないモジュールを、ROPテクニックを使用したシェルコードとして使用することによって、攻撃を成功させている。こうしたALSRの適用漏れを悪用されると、Windows Vistaや7上においても脆弱性が悪用可能になるのだ。

EMET 2から追加されたASLRの強制は、こうしたASLRを使用すると明示していないモジュールにその強制を行うものである。そうすることで、特定のアドレス依存になっているシェルコードの実行を抑止することができる。

実際にその様子をWindows 7上でデバッガを使用し、Adobe Reader 9.3.3をサンプルとして検証してみた。EMETでASLRを強制する前のicucnv36.dllのベースアドレスは次の図のようになった。

ベースアドレスというのは、モジュールが読み込まれる開始アドレスであり、言い換えれば、必ずこのアドレスを開始地点にicucnv36.dllがロードされるということである。よって先の図で示しているシェルコードは、固定のアドレス(ROPガジェット)を組み合わせることで、攻撃を成功させることができる。

他方で、EMETを使用してASLRを強制させるとどうなるか。

全く異なるベースアドレスで開始されている。しかも、このベースアドレスの値はASLRの効果により、毎回異なるものに変更されるのである。その結果、シェルコードは正確に動作することができなくなり、プログラム、この場合はAdobe Readerはクラッシュして終了することになる。クラッシュすることはあまりいいことではないが、シェルコードによる攻撃が成功するよりははるかに影響は少ない。なお、最新版のAdobe Readerではicucnv36.dllはASLRが適用される対象に変更されている。

注意しておくべきポイントは、本機能はVista以降でしか使えない。よってWindows XPなどはその恩恵にはあずかれないということである。