本「
IT談話館」一般公開記事は、10年以上の実務経験を持つ上級Windowsエンジニアを想定しています。
本館は、Windowsカーネル深層を解析し、クラッシュ原因をはじめとするシステム内の「異様な動き」を検出・分析する
超高度な技術と実績を保有しています。
Windows APIとWindowsセキュリティー
本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草されています。「本館」主筆の「豊田孝」はDKOM(Direct Kernel Object Manipulation)ベースの解析手法の第一人者であり、Windowsカーネル空間の解析分野では世界の先頭を走っています。
現在、セキュリティー問題を無視することはできません。Microsoft社側の負担だけではなく、同社製品の利用者側の負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点から「Windows10ソフトウェアセンサー」を見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
- Silo/Server Silo
- Job
- Session
- Protected Process
- Mandatory Integrity Control(MIC)
- Windows API(+CPU)
- CPU
本稿では、上記リストにある「Windows API(+CPU)」に関連するMitigationフラグという名称のフラグを取り上げます。このフラグはWindows 10のバージョン1703からバージョン1709への移行時に導入されたものであり、Windows 8から導入された「SetProcessMitigationPolicy」API関数経由で操作されます。つまり、関数パラメータがカーネルプロセスオブジェクトにセットされ、各種セキュリティー保護機能を制御できるようになっています。このAPI関数の仕様はMicrosoft社の「このページ」から公開されています。また、「このページ」からはCPUのMicroarchitecture対策APIが公開されています。
セキュリティーの観点からは、状況に応じてセキュリティー保護機能を制御できる利点は大きいといってよろしいと思います。本稿では、Windows 10 1709 Creators Update環境で採取された複数のActive Memory Dumpを本「IT談話館」の独自解析コードで解析し、Windows 10 1703環境のセキュリティー保護機能との相違点、並びに、2018年1月3日に表面化した「Meltdown and Spectre」問題への対応状況を調査します。
「Meltdown and Spectre」問題表面化以前のバージョン1709システム環境におけるMitigationフラグのデフォルト値と各プロセスオブジェクトの関係概要は次のようになっています。
0: kd> vertarget
Windows 10 Kernel Version 16299 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 16299.15.amd64fre.rs3_release.170928-1534
Machine Name:
Kernel base = 0xfffff802`e5a99000 PsLoadedModuleList = 0xfffff802`e5dfafb0
Debug session time: Thu Nov 30 09:08:09.753 2017 (UTC + 9:00)
System Uptime: 1 days 1:29:36.413
MitigationFlags->0x00000060 System
MitigationFlags->0x00000121 smss.exe
MitigationFlags->0x00000121 csrss.exe
MitigationFlags->0x00000021 wininit.exe
MitigationFlags->0x000001a1 services.exe
MitigationFlags->0x00000021 lsass.exe
MitigationFlags->0x00000021 WUDFHost.exe
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00004039 fontdrvhost.ex
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x01000821 svchost.exe
[---]
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00000040 MemCompression
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x01000821 svchost.exe
[---]
MitigationFlags->0x00000021 SecurityHealth
MitigationFlags->0x00000000 armsvc.exe
MitigationFlags->0x008800a1 MsMpEng.exe
[---]
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00000121 csrss.exe
MitigationFlags->0x00000021 winlogon.exe
MitigationFlags->0x00004039 fontdrvhost.ex
MitigationFlags->0x00000021 dwm.exe
MitigationFlags->0x00000021 sihost.exe
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00000021 taskhostw.exe
MitigationFlags->0x00000001 explorer.exe
MitigationFlags->0x00000039 ShellExperienc
MitigationFlags->0x00000039 SearchUI.exe
MitigationFlags->0x000000b1 RuntimeBroker.
MitigationFlags->0x000000b1 RuntimeBroker.
MitigationFlags->0x00000021 ctfmon.exe
MitigationFlags->0x00000021 MSASCuiL.exe
[---]
MitigationFlags->0x00000021 chrome.exe
MitigationFlags->0x00000021 chrome.exe
MitigationFlags->0x00000021 chrome.exe
MitigationFlags->0x00a900a1 chrome.exe
MitigationFlags->0x00a910a1 chrome.exe
MitigationFlags->0x0cad01bd dllhost.exe
MitigationFlags->0x00000021 ApplicationFra
MitigationFlags->0x00800539 MicrosoftEdge.
MitigationFlags->0x00000021 browser_broker
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00a80039 Windows.WARP.J
MitigationFlags->0x000000b1 RuntimeBroker.
MitigationFlags->0x00a8c03b MicrosoftEdgeC
MitigationFlags->0x000000b1 RuntimeBroker.
MitigationFlags->0x00a8053b MicrosoftEdgeC
MitigationFlags->0x00a8c53b MicrosoftEdgeC
MitigationFlags->0x000000b1 RuntimeBroker.
MitigationFlags->0x00a8053b MicrosoftEdgeC
MitigationFlags->0x00a8c53b MicrosoftEdgeC
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00a8c53b MicrosoftEdgeC
MitigationFlags->0x00000021 ImeBroker.exe
MitigationFlags->0x1c000021 SystemSettings
[---]
Mitigationフラグは、2017年秋に公開されたCreatorsと一般に呼ばれているWindows 10 1709で導入されたフラグであり、Windows 10 1703には存在しません。ただし、フラグを構成する個々のビットのいくつかは以前のWindows 10のプロセスオブジェクトにも存在していましたが、どちらかといえば、取り急ぎ追加された印象があり、オブジェクト内のあちこちに散乱している状態でした。Mitigationフラグは散乱していた複数ビットをFlagとして整理する方向で構成されています。この整理はちょっとした散乱状態の解消といった意味合いも否定できませんが、将来の仕様変更や保守の効率化と経費削減に寄与することは間違いありません。
上の情報の中には、「MitigationFlags->0x00000000 armsvc.exe」などのデータが含まれ、セキュリティー保護機能が一切無効となっているプロセスも存在していることが分かります。そのようなプロセスの多くは、旧式の32ビットプロセスです。外部からの攻撃の入り口になる恐れもありますから、現在稼働しているこのような32ビットアプリケーションには注意したいところです。カーネル層へ侵入し、価値ある情報を狙っている人々は、研究熱心であり、ちょっとした入り口を再利用する高度な技術力を備えています。
赤色で強調されている数値は、現在のブラウザ市場を二分しているGoogle社のChromeとMicrosoft社のEdgeそれぞれにおけるWin32k入力機能を抑制制御するフラグの値です。フラグ値をビット分解してみますと、2つのブラウザはWin32k入力機能を次のように制御していることが分かります。
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 chrome.exe
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 chrome.exe
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 chrome.exe
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 chrome.exe
Disabled->1 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 chrome.exe
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 MicrosoftEdge.
Disabled->0 AuditDisabled->0 EnableFilter->1 AuditFiltered->1 MicrosoftEdgeC
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 MicrosoftEdgeC
Disabled->0 AuditDisabled->0 EnableFilter->1 AuditFiltered->1 MicrosoftEdgeC
Disabled->0 AuditDisabled->0 EnableFilter->0 AuditFiltered->0 MicrosoftEdgeC
Disabled->0 AuditDisabled->0 EnableFilter->1 AuditFiltered->1 MicrosoftEdgeC
Disabled->0 AuditDisabled->0 EnableFilter->1 AuditFiltered->1 MicrosoftEdgeC
赤色のデータは次のようなことを示しています。
- Google Chromeは、Win32k入力機能を一部プロセスで無効とする方針を採用している
- Microsoft Edgeは、Win32k入力機能を一部プロセスでフィルタリングする方針を採用している
ご覧のように、2つのブラウザの設計思想は一目瞭然です。「このブログ」を読んでみると、Google社とMicrosoft社の2つのブラウザチームはお互いの開発姿勢を強く意識しながら作業していることが分かります。Win32k入力機能の無効化は、CFG、DEP、フォントロード抑制制御、ダイナミックコード展開制御などともにセキュリティー保護オプションを構成し、Windows 10カーネル層におけるオプション構成と実装はビルド単位で異なっています。つまり、一口にWindows 10といいましても、出荷されるカーネルはビルド単位で（時には、劇的に）異なります。2018年1月に表面化した「Meltdown and Spectre」問題への更新パッチを当てると、Systemプロセスの「MitigationFlags->0x00000060」は次のように変化します。
MitigationFlags->0x40000060 System
MitigationFlags->0x00000121 smss.exe
MitigationFlags->0x00000121 csrss.exe
MitigationFlags->0x00000021 wininit.exe
MitigationFlags->0x00000121 csrss.exe
MitigationFlags->0x000001a1 services.exe
MitigationFlags->0x00000021 lsass.exe
MitigationFlags->0x00000021 WUDFHost.exe
MitigationFlags->0x01000821 svchost.exe
MitigationFlags->0x00004039 fontdrvhost.ex
MitigationFlags->0x01000821 svchost.exe
[---]
Systemプロセスのフラグは、「MitigationFlags->0x00000060」から「MitigationFlags->0x40000060」へ変更されています。ビット分解してみると、この変更は、間接分岐予測を抑制する対策がSystemプロセスレベルでとられたことを示しています。また、スレッドオブジェクトの「dispatcher_header」には次のようなフィールドが追加され、プロセスレベルに加え、スレッドレベルでもセキュリティーを向上させようとしています。
+0x001 ThreadSpecControl : UChar
+0x001 SpecControlIbrs : Pos 0, 1 Bit
+0x001 SpecControlStibp : Pos 1, 1 Bit
+0x001 SpecControlReserved : Pos 2, 6 Bits
これらのビット値を独自の解析コードで調査してみると、次のようになっています。
[---]
+Dispatcher->0xffff9b8c75a30080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c75a30080
0xffff9b8c75029580 RuntimeBroker.
+Dispatcher->0xffff9b8c7436e700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c7436e700
+Dispatcher->0xffff9b8c71770700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c71770700
+Dispatcher->0xffff9b8c718af700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c718af700
+Dispatcher->0xffff9b8c74c7f080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74c7f080
+Dispatcher->0xffff9b8c74c4d700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74c4d700
+Dispatcher->0xffff9b8c74151080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74151080
+Dispatcher->0xffff9b8c74d12300 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74d12300
+Dispatcher->0xffff9b8c71fad700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c71fad700
+Dispatcher->0xffff9b8c757f6080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c757f6080
+Dispatcher->0xffff9b8c723bd340 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c723bd340
+Dispatcher->0xffff9b8c74100700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74100700
0xffff9b8c74661580 svchost.exe
+Dispatcher->0xffff9b8c725954c0 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c725954c0
+Dispatcher->0xffff9b8c7530a300 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c7530a300
0xffff9b8c7527a580 svchost.exe
+Dispatcher->0xffff9b8c73165700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c73165700
+Dispatcher->0xffff9b8c711cc080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c711cc080
+Dispatcher->0xffff9b8c7586b700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c7586b700
+Dispatcher->0xffff9b8c7436c080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c7436c080
+Dispatcher->0xffff9b8c7515e240 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c7515e240
0xffff9b8c73ea9580 dllhost.exe
+Dispatcher->0xffff9b8c72427080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c72427080
+Dispatcher->0xffff9b8c70d90700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c70d90700
+Dispatcher->0xffff9b8c74f55700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74f55700
+Dispatcher->0xffff9b8c70dda080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c70dda080
+Dispatcher->0xffff9b8c74072700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74072700
+Dispatcher->0xffff9b8c70eec080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c70eec080
0xffff9b8c71171580 svchost.exe
+Dispatcher->0xffff9b8c757a9700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c757a9700
+Dispatcher->0xffff9b8c72078080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c72078080
+Dispatcher->0xffff9b8c74c4b080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74c4b080
+Dispatcher->0xffff9b8c718a7080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c718a7080
0xffff9b8c757e0080 SkypeHost.exe
+Dispatcher->0xffff9b8c735f5700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c735f5700
+Dispatcher->0xffff9b8c70ecb0c0 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c70ecb0c0
+Dispatcher->0xffff9b8c74a93700 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c74a93700
+Dispatcher->0xffff9b8c73226080 Type->6 ThreadSpecControl->1 Thread->0xffff9b8c73226080
[---]
この実行結果は、上の「 +0x001 SpecControlIbrs : Pos 0, 1 Bit」がセットされ、間接分岐予測がスレッド単位で制限されていることを示しています。
Windowsのカーネル内部は時代の要請を受けながら敏感に変化しています。変化の技術的な背景が説明されることはありません。本「IT談話館」のこの「Windows XP/7/8/10のプロセス間親子関係解析とサンドボックス」記事では、Windows XPからWindows 10までのプロセス間親子関係の変遷を紹介しています。セキュリティーを向上させるため、プロセス間の親子関係を変更し、サンドボックス化を強力に推し進めている様子がはっきり見て取れます。その分野に関心のある場合には、目を通されるとよろしいかもしれません。
本「IT談話館」は、高度な内部解析技術を保有し、Windowsクラッシュダンプ、中でもカーネルメモリダンプとWindows 10 Active Memory Dumpの「メモリダンプ解析ビジネス」を展開しています。新しく導入されたAPI関数とカーネルとの本質的な関係やシステムへの影響の評価なども解析工程の一部として行っています。