Windows内部解析サービス
豊田孝の「IT談話館」 Windowsメモリダンプ解析を依頼する WinDbgとシステム分析



　本「IT談話館」一般公開記事は、10年以上の実務経験を持つ上級Windowsエンジニアを想定しています。
　本館は、Windowsカーネル深層を解析し、クラッシュ原因をはじめとするシステム内の「異様な動き」を検出・分析する
超高度な技術と実績を保有しています。


WinDbgとWindowsセキュリティー解析


　本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草されています。公開内容はあくまでも本館ビジネスに支障の出ない範囲に制限されていますが、Windowsビジネスを展開する上で必要となる、新規「商材」の発掘や同業他社との「差異」を確保し、人材と予算をはじめとする所有資源を適切に配置・投資する一助にはなるかもしれません。本「IT談話館」主筆の「豊田孝」はDKOM(Direct Kernel Object Manipulation)ベースの解析手法の第一人者であり、Windowsカーネル空間の解析分野では世界の先頭を走っています。

　現在、セキュリティー問題を無視することはできません。Microsoft社側の負担だけではなく、同社製品の利用者側の負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点から「Windows10ソフトウェアセンサー」を見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
  1. Silo/Server Silo
  2. Job
  3. Session
  4. Protected Process
  5. Mandatory Integrity Control(MIC)
  6. Windows API(+CPU)
  7. 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
　赤色のデータは次のようなことを示しています。 　ご覧のように、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関数とカーネルとの本質的な関係やシステムへの影響の評価なども解析工程の一部として行っています。


「Windowsメモリダンプ解析サービス」のご案内
Windowsメモリダンプ解析技術

Copyright©豊田孝 2004- 2024
本日は2024-04-18です。