Cloud ComputingにおけるVMのセキュリティ
産業技術総合研究所
情報セキュリティ研究センター
須崎有康
Research Center for Information Security
アウトライン• 仮想化はセキュリティを強化するか?• 各種の攻撃
– VM内(Inter VM)の攻撃• I/O Fuzzing [Google Report], [Symantec Report]
– VM間(Cross VM)の攻撃 (Side Channel 攻撃)• 物理キャッシュの覗き見 Cross VM attack [CSS09]• 仮想メモリの覗き見 OverShadow[ASPLOS08], SP3[Vee08]• LiveMigration時のRootKit混入 [BlackHat DC 08]
• 防御技術– VM排他制御 (Isolation)– 暗号化、完全性検証– VM Introspection – Cloud Computing特有の問題
• Failure Oblivious Computing, AutoScale V.S. TOCTOU 攻撃
セキュリティの基本と仮想化
• セキュアシステムの基本– Small 小さく
– Simple 単純に
– Steady 安定している。(物理的な制限を超えた場合の処理をしている)
• 仮想化はこの基本に反している!– Large
• 仮想化によりコードが増えている
– Complicated• 複雑なハードウェアをエミュレートしている。性能を出すために(Trickyな)最適
化を施している。
– Variable (よい意味でも悪い意味でも)• デバイスのタイミングなどは正確に仮想化できない
– Compatibility is Not Transparency [HotOS’07, Tal Garfinkel]
• Memory Ballooning, Live Migration は便利だがセキュリティホールになる
Hypervisor
仮想化はセキュリティを強化する根拠(?)• 仮想マシンモニタ(ハイパーバイザー)はOS、アプリケーションより
OSより小さく作ることができ強固である(?)– カーネルより強固にできるのか
• ドライバ以外はカーネルソースは論理的検証が可能。SEL4 [SOSP09]は8,700行のカーネルCコードをTheorem Prober (Isabelle/HOL)で検証。
• つまり、ドライバを除く論理的なプログラムは検証可能
– 多くの問題はドライバから起こっているが、仮想化の役目は計算機資源を仮想化すること。しかし完全に仮想化できない。
• Compatibility is Not Transparency [HotOS’07, Tal Garfinkel]
– 仮想化はデバイスドライバを二重に作っているようなもの• 物理デバイスが共有されるためサイドチャネル攻撃の危険もある
CPU (Rea Device)
VM (Virtual Device)
ManagementOS Guest OS
Device DriverDevice DriverSecure?Secure?
Secure?
Guest OS
Device Driver
仮想化はセキュリティを強化する根拠(!)
• 攻撃対象であるOSよりハード寄りでOSを防御・
監視– VM Introspection
• OSが汚染されても挙動解析できる。
• IEEE Security&Privacy Sep/Oct 2008 (vol. 6 no. 5)– http://www.computer.org/portal/web/csdl/abs/mags/sp/2008/05/msp05toc.htm
– VMSafe, XenAccess[CCS07], AnyDoor[FrHack09]
• しかし、監視インターフェイスから情報漏洩する恐れあり。
問題が起こる仮想化資源
• PC固有で複製してはまずい資源– MACアドレス
– TPMのEK (Endorsement Key), SRK (Storage Root Key)
• 複数同時に存在してまずい資源– 上記のもの
– ソフトウェアのライセンス
– 乱数のシード [NDSS10]
• “Should Everything Be Virtualized?“– http://storageio.com/blog/?p=719
アウトライン• 仮想化はセキュリティを強化するか?• 各種の攻撃
– VM内(Inter VM)の攻撃• I/O Fuzzing [Google Report], [Symantec Report]
– VM間(Cross VM)の攻撃 (Side Channel 攻撃)• 物理キャッシュの覗き見 Cross VM attack [CSS09]• 仮想メモリの覗き見 OverShadow[ASPLOS08], SP3[Vee08]• LiveMigration時のRootKit混入 [BlackHat DC 08]
• 防御技術– VM排他制御 (Isolation)– 暗号化、完全性検証– VM Introspection – Cloud Computing特有の問題
• Failure Oblivious Computing, AutoScale V.S. TOCTOU 攻撃
Inter VM攻撃
• In VM Vulnerabilities – 仮想マシンのデバイスを過剰に叩き、管理OS乗っ取りや悪意あるコードの
挿入を行う。• Tavis Ormandy, “An Empirical Study into the Security Exposure to Hosts
of Hostile Virtual Environments”, Google Report• Peter Ferrie,“Attacks on Virtual Machine Emulators”, Symantec Report
– ツール• CRASHME: Random input testing • I/O fuzzing
– VMware, Xen での報告あり。
– 対策は不要なデバイスを付けない
Hypervisor
CPU (Rea Device)
VM (Virtual Device)
ManagementOS
Guest OS
Device DriverDevice Driver
smash!
Cross VM 攻撃(キャッシュ共有)
Set Associative Cache
• “Hey, You, Get Off of My Cloud”[CCS’09]• Set Associative Cacheを共有している「悪意のあるVM」が連続してキャッ
シュを叩く。キャッシュの反応が遅れると他のVMでアクセスしていることが判る。– 限定した環境だが鍵漏洩の恐れがある
• 2005に話題になった Hyper Threading の脆弱性と同じ。– http://journal.mycom.co.jp/articles/2005/05/17/ht/index.html
• 対策はVMのIsolation
Main Memory
Cross VM 攻撃(メモリの覗き見)• 既存の物理メモリへの覗き見攻撃
– IEEE1394(FireWire)によるメモリ覗き見
– メモリを冷やして解析。Cold Boot Attack [USENIX Security08]
• 仮想マシンでは同様の攻撃がソフトウェアのみで出来る– 管理OSを乗っ取られればVM Introspection機能から可能。
• 対策– VMメモリの暗号化。他のVMからのぞき見られても情報漏えいしない
– Overshadow [ASPLOS08], SP3[Vee08]
SP3[Vee08]よりSID: SP3 Domain ID
Live Migration• OSを起動させたまま、VMの他のサーバ移動
– サービスを継続しつつ、ハードウェアを停止するために必要。
• スケールアウトには必須
“Explointing live virtual machine migration” [BlackHat DC 2008]
Live Migrationの問題• VM移動中にRootkitを仕込まれてしまう
– Virtual Machine Based Rootkits• “Exploiting live virtual machine migration”, [BlackHat DC 2008]
• VMイメージの完全性を検証することでRootkit混入は防げるが、
• 完全性のみでは覗き見による鍵漏洩は防げない。暗号化による秘匿性も必要。
アウトライン• 仮想化はセキュリティを強化するか?• 各種の攻撃
– VM内(Inter VM)の攻撃• I/O Fuzzing [Google Report], [Symantec Report]
– VM間(Cross VM)の攻撃 (Side Channel 攻撃)• 物理キャッシュの覗き見 Cross VM attack [CSS09]• 仮想メモリの覗き見 OverShadow[ASPLOS08], SP3[Vee08]• LiveMigration時のRootKit混入 [BlackHat DC 08]
• 防御技術– VM排他制御 (Isolation)– 暗号化、完全性検証– VM Introspection– Cloud Computing特有の問題
• Failure Oblivious Computing, AutoScale V.S. TOCTOU 攻撃
VM排他制御 (Isolation)• 利害の異なるVMは同時に実行させない、他のサーバに割当て排他制御が必要
– XenはXSM(Xen Security Module)のACM(Access Control Module)では可能• [XenSummit07]
• これにより実行時デバイス共有によるCross VM Attackは防げる…
• しかし、Isolationを困難にするデバイス共有技術(重複除外: deduplication 同じコンテンツは参照でまとめる技術)が出てきている。– ストレージ
• Content Addressable Storage
– メモリ• VMware ESX: Content-Based Page Sharing• Xen: Satori[USENIX09],Differential Engine[OSDI08]• Linux kernel KSM (Kernel Samepage Merging) [LinuxSympo09]
暗号化、完全性検証
• 各種デバイスの暗号化・完全性– メモリの暗号化 (OverShadow[ASPLOS08], SP3[Vee08])– メモリの完全性 (SevVisor[ASPLOS08], NILKE[RAID08])– ファイルの改竄防止 (HyperShield[SACSIS09])
• Live Migration時のVMイメージ完全性検証
• Trusted Computing– 機器認証、正しいソフトウェアが正しい構成で使われていることの確認
• コードの改ざんが無い・計算が秘匿にできるリモート実行– Operational Authentication Code
• SETI@homeのような分散計算環境で懸賞が付いた場合、割り当てられた計算を正しく実行したことを保証する方式。
• http://www.distributed.net/source/specs/opcodeauth.html
– Secure Multi Party Computation• 他人数で分散計算を行い、個々のサーバでは計算内容が判らず、計算結果
が秘匿できる方式。
VM Introspection• VMのメモリやデバイスの状態をハイパーバイザー
から覗き見る技術。– ゲストOS自身ではRootkitにより正しく状態を把握でき
ない場合がある。• VMにIDSを含める (LiveWire[NDSS03])• 隠ぺいプロセス(hidden processを)検出(Licosid[Vee08])
– フォレンジック対策で必要?
– VMSafe, XenAccess[CCS07], AnyDoor[FrHack09]
• プライバシにはSLAで対処(?)• この機能を悪用される恐れもある
Cloud Computing特有の問題
• AutoScaleのためにブートが多いことが想定されるが、ブートはSensitiveな処理なため新たな危険性がある。
• Live MigrationではTOCTOU (time-of-check-to-time-of-use) 攻撃を考慮する必要がある
• エラー忘却型コンピューティング(Failure Oblivious Computing)などスケールアウトするためにエラーを無視する技術への対処。– 楽天技術研究所の森正弥所長のコメント
• 「エラー忘却型コンピューティングは,データの完全性や保全性を犠牲にしてでも,分散処理の大規模化や高速化を実現しようとする考え方だ。このような考え方を,世界で初めて大規模に実用化した点が,Googleと他社の最大の差だろう」
• http://itpro.nikkeibp.co.jp/article/COLUMN/20081031/318297/
まとめ
• 仮想化は計算資源の共有、動的移動など可用性を高めるが、新たな脅威を招くものでもある。– 脆弱性が増え、そこを叩く攻撃の増加
• 新たな防御技術(VM排他制御、メモリ暗号化、VMイメージ完全性検証、VM Introspection)の導入の必要がある。
• 資料– http://www.slideshare.net/suzaki
まとめ 各種VMの対応
脆弱性対応
(コード検証)排他制御
Virtual Box
Oracle VM
KVM
Hyper-V
Xen
VMware
VM Introspection
暗号化・
完全性検証