クラウドコンピューティングにおける仮想マシンのセキュリティ

平成22年度第2回JITA講演会：クラウドコンピューティングとセキュリティ27/Dec/2010

産業技術総合研究所

情報セキュリティ研究センター

須崎有康

Research Center for Information Security

自己紹介• 所属：独立行政法人 産業技術総合研究所

– 情報セキュリティ研究センター (秋葉原ダイビル)

• IPA 「クラウド・コンピューティング社会の基盤に関する研究会」委員 2009.3-2010.3

– 報告書ＨＰ http://www.ipa.go.jp/about/pubcomme/201003/index.html

• Cloud Security Alliance Japan Chapter (日本クラウドセキュリティアライアンス) ボードメンバー

– http://www.cloudsecurityalliance.jp/– http://www.cloudsecurityalliance.jp/

– 2010年6月7日設立、3番目のRegional Chapter

• 本日の話の素

– 日経コンピュータ 2010/March/31• 「護るが勝ち 仮想マシンに潜むセキュリティ問題」• http://bizboard.nikkeibp.co.jp/kijiken/summary/20100407/NC0753H_1735146a.html

• 情報処理学会誌 2010/12号 クラウドセキュリティ小特集• 「IaaS型クラウドにおける仮想マシンのセキュリティ」• http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?flag=6&keyword=IPSJ-MGN511213&mode=PRT

• KNOPPIX日本語版の管理もしています

– http://www.rcis.aist.go.jp/project/knoppix/

Client•Key management

login, data, application•personal authentication•Software vulnerability •Component Integrity

Verified Boot by “ChromeOS”

Software Vulnerability

User’s ResponsibilityOS1

App1

OS2

App2

OS3

App3

Mem

CPU

Mem

CPU

Mem

CPU

Virtual Machine Monitor

PeepingPrivacy &Security•privacy homomorphism

Internetman in the middle attack

Cross VM Side Channel Attack・VM Isolation

Authentication

Formal VerificationIn the future

IaaS型クラウドコンピューティングセキュリティ概観

Data Management•Lost (消去) provider’s matter •Leak (漏えい)•Erasure (削除) provider’s matter

Software Vulnerability・Hypervisor・Manage OS・System Configuration

Security Guideline • CSA (Cloud Security Alliance)• Open Cloud Manifesto

Auditing Standard • SAS70• HIPPA

Memory

CPU

Virtual Machine Monitor

Auditing•Digital Forensic•Log

Provider’s Responsibility

仮想化の進歩

仮想化： Virtualization2006年以降

Intel-VT/AMD-SVMの出現 (‘06)OpenVZ(‘05-), Xen (‘03-)KVM (‘06-,Feb’07にLinux6.20統合)

•仮想マシンにより複数サーバを１台の

Linux Windows BSD

Web CGI DB分散化：Distributed Computing2000年初頭•マシンは安価で追加が容易(‘99 Pentimum IIIで1GHz)•サーバ毎に機能分割•メモリもCPUも固定

Linux

Web

Windows

CGI

BSD

DB

メモリ メモリ メモリ

CPU CPU CPU

メモリ

CPU

メモリ

CPU

メモリ

CPU•プロビジョニングにより仮想化したメ

レガシーシステム

•仮想マシンにより複数サ を１台の物理マシンに集約

仮想マシンモニタ

Linux

Web

Windows

CGI

BSD

DB

仮想マシンモニタ

BSD

DB

仮想マシンモニタ

Linux

Web

Windows

CGI

BSD

DB

CPU CPU CPU

メモリ

CPU

• ジョ ング より仮想化したモリ、CPUに物理能力を動的に分配•仮想化した総メモリサイズが物理メモリを超えるメモリオーバーコミット機能により柔軟に管理

自動化： Autonomics System2008年以降•ライブマイグレーションにより負荷分散、障害時の移動が仮想マシン単位で可能•仮想マシンの複製も容易 移動 複製

仮想マシンモニタ

・VMI (Virtual Machine Image)によりOSのインストールをせずにコピーのみでインスタンスが増やせる

• クラウドコンピューティングと言うとコストとか、スケールアウトとか注目されますが、セキュリティは？

– IPA 「クラウド・コンピューティング社会の基盤に関

