検索
連載

もっと新しいエメット（EMET 5.2）さん、リ・リリース：山市良のうぃんどうず日記（29）

2015年3月に「EMET 5.2」が公開されました。実は、今公開されているEMET 5.2は“二度目”のリリースです。数日で差し替えられたEMET 5.2、いったい何があったのでしょうか？

[山市良，テクニカルライター] PC用表示 関連情報
Share
Tweet
LINE
Hatena
「山市良のうぃんどうず日記」のインデックス

連載目次

EMET最新版「5.2」がリリース。今度は大丈夫？

　マイクロソフトが提供する無償の脆弱（ぜいじゃく）性緩和ツール「Enhanced Mitigation Experience Toolkit（EMET）」については、本連載で何度も取り上げてきました。これまでいくつか不具合を指摘し、EMETのセキュリティ機能に過度に期待すべきではないとお伝えしてきました。

　EMETの最新バージョン「EMET 5.2」が、2015年3月12日（米国時間）に公開されました。EMET 5.2の新機能については、緩和策がいくつか強化されたと思えばよいです。ここであえて説明はしません。

　EMETが搭載している全ての緩和策をきちんと理解している人、理解できる人はいないでしょう。EMETが利用する脆弱性緩和策に関してはプロにお任せし、信じるしかありません。しかし、本当に信じてよいものかどうか、最近のEMETは不安にさせてくれます。

Windows 8.1のIE 11クラッシュ問題で数日後に差し替え

　2015年3月12日（米国時間）に公開されたEMET 5.2には不具合があり、数日後に修正版に差し替えられました。バージョン番号、ダウンロードファイル名、ファイルサイズは変わっていないため、問題のあるEMET 5.2をダウンロードしたのか、修正版のEMET 5.2をダウンロードしたのか分からないということもあるかもしれません。

　その不具合とは、Windows 8.1にEMET 5.2をインストール後、「Internet Explorer（IE）11」を開始すると「Internet Explorerは動作を停止しました」と表示され、クラッシュしてしまうというものでした（画面1）。

画面1
画面1　Windows 8.1にEMET 5.2をインストール後に、IE 11が開始直後にクラッシュするようになる

　筆者は、Windows 8.1の64ビット版と32ビット版の両方でこの問題に遭遇しています。これは筆者の想像ですが、特定の環境に依存する問題ではなく、Windows 8.1とEMET 5.2の標準的な設定で発生する問題だったと思います。

　なぜなら、問題を確認した1台は、Windows 8.1 Updateをクリーンインストールして、2015年3月までの全ての更新プログラムをインストールしただけのものでしたから。いち早くEMET 5.2にアップグレードしたWindows 8.1ユーザーの多くは、EMET 5.1に戻してしまったのではないでしょうか。

　EMET 5.2をアンインストールしてしまった方、アンインストールしてEMET 5.1を再インストールしたという方で、まだ修正版のリリースにお気付きでない場合は、たぶん、もう大丈夫です。修正版をダウンロードし直して再インストールしてください（画面2）。

画面2
画面2　修正版のEMET 5.2で、Windows 8.1におけるIE 11のクラッシュ問題は解消。修正版のバージョン番号に変更はなし

　EMET 5.2が不具合により差し替えられたということは、以下のブログの更新情報しかありません。

　2015年3月16日以前にダウンロードした場合は、不具合のあるEMET 5.2の可能性があります。しかし、修正後のバージョン情報、ダウンロードファイル名、ファイルサイズに変更がないため、すでにダウンロードしたファイルが修正版なのかどうかを判断するのは難しいでしょう。

　その場合は、ダウンロードファイル「EMET 5.2 Setup.msi」のデジタル署名を確認してみてください。デジタル署名が「2015年3月12日」の場合は不具合のあるEMET 5.2です。差し替えられた修正版のデジタル署名は「2015年3月17日」になっています（画面3）。

画面3
画面3　EMET 5.2をすでにダウンロード済みならデジタル署名を確認すること。左の画面が修正版のEMET 5.2、右の画面が不具合を含むEMET 5.2のインストーラー

　“たぶんもう大丈夫”と言ったのは、Windows 8.1の標準的な構成で問題が発生するようなものがリリースされてしまうことに対する疑念が残るからです。

　EMET 5.2はWindows Vista Service Pack（SP）2〜Windows 8.1、Windows Server 2003 SP2〜Windows Server 2012 R2までをサポートしていますが、これらサポート対象OSの全てできちんとテストされているのでしょうか。テストされているのであれば、今回の問題は発生するはずはなかったと思います。こうなると、他の脆弱性緩和策は機能するのか、いざというときに攻撃を防いでくれるのか、気になるのは筆者だけではないでしょう。

　ちなみに、修正版のEMET 5.2は、筆者のWindows 8.1環境で今のところは問題なく動作しています。ただし、脆弱性緩和策がちゃんと機能しているかというと、それは信じるしかありません。やはり、EMET 5.2は「補完的なセキュリティツール」として考えるべきであり、そのセキュリティ機能に過度に期待するべきではないでしょう。

さらに、EMET 5.0／5.1からのアップグレードにもご用心！

　この問題は以前も指摘しましたが、新バージョンへのアップグレード前に知っておくべき重要なことなのであらためて説明します。これらを知らないで使っていると、実はEMETは何もしていないのに、根拠のない安心感だけを得ているということにもなりかねないからです。

　一つ目の問題は、EMET 5.0またはEMET 5.1からEMET 5.2にアップグレードする（した）人に知っておいてほしいことです。

