paint-brush
AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: Firecracker の封じ込めシステムの分析@autoencoder
463 測定値
463 測定値

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: Firecracker の封じ込めシステムの分析

長すぎる; 読むには

この研究論文では、Firecracker がマイクロアーキテクチャ攻撃に対してどれほど安全であるかを調査します。
featured image - AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: Firecracker の封じ込めシステムの分析
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

著者:

(1)ゼイン・ワイスマン、ウースター工科大学、マサチューセッツ州ウースター、米国{[email protected]}

(2)トーマス・アイゼンバルト、リューベック大学、リューベック、SH、ドイツ {[email protected]}

(3)Thore Tiemann、リューベック大学、リューベック、SH、ドイツ {[email protected]}

(4) Berk Sunar、ウースター工科大学、マサチューセッツ州ウースター、米国 {[email protected]}。

リンク一覧

4. 爆竹の封じ込めシステムの分析

図2は、AWSが提示したFirecrackerが提供する封じ込めを示しています。このセクションでは、図に示された各コンポーネントと、マイクロアーキテクチャ攻撃に対する防御と脆弱性を分析します。


図 3: ユーザー間脅威モデルでは、悪意のあるクラウド サービス テナントが別のテナントから情報を盗み出そうとすると想定しています。ゲスト カーネルは CSP によって提供され、攻撃者は VM のアプリとランタイムを制御できると想定しています。


図 4: ユーザーからホストへの脅威モデルでは、悪意のあるテナントは、仮想マシン マネージャーやホスト カーネルなどのホスト システムから情報を漏洩させることを目的とします。攻撃者は仮想マシン内のランタイムとアプリを制御しますが、ゲスト カーネルは CSP によって提供されます。


KVM。Linuxカーネルベースの仮想マシン (KVM) は、最新の Linux カーネルに実装されているハイパーバイザーであり、したがって Linux コード ベースの一部です。基盤となるハードウェアのスーパーバイザー モードとユーザー モードを仮想化し、VM 間のコンテキスト スイッチを管理し、I/O 操作に関連しない限り、ほとんどの VM 終了理由を処理します。これらのアーキテクチャ分離メカニズムに加えて、KVM は VM 終了時の Spectre 攻撃に対する緩和策も実装し、ホスト OS またはハイパーバイザーを悪意のあるゲストから保護します。Firecracker はハイパーバイザーとして KVM に大きく依存しています。ただし、KVM は Linux ソース コードの一部であり、Linux コミュニティによって開発されているため、KVM は Firecracker の一部ではないと定義しています。したがって、KVM に実装されているマイクロアーキテクチャ攻撃に対する対策は、Firecracker の封じ込めシステムに起因するものではありません。


メタデータ、デバイス、および I/O サービス。メタデータ、デバイス、および I/O サービスは、VM と直接対話し、メトリックを収集および管理し、接続を提供する Firecracker VMM および API の一部です。AWS は、これらのインターフェイスのシンプルさ (攻撃対象領域の縮小) と、Firecracker 用にセキュリティ機能で知られるプログラミング言語 Rust でゼロから記述されていることを売りにしています [9]。ただし、Rust は、無効なメモリ アクセスや境界外のメモリ アクセスに対するプロセス内保護を最もよく提供しますが、キャッシュ攻撃、Spectre、MDS などのマイクロアーキテクチャ攻撃は、被害者のプロセスを直接ハイジャックするのではなく、プロセス間で情報を漏らす可能性があります。


Firecracker と他の多くの VMM とのもう 1 つの顕著な違いは、これらのサービスはすべて、別のスレッドではあるものの、VM 自体と同じホスト プロセス内で実行されることです。VM 内のメモリ アドレスの仮想化により、ゲストのコードと I/O サービス間の難読化がいくらか実現されますが、一部の Spectre 攻撃は単一のプロセス内でのみ機能します。ただし、同じハードウェア上で実行される 2 つのゲストはそれぞれこれらの重要なサービスのコピーを持っているため、プロセス内攻撃は実際のシステムにとってそれほど脅威にならない可能性があります。


ジェイラーバリア。APIまたは VMM が侵害された場合、ジェイラーは Firecracker インスタンスの周囲に最後の防御バリアを提供します。ジェイラーは、ホストシステムのファイルとリソースをそれぞれ名前空間とコントロールグループ (cgroup) で保護します [7]。マイクロアーキテクチャ攻撃は、定義上マイクロアーキテクチャ状態外にあるファイルを直接脅かすことはありません。cgroup を使用すると、システム管理者はプロセスをグループに割り当て、グループごとにシステムリソースの使用を割り当て、制限し、監視できます [17]。cgroup で適用される制限により、攻撃者が特定のマイクロアーキテクチャ攻撃を実行する能力が妨げられる可能性があります。たとえば、メモリ制限により、エビクションベースのキャッシュ攻撃の実行が困難になる可能性があります。また、CPU 時間制限により、攻撃者が HyperDegrade [2] などの CPU サービス拒否ツールを効果的に使用できなくなる可能性があります。HyperDegrade は、被害者のプロセスを遅くして、マイクロアーキテクチャサイドチャネルの流出または注入のタイミングを簡素化します。実際には、Firecrackerは特定のcgroupルールで配布されるわけではありません[7]。実際、FirecrackerはデフォルトのLinuxリソース割り当ての下で多くのFirecracker VMを効率的に操作できるように特別に設計されています[6]。


Firecracker の分離および封じ込めシステムはいずれも、ユーザー間またはユーザーからホストへの攻撃を直接的に防御するものではないようです。そのため、Firecracker VM の内外でさまざまなマイクロアーキテクチャ攻撃の概念実証をテストしました。


この論文は、CC BY-NC-ND 4.0 DEED ライセンスの下でarxiv で公開されています