する研究会報告書」では乗り換えに対して価格やサ ビス向上より懸念されていることが示されてサービス向上より懸念されていることが示されている

– 米国のISACA（情報システムコントロール協会）のITのリスクとメリットに関する調査で、IT担当者の

半数近くが「クラウドのリスクはメリットを上回る」と回答し、クラウドに慎重な態度であることが分かった。ISACAが初めて行った年次調査で、2010年4月7日（米国時間）に発表した

仮想マシン導入のガイドライン

• NIST Guideline, “Guide to Security for Full Virtualization Technologies”, Karen Scarfone, Murugiah Souppaya, Pual Hoffman–– ガイドラインであり、技術的な問題点の指摘が少

ない。

• 仮想化の技術的問題点を中心に話します

NIST近くのレストランで2010/08撮影

アウトライン

• 仮想化はセキュリティを強化するか？– 仮想化のイメージとのギャップ

• 各種の脆弱性/攻撃– VM内(VM Internal)の脆弱性/攻撃

• VM内の脆弱性をついてクラウドを攻撃する。

– VM間(Cross VM)の脆弱性/攻撃– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。

• クラウド特有の問題、防御技術

セキュリティの基本と仮想化

• セキュリティの基本 (“Building Secure Software”, Addison-Wesley 2002)

– 原則2：Defense in Depth 多層防衛

– 原則4： Least Privilege 最小権限

– 原則6： Keep it simple 単純に

• 仮想化では• 仮想化では– 多層防衛は実現している

– Large & Complicated• 仮想化によりコードが増えている

• 複雑なハードウェアをエミュレートしている。性能を出すために(Trickyな)最適化を施している

• 権限は複雑になっている

– Variable (よい意味でも悪い意味でも)• デバイスのタイミングなどは正確に仮想化できない

– Compatibility is Not Transparency [HotOS’07, Tal Garfinkel]

• Memory Ballooning, Live Migration は便利だがセキュリティホールになる

仮想化はセキュリティを強化するのか？• 仮想マシン研究者の主張：「仮想マシンモニタ（ハイパーバイザー）はOS、アプ

リケーションよりOSより小さく作ることができ、強固である」– カーネルもドライバ以外は形式的検証が可能で強固にできている[SOSP09]

• SEL4 は8,700行のカーネルCコードをTheorem Prober(Isabelle/HOL)で検証

• つまり、ドライバを除く論理的なプログラムは検証可能

– 多くの問題はドライバから起こっているが、仮想化の役目は計算機資源を仮想化すること。しかし、タイミングなど完全に仮想化できない

• Compatibility is Not Transparency [HotOS’07, Tal Garfinkel]

– 仮想化はデバイスドライバを二重に作 ているようなもの– 仮想化はデバイスドライバを二重に作っているようなもの• 物理デバイスが共有されるためサイドチャネル攻撃の危険もある

仮想マシンモニタ

ハードウェア (Real Device)

VM (Virtual Device)

ManagementOS Guest OS

Device DriverDevice Driver安全?

Guest OS

Device Driver

App1 App2 App3安全?

安全?

仮想マシンモニタにより多層防衛を強化？VM (Virtual Device)VM (Virtual Device)

仮想マシンモニタの問題点• 脆弱性(bug)はコード量に比例する

– “An Empirical Study of Operating Systems Error”,SOSP’01

• デバイスドライバでは対応項目が多い– “Tolerating Hardware Device Failures in Software”, SOSP’09で示さ

れた各社のドライバ開発ガイドライン

• 更に問題なのは仮想マシンモニタを乗っ取られると被害が甚大– マルチテナントでは他のOSにまで被害が及ぶ

仮想化はセキュリティを強化する根拠(!)

• 攻撃対象であるOSより下位（ハード寄り）にあり、OSを防御・監視

– VM Introspection• OSが汚染されても挙動解析できる

• IEEE Security&Privacy Sep/Oct 2008 (vol. 6 no. 5)• 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]

• 仮想化を使わないクラウドのアンチテーゼが出ている– NoHype [ISCA’10](Princeton U)– “Should Everything Be Virtualized?“

• http://storageio.com/blog/?p=719

IaaSの仮想化技術のセキュリティ– VM内(VM Internal)の脆弱性/攻撃

