Cloud ComputingにおけるVMのセキュリティ(14/Jan/2010)

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 は便利だがセキュリティホールになる

仮想化はセキュリティを強化する根拠(?)
• 仮想マシンモニタ（ハイパーバイザー）はOS、アプリケーションより
OSより小さく作ることができ強固である(?)
– カーネルより強固にできるのか
• ドライバ以外はカーネルソースは論理的検証が可能。SEL4 [SOSP09]は8,700
行のカーネルCコードをTheorem Prober (Isabelle/HOL)で検証。
• つまり、ドライバを除く論理的なプログラムは検証可能
– 多くの問題はドライバから起こっているが、仮想化の役目は計算機資源を
仮想化すること。しかし完全に仮想化できない。
• Compatibility is Not Transparency [HotOS’07, Tal Garfinkel]
– 仮想化はデバイスドライバを二重に作っているようなもの
• 物理デバイスが共有されるためサイドチャネル攻撃の危険もある

ManagementOS Guest OS Guest OS
Secure?
Secure? Device Driver Device Driver Device Driver
Secure?
VM (Virtual Device)
Hypervisor

CPU (Rea Device)

仮想化はセキュリティを強化する根拠(!)
• 攻撃対象である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

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 での報告あり。 Guest OS

– 対策は不要なデバイスを付けない
smash!
ManagementOS

Device Driver Device Driver

VM (Virtual Device)
Hypervisor

CPU (Rea Device)

Cross VM 攻撃(キャッシュ共有)
• “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

Set Associative
Cache

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排他制御 (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の対応
脆弱性対応排他制御暗号化・ VM
(コード検証) 完全性検証 Introspection
VMware

Xen

Hyper-V

KVM

Oracle VM

Virtual Box

Cloud ComputingにおけるVMのセキュリティ(14/Jan/2010)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cloud ComputingにおけるVMのセキュリティ(14/Jan/2010)

Similar to Cloud ComputingにおけるVMのセキュリティ(14/Jan/2010) (20)

More from Kuniyasu Suzaki

More from Kuniyasu Suzaki (20)

Recently uploaded

Recently uploaded (14)

Cloud ComputingにおけるVMのセキュリティ(14/Jan/2010)