Bitvisorをベースとした既存Windowsのドライバメモリ保護
3 likes2,019 views
![ドライバへの攻撃 Research Institute
for Secure Systems
• ドライバの中に暗号鍵がある。ドライバは長時間メモリに滞在す
るため、漏えいの危険性がある。
• メモリに長期滞在するデータの危険性は[Chow, USENIX Sec 04]より指
摘されている。
• ハイパーバイザーでOSの下位よりドライバを監視して不正アクセ
スを防御する。 ユーザ空間
• ハイパーバイザーで守るこ アプリ アプリ
とで、OSをだます攻撃にも カーネル空間
覗き見不可
対応する。
×
改ざん不可
カーネル
× ドライバ 鍵
× ドライバ
鍵の格納メモリの
ドライバメモリのwrite監視。
read/writeを不可にする。
改ざん検知。
ドライバ自体の読出しの
み許可。
ハイパーバイザー
ハードウェア](https://image.slidesharecdn.com/bitvisorsummit2012-suzaki-121204213439-phpapp01/85/Bitvisor-Windows-4-320.jpg)
![VM Introspection Research Institute
for Secure Systems
• Ether [GITech Wenke Leeグループ, CCS’08]
• XenベースのVM Introspection。オープンソース。
対象OSはWindows XP SP2
• http://ether.gtisc.gatech.edu/source.html
• GreenKiller [FFRI Junichi Murakami, BlackHat’08]
• BitvisorベースのVM Introspection。対象OSは
Windows XP SP3
• Alkanet [立命館大学 大月さん、毛利先生, CSS’11]
• Bitvisorベースのシステムコールトレース。対象OS
はWindows XP SP3](https://image.slidesharecdn.com/bitvisorsummit2012-suzaki-121204213439-phpapp01/85/Bitvisor-Windows-9-320.jpg)
![ドライバ保護の類似研究 Research Institute
for Secure Systems
• Nooks [M.Swift, SOSP’03]
• 障害時にリカバーがメイン。
• HUKO[NDSS’11]
• 信頼できないドライバの保護。ドライバ用のメモリ空間とカ
ーネル用のメモリ空間の分離。CR3の値を変える。
• Windows7の Driver Isolation
• プリンタがメイン。
• OS2
• IA32アーキテクチャの4つのリング構造でカーネルとデバイ
スドライバを分ける。](https://image.slidesharecdn.com/bitvisorsummit2012-suzaki-121204213439-phpapp01/85/Bitvisor-Windows-10-320.jpg)
![メモリの保護 Research Institute
for Secure Systems
• Stealth Breakpoints [ACSAC’05]の技術の活用
• INT 03H (0xCC)に置き換えずにBreakpointの機能を実現。
メモリ内容を変えないため、攻撃者から検出され難い。
• ハイパーバイザーが守るべきメモリを管理するページテーブ
ルを空にし、アクセスが起こるたびにページフォルトを起こす
。
• ページフォルトをハイパーバイザーが捉え、正しいアクセスか
検証。問題が無ければアクセスを許す。
• 問題点
• 保護対象は4KBページ単位。
• 保護対象外でも4KBページ内のアクセスは全て検証されてしまう。](https://image.slidesharecdn.com/bitvisorsummit2012-suzaki-121204213439-phpapp01/85/Bitvisor-Windows-17-320.jpg)
Bitvisorをベースとした既存Windowsのドライバメモリ保護
- 1. Research Institute for Secure Systems Bitvisorをベースとした 既存Windowsのドライバメモリ保護 須崎 有康、八木 豊志樹、古原 和邦、 石山 智祥、村上 純一、鵜飼 裕司 （独）産業技術総合研究所 セキュアシステム研究部門 フォティーンフォティ技術研究所
- 2. 概要 Research Institute for Secure Systems • 背景 • ドライバメモリを守る理由 • ドライバメモリ保護に必要な技術 • インストール済みのOSの外部から挿入可能なハイパ ーバイザー • VM Introspection • 関連研究 • 現状 • メモリの保護はStealth breakpointsを活用 • 改善計画 • まとめ
- 3. 背景 Research Institute for Secure Systems • クライアントおよびサーバ双方からの情報漏えいを防止するアク セス制御技術の研究開発 • 総務省による戦略的情報通信研究開発推進制度(SCOPE) H23-25 • 産総研、サイエンスパーク、（FFRI） • Windows上でアクセス制御を行うNonCopy (サイエンスパーク 社製品)を活用 • NonCopyはドライバによりファイルコピー、Screen Cut&Paste、印刷な どを行うWindows APIを抑制する。 Internet ネットワーク メール添付、 利用禁止 プリンタ FTP NonCopyアーキテクチャ 印刷禁止 コピー＆ペース アプリケーション ト デフォルトで は閲覧のみ オペレーティングシステム 禁止 NonCopy Driverwareコア・エンジン NonCopyアクセス制御 ネットワーク 制御モジュール プリンタ ファイルシステム HID LBCAS 制御モジュール 制御モジュール 制御モジュール 書き込み禁止 This is This is ライティング ネットワーク プリンタ ストレージデバイス マウス/キーボード a pen. a pencil ソフト ハードウェア
- 4. ドライバへの攻撃 Research Institute for Secure Systems • ドライバの中に暗号鍵がある。ドライバは長時間メモリに滞在す るため、漏えいの危険性がある。 • メモリに長期滞在するデータの危険性は[Chow, USENIX Sec 04]より指 摘されている。 • ハイパーバイザーでOSの下位よりドライバを監視して不正アクセ スを防御する。 ユーザ空間 • ハイパーバイザーで守るこ アプリ アプリ とで、OSをだます攻撃にも カーネル空間 覗き見不可 対応する。 × 改ざん不可 カーネル × ドライバ 鍵 × ドライバ 鍵の格納メモリの ドライバメモリのwrite監視。 read/writeを不可にする。 改ざん検知。 ドライバ自体の読出しの み許可。 ハイパーバイザー ハードウェア
- 5. ドライバメモリ保護に 必要な技術 Research Institute for Secure Systems • ハイパーバイザーに必要な技術 1. インストール済みのOSに対して外部から挿入可 能なハイパーバイザー 2. VM Introspection • 関連研究
- 6. Windowsドライバ保護に必要 な技術 １(デバイス管理問題) Research Institute for Secure Systems • 多くのハイパーバイザーは複数OSを1台のマシンで起動 するために使われている • 例：IaaSクラウド • 問題点 • ホストOSが必要 • 管理ソフトウェアの大規模化 • VMware ESXiは5.xよりホストOS無しになったが、管理サーバが必要 • 基本的にデバイスがホストOSの管理下になる • VMデバイスモデルが固定 • デバイスはVM中の仮想デバイスで共有される • プレインストールのOSとは異なる • Xen, KVM, QEMUはQEMU Deviceモデルが標準
- 7. 既存のOSへの ハイパーバイザー挿入 Research Institute for Secure Systems • 既存のOSが想定している物理デバイスをVM 環境内で提供する必要がある。 • VMデバイスモデルが同じにできればよい • 各PC毎にデバイスをモデルを用意しなければならない • VMからデバイスを直接アクセス • I/O PassThrough。ハードウェアが限定。ハイパーバイ ザーでも対応が必要 • Para-PassThrough。Bitvisorで提供される
- 8. Windowsドライバ保護に必要 な技術 2(VM Introspection) Research Institute for Secure Systems • ハイパーバイザーがドライバの動作、メモリ空間 を認識する必要がある。 • 守るべきドライバが組み込まれたことの認識 • Linux: create_module, init_module システムコールなど • Windows: NtLoadDriver システムコールなど。 • 守るべきメモリ空間の認識 • 各種の実装あり。
- 9. VM Introspection Research Institute for Secure Systems • Ether [GITech Wenke Leeグループ, CCS’08] • XenベースのVM Introspection。オープンソース。 対象OSはWindows XP SP2 • http://ether.gtisc.gatech.edu/source.html • GreenKiller [FFRI Junichi Murakami, BlackHat’08] • BitvisorベースのVM Introspection。対象OSは Windows XP SP3 • Alkanet [立命館大学 大月さん、毛利先生, CSS’11] • Bitvisorベースのシステムコールトレース。対象OS はWindows XP SP3
- 10. ドライバ保護の類似研究 Research Institute for Secure Systems • Nooks [M.Swift, SOSP’03] • 障害時にリカバーがメイン。 • HUKO[NDSS’11] • 信頼できないドライバの保護。ドライバ用のメモリ空間とカ ーネル用のメモリ空間の分離。CR3の値を変える。 • Windows7の Driver Isolation • プリンタがメイン。 • OS2 • IA32アーキテクチャの4つのリング構造でカーネルとデバイ スドライバを分ける。
- 11. ドライバメモリを保護する ハイパーバイザー Research Institute for Secure Systems • 既存OSへの挿入可能性、VM Introspectionを 考慮してGreen Killerベースで開発。 • DriverGurad と命名。 • 動作手順 • USBからハイパーバイザーを起動後、ハードディ スクOSの起動 • ハイパーバイザーのドライバ認識 • 保護するメモリ領域の認識 • 攻撃に対する防御 • Stealth Breakpoints技術
- 12. 起動手順 Research Institute for Secure Systems • ハードディスクにインストール済みのOSに対して、起 動時にDriverGuardを挿入する • Chain load技術 • 類似の技術にはLinuxのkexcシステムコールを使った kbootがある。PS3Linuxで使われていた。 BIOS (USB is the first bootable device) Go back to MBR USB(GRUB) DriverGuard (Bitvisor) (resides in memory) chain loader HardDisk(NTLDR) Windows
- 13. 現在の実装 1/2 Research Institute for Secure Systems • DriverGuardではGreenKillerによるWindows の解析を利用 • 起動時に守るべきドライバの認識 • ドライバのIDとしてはタイムスタンプをIDとする • ドライバはntkrnlpa.exeのLoadDriver関数を通る ため、この関数をフック。 • フックはint 03H (0xCC)命令例に置き換えることで例外 をDriverGuardに通知。
- 14. 現在の実装 2/2 Research Institute for Secure Systems • 守るべきメモリ空間はドライバからのハイパーコール で通知 • ドライバの改変が必要 • 現在対象のNonCopyではExAllocatePoolWithTagで 保護対象のメモリを確保していたが、他の領域で保護 対象にできる
- 15. 保護手順 Research Institute for Secure Systems ② System Call “IopLoadDriver” loads a driver Windows kernel Driver A Hooked by DriverGard (protected ) ① Boot parameter ③ Hyper Call tells a driver identification to protect tells a data region to protect DriverGuard All Code Section becomes A part of Data Section Write-protected becomes Write-protected Memory Driver A Driver A Code Data Write Protect Read/Write Protect
- 16. 攻撃モデル Research Institute for Secure Systems • 本来のドライバ以外から攻撃を検出 • カーネル内で同じメモリ空間のドライバからの攻撃
- 17. メモリの保護 Research Institute for Secure Systems • Stealth Breakpoints [ACSAC’05]の技術の活用 • INT 03H (0xCC)に置き換えずにBreakpointの機能を実現。 メモリ内容を変えないため、攻撃者から検出され難い。 • ハイパーバイザーが守るべきメモリを管理するページテーブ ルを空にし、アクセスが起こるたびにページフォルトを起こす 。 • ページフォルトをハイパーバイザーが捉え、正しいアクセスか 検証。問題が無ければアクセスを許す。 • 問題点 • 保護対象は4KBページ単位。 • 保護対象外でも4KBページ内のアクセスは全て検証されてしまう。
- 18. Stealth Breakpoints Research Institute for Secure Systems Process A (Normal) CR3 Page Table Directory 0x88001000 0x88001000 0x88002000 0x88002000 Physical Memory 0x88003000 0x88003000 … … … … … 0x41101000 0x41102000 Process B (Malicious) 0x41103000 CR3 Page Table Directory … 0x88001000 0x88001000 … 0x88002000 0x88002000 0x88003000 0x88003000 ③ Page fault which is … … trapped by DriverGuard … … ② Malicious Access ① Deleted by DriverGuard after kernel set up.
- 19. 攻撃検出後の動作 Research Institute for Secure Systems • 問題を起こしたプロセスをとらえ、無限ループに する • Low IRQL(Interrupt ReQuest Level)で無限ルー プのすることにより、他のプロセスは実行可能。但 し、現状ではCPUをかなり食うので他のプロセス は遅くなる。
- 20. 動作例１ Research Institute for Secure Systems ログ表示ツールによる Bitvisor(DriverGuard) の動作確認
- 21. 動作例2 Research Institute for Secure Systems 保護アドレスの確認 攻撃ツールのCPU 攻撃前使用量 (0%) 攻撃ツールからの保護 アドレスへの書き込み
- 22. 動作例3 Research Institute for Secure Systems 保護アドレスの確認 攻撃ツールのCPU 攻撃後使用量 (98%)Low IRQLに よる無限ループ 攻撃ツールからの保護 他のアプリも使えま アドレスへの書き込み すが、遅くなります。
- 23. 現在DriverGuardの制約事項 Research Institute for Secure Systems • OSはWindowsXP SP3のみ • BIOSの設定によりマルチプロセッサをDisabled（無効）とする • OSの設定により仮想メモリ機能を無効の状態とする • OSの設定によりPSE（Page Size Extension）を無効の状態と する • 保護領域のアドレス通知をすべて受け取るまでは保護領域は 守れない • OSであるWindowsXP SP3をアップデートした場合は動作を保 証できない
- 24. 現状の課題 Research Institute for Secure Systems • ドライバのIDとしてタイムスタンプは不適切 • 実装が容易だが、改ざんされる恐れあり。 • ドライバでHyperCallする必要がある • ドライバの改良が必要 • 警告確認がCPUの負荷の向上で判り難い • ユーザ空間にハイパーバイザーの状態をポーリン グする手法も考慮したが、これが改ざんされる(検 出漏れ)恐れがある
- 25. 改良予定 Research Institute for Secure Systems • ドライバの識別子としてドライバコードのSHA1とする • ハイバーバイザーでSHA1の計算が必要 • ドライバの守るべき領域をヒープメモリとする • ヒープメモリをハイパーバイザーが実行時に検出する必要あり • ヒープは頻繁にアクセスされないと想定 • OSと非依存の警告 • 悪意のあるアクセスを検出した場合、OSと非依存の警告 • ハイパーバイザーがビープ音を鳴らすことやビデオドライバへ の直接警告する • Bitvisor 1.3で入った機能。(電通大の大山先生のADvisor) • 現状では対象ビデオカードが限定。 Intel 945GMはちょっと古い？
- 26. まとめ Research Institute for Secure Systems • Windowsを対象としたドライバメモリの情報漏 えいを防ぐ、DriverGuardの提案 • Bitvisorベースとすることで、任意のインストール済 みOSに対して、起動時にハイパーバイザーを挿 入する • Driverを理解するためにVM Introspection機能の あるGreenKillerの活用 • Stealth Breakpointsによるアクセス検出