• VM内の脆弱性をついてクラウドを攻撃する。1.仮想マシン上のOS管理2.I/O Fuzzing攻撃 [Google Report], [Symantec Report]

3.メモリエラーが引き金になる脆弱性[SIGMETICS09][SSP03]

4.ランダムにならない乱数[NDSS10]

– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。1.物理キャッシュを通した覗き見 Cross VM Side

Channel Attack [CSS09]

2.仮想メモリの覗き見 [ASPLOS08], [Vee08]

3.仮想ネットワークによるセキュリティ障害4.LiveMigration時のRootKit混入 [BlackHat DC 08]

仮想マシン上のOS管理 (VM Internal 1)

• 現在のクラウドではOSのインストール作業が無い！– ダッシュボード機能からメニューで作成

• VMI(Virtual Machine Image), AMI (Amazon Machine Image)

• （基本的に）インストール後は管理者権限譲渡やプライバーの問題があり、ユーザが管理問題 あり、 管– 長い間使われなかったVMIでは脆弱性対処がなく、攻撃対象となる

• クラウド＆仮想化ベンダーでもこの問題は認識しており、対策を提供

• VMIを直接扱うツール

– VMware Update Manager（VUM）

– Microsoft Offline Virtual Machine Servicing Tool

I/O Fuzzing攻撃 (VM Internal 2)• 仮想マシンの脆弱性を突いた攻撃

– 仮想マシンのデバイスを過剰に叩き、管理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 • CRASHME: Random input testing • I/O fuzzing

– VMware, Xen での報告あり

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

Hypervisor

CPU (Real Device)

VM (Virtual Device)

ManagementOS

Guest OS

Device DriverDevice Driver

smash!

I/O Fuzzing攻撃 (2/2)• VMWareのビデオデバイスの脆弱性 (Black Hat 2009の発表)

– CLOUDBURST A VMware Guest to Host Escape Story, Kostya Kortchinsky (Immunity, Inc.)

• SVGA_CMD_RECT_COPY バグ– フレームバッファはホストのメモリにmapされている

• これでアドレスが判明する

• SVGA_CMD_DRAW_GLYPH バグ– バウンダリチェックをしていないので SVGA_CMD_RECT_COPY から得たアドレス– バウンダリチェックをしていないので、 SVGA_CMD_RECT_COPY から得たアドレス

相対でホストのメモリが読み書きできる

Memory Leak

OverWrite memoryNormal behavior

メモリエラーが引き金になる脆弱性 (VM Internal 3)

• クラウドコンピューティングでは数万台を超える大規模なサーバ群から構成されるため、各デバイスの障害も半端でない

• ” DRAM Errors in the Wild: A Large-Scale Field Study” [SIGMETICS09]においてGoogleのサーバ群におけるメモリのエラーレートを報告

– 通常考えられている以上に物理的なメモリエラーが起こる

– クラウドコンピューティングではメモリ上の処理が多い

• メモリエラーを狙った攻撃• メモリエラ を狙った攻撃

– “Using Memory Errors to Attack a Virtual Machine”, [IEEE Symposium on Security and Privacy’03]

• 悪意のあるコードにジャンプする仕組みをメモリ内に敷き詰め(スプレー攻撃)、メモリエラーを待つ

• この論文自体はJavaVMを想定しているが、仮想マシンでも同じ

• 対処

– SELinuxのような各権限(ルート)での強制アクセス制御を施すこと• ルートを乗っ取られても被害が限定できる

– AMD のNXビットやIntel CPUのDXビットのようなデータ領域のコードを実行できない機能(DEP: Data Execution Prevention)を有効にする

ランダムにならない乱数 (VM Internal 4)• 仮想マシンモニタは仮想マシンの実行途中を保存するスナッ

プショット機能を提供

• スナップショットイメージを複数回使うと前の疑似乱数生成を繰り返すことになる

• 更に問題なのは、疑似乱数のシードは時計などの物理的要因から取られるが スナップショット再開後に外部の時計と同因から取られるが、スナップショット再開後に外部の時計と同期せずに時間が繰り返される仮想マシンがある– When Good Randomness Goes Bad [NDSS10]

• 対処– Hedged cryptography

– 暗号化レベルで仮想マシンの乱数生成の問題を意識して回避する

IaaSの仮想化技術のセキュリティ– VM内(VM Internal)の脆弱性/攻撃

