kkent030315/pagetableinjectionコードインジェクション、pagetables pml4 を介して悪意のあるペイロードを注入する。
コードインジェクション、ページテーブルのPML4を介して悪意のあるペイロードを注入する手法。
これは、ページテーブルインジェクション技術（page table injection technique）を利用して任意のユーザープロセスに悪意のあるコードを注入する概念実証です。
Windows（および一部の最新OS）では、各プロセスには独自のPML4、すなわち*ディレクトリテーブルベース（Directory Table Base）*が存在します。したがって、プロセスAはAPIを使用しなければプロセスBにアクセスできません。しかし、任意のPML4エントリを注入できるとしたらどうでしょうか？もちろん、PML4エントリは、バッキングプロセスとまったく同じように、対応するエントリ（PDP、PD、PT）の物理アドレスを指すことになります。
悪意のあるPML4エントリをターゲットプロセスに注入するには、その悪意のあるPML4エントリを支える実際の常駐ページ（物理メモリ）が必要です。つまり、文字通り常駐ページでなければなりません。そうでなければ、MMUが物理アドレスに変換する際にMMUが期待するものが存在せず、Windowsメモリマネージャも期待するものが存在しないため、システムがクラッシュしたり不安定になったりする可能性があります。
バッキングプロセスとターゲットプロセスの両方のバッファを見てみましょう。ここでは、以下のバッファがあります。
0x1A45F8100000x6EA45F810000次のステップに進む前に、2番目のアドレス（0x6EA45F810000）が奇妙に見えると感じる方もいるかもしれません。通常、mallocやVirtualAllocでバッファを割り当てると、仮想アドレスは0x17C7CAC0000、0x23BE9D80000、0x19FE76F0000などのようになるはずだからです。これは、悪意のあるPML4エントリがWindowsのメモリマネージャに関与しておらず、管理もされていないためです。もちろん、Windows 64ビットプロセスのすべての仮想アドレスは、ユーザーメモリ範囲内の任意の値を取り得ます。
それでは、両方のアドレスを調べてみましょう。
0: kd> .process ffff9803d8037080
Implicit process is now ffff9803`d8037080
0: kd> db 0x6EA45F810000 l2
00006ea4`5f810000 4d 5a MZ
0: kd> !vtop 7968b000 0x6EA45F810000
Amd64VtoP: Virt 00006ea45f810000, pagedir 000000007968b000
Amd64VtoP: PML4E 000000007968b6e8
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 6ea45f810000 translates to physical address 14306000.
0: kd> .process ffff9803d9f6b080
Implicit process is now ffff9803`d9f6b080
0: kd> db 0x1A45F810000 l2
000001a4`5f810000 4d 5a MZ
0: kd> !vtop 564f6000 0x1A45F810000
Amd64VtoP: Virt 000001a45f810000, pagedir 00000000564f6000
Amd64VtoP: PML4E 00000000564f6018
Amd64VtoP: PDPE 000000005849b488
Amd64VtoP: PDE 0000000059e9c7e0
Amd64VtoP: PTE 000000003251d080
Amd64VtoP: Mapped phys 0000000014306000
Virtual address 1a45f810000 translates to physical address 14306000.
両方のアドレスは、まったく同じページテーブルエントリ（PDP、PD、PT）と物理アドレスに対応しています。したがって、バッキングプロセスのバッファを変更すると、その変更はターゲットプロセスにも反映されます。これはWindowsの共有メモリに非常に似ていますが、異なる点は、ターゲットプロセス上のメモリ領域がそのプロセスのVADエントリに決して表示されないことです。しかしその一方で、バッキングプロセスのバッファが解放されると、ターゲットプロセス側でも解放されますが、ターゲットプロセスのページテーブルエントリがクリーンアップされないため、メモリマネージャがバグチェック MEMORY_MANAGEMENT を引き起こしたり、さらに悪いことにCPU上でトリプルフォールトを発生させる可能性があります。
この技術には、前述したように注入された悪意のあるPML4エントリがWindowsのメモリマネージャやカーネルに関与しないという大きな安定性の問題があります。また、バッキングプロセスがターゲットプロセスが終了するまで生存している保証はなく、ターゲットプロセスがバッキングプロセスの終了時に悪意のあるPML4エントリをクリーンアップする仕組みもありません。
MIT copyright Kento Oki <[email protected]>
ソースコードには外部のコンテンツが含まれている場合があり、それらのコンテンツはその著作権者に帰属します。