　EMETをカスタマイズして使用している場合は、EMET 5.2にアップグレードする際、設定を引き継ぐために「EMET Configuration Wizard」で「Keep Existing Settings」を選択すると思います（画面4）。

画面4
画面4　EMETをカスタマイズして使用している場合は、設定を引き継ぎたいので「Keep Existing Settings」を選択するはず

　しかし、EMET 5.0またはEMET 5.1から「Keep Existing Settings」を選択してアップグレードした場合、「アプリケーションの設定」（Application Configurationのアプリケーションの登録とMigration Settingsの状態）は引き継がれず、空っぽになってしまうでしょう（画面5）。

画面5
画面5　「Keep Existing Settings」を選択してアップグレードした結果。左の画面はEMET 5.1からEMET 5.2へのアップグレード、右の画面はEMET 4.1からEMET 5.2へのアップグレード

　また、「Add Certificate Trust rules for Microsoft online services」オプションをチェックした場合は、証明書信頼のWebサイトの保護設定（Protected Websites）とピンルールの設定（Pinning Rule）も全て上書きされてしまうと思います。

　この問題はEMET 5.1からのもので、EMET 4.xからのアップグレードでは期待通りに機能します。ユーザーズガイドを見てもこの動作が不具合なのか、仕様なのか（「一つ前のメジャーバージョンからの引き継ぎ」という意味なのか）は分かりません。しかし、「Keep Existing Settings」を選択すれば設定を引き継いでくれると、誰もが思うはずです。

　すでにアップグレードした人は、アプリケーション設定や証明書信頼の設定を再確認してください。設定が空っぽになっていたという方は、「EMET Configuration Wizard」を実行して、「Use Recommended Settings」を選択し、推奨設定を読み込んでから再設定するか、一から設定をし直すことになります。まだアップグレードしていないという人は、EMET 5.0／EMET 5.1から設定をエクスポートして、保存しておきましょう。アップグレード後にインポートして設定を復元できます。

Windows 7でEMETの証明書信頼は中間者攻撃をスルーしてしまう疑惑

　次の問題はEMET 5.0からのものですが、Windows 7ユーザーが知っておくべき不具合です。その不具合とは、証明書信頼（Certificate Trust）機能が期待通りに機能しないというものです。

　EMETが入っているから、SSL（Secure Sockets Layer）／TLS（Transport Layer Security）通信は安全と思っていませんか。Windows 7でEMET 5.xを使用している場合、EMETの証明書信頼機能は万が一のその時に何もしてくれませんよ。証明書信頼を適切に設定していたとしても、不正な証明書による中間者攻撃を完全にスルーしてしまうでしょう。

　EMETの証明書信頼機能は、EMET 4.0で導入されました。この機能は、ルート証明書と特定のドメインのSSL／TLS証明書の関連を事前にピンルールとして設定しておくことで、ルート証明書の変動を検出し、WebサイトへのSSL／TLSアクセスを警告してくれるものです。EMET 5.0からは警告だけでなく、アクセスをブロックする機能も追加されました。

　どのように動作するのか、この機能が正常に動作するWindows 8.1で試してみましょう。その方法は簡単です。でたらめなルート証明書を設定したルールを作成し、Facebookのドメイン「www.facebook.com」に設定します（画面6）。その状態でIEから「https://www.facebook.com」を開くと、EMETが警告またはブロックしてくれます（画面7）。

画面6
画面6　Windows 8.1のEMET 5.2の証明書信頼機能をテストするために、Facebookのドメインにでたらめなルールを設定し、IEでアクセスしようとしたところ
画面7
画面7　「ブロックルール（Blocking Rule）」を有効にすると、警告に加えてアクセスをブロックしてくれる

　Windows 8.1で期待通りの動作をした証明書信頼機能のテスト設定と同じものを、Windows 7のEMET 5.2に対して設定しても、警告やブロックは全く機能しません（画面8）。ちなみに、Windows 7上のEMET 4.xであれば、EMET 4.xはちゃんと警告してくれます。

画面8
画面8　前出の画面7と全く同じ設定をWindows 7のEMET 5.2に対して行っても、EMET 5.2は警告もブロックもしてくれない

　実は筆者は、Windows 7上のEMET 5.xでも、証明書信頼機能が正しく機能する方法を見つけています。その方法とは、「ユーザーアカウント制御（UAC）」を無効にすることです（画面9）。

画面9
画面9　Windows 7の「ユーザーアカウント制御（UAC）」を無効にすると、EMET 5.xの証明書信頼機能が動作する。でも、決して真似しないように

　しかし、EMETの証明書信頼機能を動かすためだけに、重要なセキュリティ機能であるUACを無効にするのはばかげているので、不具合の回避策にはなりません。Windows 7でEMET 5.2を利用するなら、EMET 5.2の証明書信頼機能の利用をあきらめるしかないでしょう。あるいは、緩和策は少なくなりますが、正常に機能するEMET 4.1 Update 1を利用するしかありません。

　EMET 5.2の初期リリースの不具合、既知の問題、これらをふまえてEMET 5.2を導入するか否か、そのセキュリティ機能に期待するか否かは、あなた次第です。筆者の場合、利用させてもらいますが、信用しているわけではありません。少なくとも、“EMETが入っているから大丈夫”“EMET最強”、なんて考えは持つべきではありません。あくまでも他のセキュリティ対策と組み合わせて使う、補助的な、脆弱性を“緩和”してくれる“かもしれない”ツールなのです。

「山市良のうぃんどうず日記」バックナンバー

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP：Hyper-V（Oct 2008 - Sep 2015）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。マイクロソフト製品、テクノロジを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る