• VM内の脆弱性をついてクラウドを攻撃する。1.仮想マシン上のOS管理2.I/O Fuzzing攻撃 [Google Report], [Symantec Report]

3.メモリエラーが引き金になる脆弱性[SIGMETICS09][SSP03]

4.ランダムにならない乱数[NDSS10]

– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。1.物理キャッシュを通した覗き見 Cross VM Side

Channel Attack [CSS09]

2.仮想メモリの覗き見 [ASPLOS08], [Vee08]

3.仮想ネットワークによるセキュリティ障害4.LiveMigration時のRootKit混入 [BlackHat DC 08]

物理キャッシュによるサイドチャネル攻撃(CrossVM-1)

• “Hey, You, Get Off of My Cloud”[CCS’09]• セットアソシアティブキャッシュを共有している「悪意のあるVM」が連続して

キャッシュを叩く。キャッシュの反応が遅れると他のVMでアクセスしていることが判る– 限定した環境だが鍵漏洩の恐れがある

• 2005に話題になった Hyper Threading の脆弱性と同じ– http://journal.mycom.co.jp/articles/2005/05/17/ht/index.html

• 対策はVMのIsolation、排他制御 Log of Cache delay

Set Associative Cache

Main Memory

AttackerVM

Cache Line64 byte

2 way

NormalVM

仮想マシンモニタ

Core1 Core2

仮想マシンメモリの覗き見(CrossVM-2)• 既存の物理メモリへの覗き見攻撃

– IEEE1394(FireWire)によるメモリ覗き見

– メモリを冷やして解析。Cold Boot Attack [USENIX Security08]

• 仮想マシンでは同様の攻撃がソフトウェアのみで出来る– 管理OSを乗っ取られればVM Introspection機能から可能

• 対策– VMメモリの暗号化。他のVMからのぞき見られても情報漏えいしない– VMメモリの暗号化。他のVMからのぞき見られても情報漏えいしない

– Overshadow [ASPLOS08], SP3[Vee08]

SP3[Vee08]よりSID: SP3 Domain ID

仮想ネットワークによるセキュリティ障害(CrossVM-3)

• 仮想マシンモニタでは、同一物理マシン上の仮想マシン間を高速な仮想ネットワークで繋ぐ– XenSocket[Middleware07], XWAY[Vee08], XenLoop[Cluster

Computing09]

• 全通信が仮想マシンモニタ内に閉じ込められ、表に出てこない– フィルタリング、ネットワーク型IDSなど既存のツールを利用できない

• 対策– 日本IBM「Virtual Server Security for VMware（VSS）」

• VMWareのVMSafeを利用し、各仮想マシンの通信内容をチェック

Live Migration (CrossVM-４)• OSを起動させたまま、VMの他のサーバ移動

– サービスを継続しつつ、ハードウェアを停止するために必要

• スケールアウトには必須

“Exploiting live virtual machine migration” [BlackHat DC 2008]

LiveMigration時のRootKit混入(CrossVM-４)

• VM移動中にRootkitを仕込まれてしまう– Virtual Machine Based Rootkits

• “Exploiting live virtual machine migration”, [BlackHat DC 2008]

• VMイメージの完全性を検証することでRootkit混入は防げるが、

• 完全性のみでは覗き見による鍵漏洩は防げない。暗号化による秘匿性も必要

Live Migration

OS

メモリ

CPU

メモリ

CPU

仮想マシンモニタ

OS

アプリ

メモリ

CPU

仮想マシンモニタ

VMBROS

アプリ

VMBR

AttachedBy Attacker

Live Migration

メモリ

CPU

アプリ

アウトライン

• 仮想化はセキュリティを強化するか？– 仮想化のイメージとのギャップ

• 各種の脆弱性/攻撃– VM内(VM Internal)の脆弱性/攻撃

• VM内の脆弱性をついてクラウドを攻撃する。

– VM間(Cross VM)の脆弱性/攻撃– VM間(Cross VM)の脆弱性/攻撃• VM間の脆弱性をついて他のVMを攻撃する。

• クラウド特有の問題、防御技術

VM排他制御 (Isolation)• 利害の異なるVMは同時に実行させない、他のサーバに割当て排他制御が必要

– XenはXSM(Xen Security Module)のACM(Access Control Module)では可能• [XenSummit07]

