本「
IT談話館」一般公開記事は、10年以上の実務経験を持つ上級Windowsエンジニアを想定しています。
本館は、Windowsカーネル深層を解析し、クラッシュ原因をはじめとするシステム内の「異様な動き」を検出・分析する
超高度な技術と実績を保有しています。
Windows 7/8/10、セキュリティー、Token、SD
本「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
本稿では保護メカニズム階層内の比較的下位に位置する上記赤色のMICを取り上げます。米Microsoft社はこの「Mandatory Integrity Control(MIC)」ページからMIC情報を公開しています。概念的には、このメカニズムは次のような既存の概念を拡張・統合する方向で実装されています。
- プロセスオブジェクト
- セッション
- トークンオブジェクト
- セキュリティーディスクリプター(SD)
本館のこの別稿「Windows XP/7/8/10のセッションとプロセス」では、次のような条件に従って、システム内で動作中の各種Windowsプロセスを分類できることを紹介しています。
- システムプロセスはセッション0内で動作し、SCMの子プロセスではない
- サービスプロセスはセッション0内で動作し、SCMの子プロセスである
- ユーザープロセスはセッション0以外のセッション内で動作し、SCMの子プロセスでもない
まずは、このプロセス分類条件を組み入れた解析ードを実行し、次のような情報を取得してみることにします。
- プロセスオブジェクトのアドレスと名称を取得する
- プロセスオブジェクトが所属するセッションIDを取得する
- プロセスオブジェクトのトークンアドレスを取得する
- 取得したトークンのMandatory Policyを取得する
- プロセスオブジェクトのセキュリティーディスクリプター(SD)アドレスを取得する
実行結果を見てみましょう。
1: kd> vertarget
Windows 10 Kernel Version 10240 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 10240.16463.amd64fre.th1.150819-1946
Machine Name:
Kernel base = 0xfffff800`6d404000 PsLoadedModuleList = 0xfffff800`6d729030
Debug session time: Thu Oct 1 08:57:05.915 2015 (UTC + 9:00)
System Uptime: 4 days 21:18:39.610
SessionId->0 System->0xFFFFE0001F2A8840
MandatoryPolicy->1
Token->0xFFFFC001EEC16A60
SecurityDescriptor->0xFFFFC001EEC16510
SessionId->0 smss.exe->0xFFFFE0002090F040
MandatoryPolicy->1
Token->0xFFFFC001EFDA5590
SecurityDescriptor->0xFFFFC001EEC16510
SessionId->0 csrss.exe->0xFFFFE00020E19840
MandatoryPolicy->1
Token->0xFFFFC001F11C9060
SecurityDescriptor->0xFFFFC001F11C9ED0
SessionId->0 wininit.exe->0xFFFFE00020EB9080
MandatoryPolicy->1
Token->0xFFFFC001F1D5B060
SecurityDescriptor->0xFFFFC001EEC16510
SessionId->0 services.exe->0xFFFFE00020ED9700
MandatoryPolicy->1
Token->0xFFFFC001F1DE0A10
SecurityDescriptor->0xFFFFC001EEC16510
SessionId->0 lsass.exe->0xFFFFE00020F8C6C0
MandatoryPolicy->1
Token->0xFFFFC001F1D36060
SecurityDescriptor->0xFFFFC001F1DE27C0
SessionId->0 svchost.exe->0xFFFFE00020E49840
MandatoryPolicy->3
Token->0xFFFFC001F0F318F0
SecurityDescriptor->0xFFFFC001F0F2A640
[---]
SessionId->1 chrome.exe->0xFFFFE000238545C0
MandatoryPolicy->3
Token->0xFFFFC001F5EDA960
SecurityDescriptor->0xFFFFC001F7033C40
SessionId->1 chrome.exe->0xFFFFE0001FDED840
MandatoryPolicy->3
Token->0xFFFFC001F8B3A550
SecurityDescriptor->0xFFFFC00200851720
SessionId->1 chrome.exe->0xFFFFE000200CE200
MandatoryPolicy->3
Token->0xFFFFC001F8A69940
SecurityDescriptor->0xFFFFC00200851720
SessionId->1 chrome.exe->0xFFFFE0002002D840
MandatoryPolicy->3
Token->0xFFFFC001F7C69060
SecurityDescriptor->0xFFFFC00200851720
[---]
実行結果を見ると、「SessionId->0」と「SessionId->1」という異なるセッションに所属するプロセスが存在します。先ほど紹介したプロセス分類条件に従えば、「SessionId->0」に所属するプロセスは、システムプロセスかサービスプロセスとなり、「SessionId->1」に所属するプロセスはユーザープロセスと解釈できます。セキュリティーの観点からは、「SessionId->0」所属プロセスは他のセッション所属のプロセスより多くのアクセス権限と保護制限を与えられているはずです。これは常識中の常識ですが、まずは、この常識を疑ってかかり、「SessionId->0」所属プロセスが与えられているこれらの特性を調査してみます。次の実行結果をご覧ください。
SessionId->0 System->0xFFFFE0001F2A8840
MandatoryPolicy->1
Token->0xFFFFC001EEC16A60
SecurityDescriptor->0xFFFFC001EEC16510
SessionId->0 smss.exe->0xFFFFE0002090F040
MandatoryPolicy->1
Token->0xFFFFC001EFDA5590
SecurityDescriptor->0xFFFFC001EEC16510
[---]
SessionId->0 svchost.exe->0xFFFFE00021B7E840
MandatoryPolicy->3
Token->0xFFFFC001F1368060
SecurityDescriptor->0xFFFFC001F1368F70
SessionId->0 WUDFHost.exe->0xFFFFE00021C84840
MandatoryPolicy->3
Token->0xFFFFC001F140F8D0
SecurityDescriptor->0xFFFFC001F13BAB10
[---]
システムプロセスとサービスプロセスはセッション0に所属しますから、それぞれのトークンとSDを調査すれば、与えられているアクセス権限と保護制限を知ることができます。ここでは、赤色の2つのプロセスを調査してみます。
Systemプロセスのトークン
1: kd> !token -n 0xFFFFC001EEC16A60
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001eec16a60
TS Session ID: 0
User: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
User Groups:
00 S-1-5-32-544 (Alias: BUILTIN\Administrators)
Attributes - Default Enabled Owner
01 S-1-1-0 (Well Known Group: localhost\Everyone)
Attributes - Mandatory Default Enabled
02 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
Attributes - Mandatory Default Enabled
03 S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
Attributes - GroupIntegrity GroupIntegrityEnabled
Primary Group: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
[---]
この結果は、Systemプロセスが「システムプロセス」であり、後ほど触れる「System Mandatory Level」を示すSIDを持っていることを示しています。この「システムプロセス」のSD内容は次のようになっています。
SystemプロセスのSD
1: kd> !sd 0xFFFFC001EEC16510 1
[---]
->Sacl : ->Ace[0]: ->Mask : 0x00000003
->Sacl : ->Ace[0]: ->SID: S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
ご覧のように、トークンと同じ「System Mandatory Level」を示すSIDを持っています。「Mask」に関しては、Mandatory Policyとともに後ほど説明します。次に、「WUDFHost.exe」プロセスのトークン内容を見てみます。
WUDFHost.exeプロセスのトークン
1: kd> !token -n 0xFFFFC001F140F8D0
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f140f8d0
TS Session ID: 0
User: S-1-5-19 (Well Known Group: NT AUTHORITY\LOCAL SERVICE)
User Groups:
00 S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
Attributes - GroupIntegrity GroupIntegrityEnabled
01 S-1-1-0 (Well Known Group: localhost\Everyone)
Attributes - Mandatory Default Enabled
02 S-1-5-32-545 (Alias: BUILTIN\Users)
Attributes - Mandatory Default Enabled
03 S-1-5-6 (Well Known Group: NT AUTHORITY\SERVICE)
Attributes - Mandatory Default Enabled
04 S-1-2-1 (Well Known Group: localhost\CONSOLE LOGON)
Attributes - Mandatory Default Enabled
05 S-1-5-11 (Well Known Group: NT AUTHORITY\Authenticated Users)
Attributes - Mandatory Default Enabled
06 S-1-5-15 (Well Known Group: NT AUTHORITY\This Organization)
Attributes - Mandatory Default Enabled
07 S-1-5-84-0-75023-0-0-0 (no name mapped)
Attributes - Mandatory Default Enabled Owner LogonId
08 S-1-5-84-0-0-0-0-0 (Well Known Group: NT AUTHORITY\USER MODE DRIVERS)
Attributes - Mandatory Default Enabled
Primary Group: S-1-5-19 (Well Known Group: NT AUTHORITY\LOCAL SERVICE)
[---]
この実行結果は、「WUDFHost.exe」プロセスが「サービスプロセス」であり、「System Mandatory Level」を示すSIDを持っていることを示しています。また、「システムプロセス」と「サービスプロセス」は、それぞれが所属するグループの数に大きな違いがあることも示しています。この「WUDFHost.exe」プロセスのSDは次のようになっています。
WUDFHost.exeプロセスのSD
1: kd> !sd 0xFFFFC001F13BAB10 1
[---]
->Sacl : ->Ace[0]: ->Mask : 0x00000003
->Sacl : ->Ace[0]: ->SID: S-1-16-16384 (Label: Mandatory Label\System Mandatory Level)
この情報は、「システムプロセス」と「サービスプロセス」の区別がSDレベルではかなり難しいことを示しています。それでは今度は、セッション0以外のセッションに所属するユーザープロセスのトークンを見てみましょう。
[---]
SessionId->1 chrome.exe->0xFFFFE000238545C0
MandatoryPolicy->3
Token->0xFFFFC001F5EDA960
SecurityDescriptor->0xFFFFC001F7033C40
SessionId->1 chrome.exe->0xFFFFE0001FDED840
MandatoryPolicy->3
Token->0xFFFFC001F8B3A550
SecurityDescriptor->0xFFFFC00200851720
SessionId->1 chrome.exe->0xFFFFE000200CE200
MandatoryPolicy->3
Token->0xFFFFC001F8A69940
SecurityDescriptor->0xFFFFC00200851720
SessionId->1 chrome.exe->0xFFFFE0002002D840
MandatoryPolicy->3
Token->0xFFFFC001F7C69060
SecurityDescriptor->0xFFFFC00200851720
[---]
赤色の2つの「chrome.exe」ユーザープロセスは、次のようなトークンを持っています。
chrome.exe->0xFFFFE000238545C0のトークン
1: kd> !token -n 0xFFFFC001F5EDA960
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f5eda960
TS Session ID: 0x1
[---]
15 S-1-16-8192 (Label: Mandatory Label\Medium Mandatory Level)
Attributes - GroupIntegrity GroupIntegrityEnabled
この「chrome.exe」プロセスは、「System」ではなく、それより一段低い「Medium」を示すSIDを持っています。もう一つの「chrome.exe」ユーザープロセスのトークンは次のようになっています。
chrome.exe->0xFFFFE0001FDED840のトークン
1: kd> !token -n 0xFFFFC001F8B3A550
*** Friendly name lookup may not work correctly with dumpfiles.
_TOKEN ffffc001f8b3a550
TS Session ID: 0x1
[---]
15 S-1-16-4096 (Label: Mandatory Label\Low Mandatory Level)
Attributes - GroupIntegrity GroupIntegrityEnabled
この「chrome.exe」プロセスは、「Medium」よりさらに低い「Low」を示すSIDを持っています。同じ「chrome.exe」プロセスであっても、前者と比較しますと、レベルの一段低いSIDです。これは、親プロセスは自分よりレベルの高い実行権限を持つ子プロセスを作成できない、というセキュリティー原則が作用していることを証明しています。
これまでの解析過程で登場した「 S-1-16-4096 (Label: Mandatory Label\Low Mandatory Level)」などのSIDは「Integrity Level」を決定する機能を持ち、次のように定義されています。
- 0x0000(0000) Untrusted level SECURITY_MANDATORY_UNTRUSTED_RID
- 0x1000(4096) Low integrity level SECURITY_MANDATORY_LOW_RID 子プロセスや新規作成オブジェクト
- 0x2000(8192) Medium integrity level SECURITY_MANDATORY_MEDIUM_RID 通常アプリケーション
- 0x3000(12288) High integrity level SECURITY_MANDATORY_HIGH_RID 特権ユーザー
- 0x4000(16384) System integrity level SECURITY_MANDATORY_SYSTEM_RID システム/サービスプロセス
これらのSIDは、末尾(RID)の値が大きければ大きいほどより多くのアクセス権限と保護制限を持つことを示し、トークンとSDの両方に設定されます。
これまでご紹介した実行結果には、「Mandatory Policy」という用語が登場していましたが、トークン側には次のような値が設定されます。
- 0x0: TOKEN_MANDATORY_POLICY_OFF
- 0x1: TOKEN_MANDATORY_POLICY_NO_WRITE_UP
- 0x2: TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN
- 0x3: TOKEN_MANDATORY_POLICY_VALID_MASK
一方、SD側には、たとえば、「->Sacl : ->Ace[0]: ->Mask : 0x00000003」などと設定され、この「Mask」値は下位オブジェクトからの読み書きアクセスを制限することを示します。
- 0x1: SYSTEM_MANDATORY_LABEL_NO_WRITE_UP
- 0x2: SYSTEM_MANDATORY_LABEL_NO_READ_UP
- 0x4: SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP
Windowsセキュリティーメカニズムの全体像を把握するのは簡単ではありません。新しいセキュリティー保護概念も追加・実装されています。本館は定期的に解析コードを開発し、返される実行結果をその都度吟味しているのが現実です。