• これにより実行時デバイス共有によるCross VM Attackは防げる…

ポリシー利害関係有り

Timeslot

VM排他制御 (Isolation)• 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: Service Level Agreement)で対処(?)

• この機能を悪用される恐れもある

Cloud Computing特有の問題 1/2

• AutoScaleのためにブートが多いことが想定されるが、ブートはSensitiveな処理なため新たな危険性がある

• エラー忘却型コンピューティング(Failure Oblivious Computing)などスケールアウトするためにエラーを無視する技術 対処Computing)無視する技術への対処– 楽天技術研究所の森正弥所長のコメント

• 「エラー忘却型コンピューティングは，データの完全性や保全性を犠牲にしてでも，分散処理の大規模化や高速化を実現しようとする考え方だ。このような考え方を，世界で初めて大規模に実用化した点が，Googleと他社の最大の差だろう」

• http://itpro.nikkeibp.co.jp/article/COLUMN/20081031/318297/

Cloud Computing特有の問題 2/2• サービス終了後に預けたデータを確実に消すこと

– J-SaaS利用規約• http://www.j-saas.jp/service/download/pdf/kiyaku.pdf

• データ消去の要件： サービス解約後１か月以内にデータ及び外部保管媒体を破棄

• Key-Value Storageではありえない！• Key-Value Storageではありえない！– Key-Value Storageの代表例: Amazon S3

– 複数のサーバに分散することでロバストにするが、どこにデータがあるのか不明

– ロサンゼルス警察がGovCloudに対してGoogleに求めたセキュリティ要件「データサーバの特定」に対する回答

• 「データは北米大陸のみに保管」することを保証

– SNIAのCDMI(Cloud Data Management Interface)内では定義していないが、消去はガイドラインとして出したい。By Eric A. Hibbard 2010/6/29 at SNIA-J主催 「第１回最新技術動向講演会」

まとめ

• 仮想化は計算資源の共有、動的移動など可用性を高めるが、新たな脅威を招くものでもある– 脆弱性が増え、そこを叩く攻撃の増加

• 新たな防御技術(VM排他制御、メモリ暗号化、VMイメージ完全性検証、VM Introspection)の導入の必要がある

• 資料– 日経コンピュータ 2010/March/31

• 「護るが勝ち 仮想マシンに潜むセキュリティ問題」• http://bizboard.nikkeibp.co.jp/kijiken/summary/20100407/NC0753H_1735146a.html

• 情報処理学会誌 2010/12号 クラウドセキュリティ小特集• 「IaaS型クラウドにおける仮想マシンのセキュリティ」• http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?flag=6&keyword=IPSJ-MGN511213&mode=PRT

まとめ 各種VMの対応脆弱性対応

(コード検証)ゲストの

DEP対応

排他制御 暗号化・

完全性検証

VM Introspection

メモリ重複除外

VMware vSphere 4.0とvCenter Server 4.0

EAL4+

あり VMSafe Content-Based Page

Sharing

XenXenServer 5.6

XSM(sHype)

OverShadowSP3

XenAccess Satori, Differential XenServer 5.6

EAL2(sHype) SP3 Differential

Engine

Hyper-V EAL4 デフォルト

KVM Libvrit+SELinux

KSM(Kernel

SamePageMerging)

勝手に考えるIaaSのSLA (Service Level Agreement)

• 仮想マシンモニタはセキュリティ評価基準(ex: EAL)取得か

• ゲストOSはDEP(Data Execution Prevention)対応をインストールできるのか

• Live Migrationの有無の確認

– 転送イメージの暗号化・完全性検証の確認

– 乱数シードの初期化は確実か

• VM Isolationは確実か

– 利害が絡むVMが同時に動かないか。キャッシュの共有はないのか。重複除外で共有しているものはないのか共有しているものはないのか

• ゲストOSの振舞い監視(VM Introspection)はあるのか。どこまでか。ログはあるか

• ハードウェアおよび仮想マシンモニタのエラー処理は適切に/即時に行っているのか。タイミングを狙った攻撃を防げるのか

• データの所在

– どこにあるのか確認できるのか。国単位か

– 災害があった際にバックアップは地政学的に問題ないか

• サービス停止後のデータ消去の条件

– 消したことをどこまで検証可能にしているのか