AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: 概要と概要

リンク一覧

• 概要と序論
• 背景
• 脅威モデル
• 爆竹の封じ込めシステムの分析
• Firecracker Microvms におけるマイクロアーキテクチャ攻撃と防御の分析
• 結論、謝辞、参考文献

抽象的な

Firecracker は、Amazon Web Services (AWS) がサーバーレス クラウド プラットフォーム向けに特別に構築した仮想マシン マネージャー (VMM) です。サーバーレス クラウド プラットフォームは、エンド ユーザー向けにタスクごとにコードを実行し、サーバー インフラストラクチャを自動的に管理するサービスです。Firecracker は高速で軽量な VM を提供し、小さなタスクを分離するために通常使用されるコンテナーの速度と、パフォーマンスを犠牲にして分離を強化する傾向がある VM のセキュリティの組み合わせを保証します。AWS によると、このセキュリティと効率性の組み合わせにより、ホスト システムがアクティブ タスク間を迅速かつ頻繁に切り替える状態で、同じハードウェア上で異なるユーザーによる何千ものユーザー タスクを実行することを可能にするだけでなく、安全に実行できます。AWS は、マイクロアーキテクチャ攻撃が脅威モデルに含まれていると述べていますが、このクラスの攻撃は共有ハードウェアに直接依存しており、サーバーレス コンピューティングのスケーラビリティが前例のない数のユーザー間でのハードウェアの共有に依存しているのと同じです。

この研究では、Firecracker がマイクロアーキテクチャ攻撃に対してどの程度安全であるかを調査します。まず、Firecracker の規定された分離モデルとデプロイメントの推奨ベストプラクティスを確認し、サーバーレス プラットフォームの潜在的な脅威モデルを特定し、潜在的な弱点を分析します。次に、マイクロアーキテクチャ攻撃の概念実証を使用して Firecracker が提供する分離をテストし、Spectre または MDS 攻撃に対する保護がほとんどないことを発見しました。特に懸念される 2 つのケースが見つかりました。1) Firecracker VM を脅かすものの、その外部で実行されているプロセスは脅かさず、AWS が推奨する防御策では緩和されない Medusa バリアント、および 2) 推奨される対策が実施され、システムで SMT が無効になっている場合でも悪用可能な Spectre-PHT バリアントです。要約すると、AWS は Firecracker VMM に固有のセキュリティを過大評価しており、Firecracker を使用するクラウド システムを適切に保護するためのガイダンスが不完全であることを示しています。

CCSコンセプト

• セキュリティとプライバシー → 仮想化とセキュリティ、サイドチャネル分析と対策。

キーワード

システム セキュリティ、マイクロアーキテクチャ セキュリティ、仮想マシン、ハイパーバイザー、サーバーレス、クラウド システム

1. はじめに

サーバーレス コンピューティングは、クラウド サービス プロバイダー (CSP) が顧客にランタイム環境を提供するクラウド コンピューティングの新たなトレンドです。この方法では、顧客はハードウェア、オペレーティング システム (OS)、場合によってはランタイムに関連する管理作業を CSP に任せながら、関数コードの保守に集中できます。一般的なサーバーレス プラットフォーム モデルには、Function-as-a-service (FaaS) と Container-as-a-service (CaaS) があります。個々の関数は通常小さいですが、顧客のアプリケーションはそれぞれ 1 個から数千個の関数を実行する可能性があるため、CSP はアイドル時間を最小限に抑え、利益を最大化するために、できるだけ多くの関数を 1 台のサーバーに収めることを目指しています。ランタイム環境を提供する比較的軽量なアプローチは、コンテナーを実行することです。コンテナーは、プロセスとその依存関係をカプセル化して、各プロセスに必要なファイルのみが共有カーネルの上にある仮想ファイル システムにロードされるようにします。これにより、コンテナー間の切り替えが、プロセス間のコンテキスト切り替えとほとんど変わらない程度に軽減されます。一方、完全仮想化では、仮想マシン (VM) 間の分離が適切に行われるため、テナント間のセキュリティが確保されますが、各 VM に独自のカーネルが付属するため、かなり重量が重くなります。

コンテナも VM も、どちらのアプローチも、多くのユーザーが所有する多くの短命な関数が同時に実行され、頻繁に切り替わるサーバーレス環境での使用には理想的ではありません。そのため、このユースケース向けに新しい分離メカニズムが開発されました。たとえば、インプロセス分離のメカニズム [38、45、49] は、ランタイムと基盤となるカーネルの攻撃対象領域を減らすことで、コンテナのセキュリティを向上させることを目的としています。カーネルの保護は重要です。コンテナの場合、カーネルが侵害されると、システムが完全に侵害されることになるからです。ただし、システムコールの制限などの強力な保護は、コンテナで利用できる機能を制限し、一部のアプリケーションとの互換性を損なうことさえあります。VM の研究では、開発者はますます小型で効率的な VM を作成し、最終的にはいわゆるマイクロ VM につながりました。マイクロ VM は通常の仮想マシンと同じ分離保証を提供しますが、デバイスや OS のサポートに関しては機能が非常に限られているため、通常の VM に比べて軽量で、サーバーレス コンピューティングに適しています。

Firecracker [1] は、一般的なコンテナシステムと同等のメモリオーバーヘッドと起動時間を提供しながら、マイクロVMを実行するように設計された仮想マシンマネージャ (VMM) です。Firecracker は Amazon Web Services (AWS) によって積極的に開発されており、2018 年から AWS Lambda [5] および AWS Fargate [4] サーバーレスコンピューティングサービスの実稼働環境で使用されています [1]。AWS の設計論文 [1] では、Firecracker の機能、従来の仮想マシンとの違い、および Firecracker が提供する分離モデル (「同じハードウェア上で実行される複数の機能の安全性、権限昇格、情報漏えい、隠れたチャネル、およびその他のリスクから保護」) について説明しています [1]。さらに、AWS は、Firecracker VM が対話する CPU とカーネルの一部を保護するための実稼働ホストのセットアップ推奨事項 [8] を提供しています。この論文では、Firecracker がマイクロVM 全体の隠れたチャネルとサイドチャネルから機能を保護するという主張に異議を唱えます。 Firecracker 自体はマイクロアーキテクチャ攻撃対策には追加されず、ホストとゲストの Linux カーネルと CPU ファームウェア/マイクロコードの更新に完全に依存していることがわかります。

さまざまな Spectre [10、13、22、30、31、33、52] やマイクロアーキテクチャ データ サンプリング (MDS) [14、37、46、50] の亜種などのマイクロアーキテクチャ攻撃は、VM の分離境界を含むソフトウェアとアーキテクチャの分離境界の両方を回避できることが多いため、マルチテナント システムにとって脅威となります。Spectre と MDS は、分岐予測ユニット (BPU) やライン フィル バッファー (LFB) などの CPU コア リソースを共有するテナントを脅かします。より従来的なサービスを提供する CSP は、長期間存続する VM テナントを別の CPU コアに固定することで、共有ハードウェア リソースの問題を軽減できます。これにより、テナント間でリソースが効果的に分割され、マイクロアーキテクチャの状態が一度に 1 つのテナントによってのみ影響を受けるようになります。

ただし、サーバーレス環境では、マイクロアーキテクチャ攻撃の脅威は大きくなります。その理由は、異なるテナントによって実行される関数の存続期間が短いためです。サーバーレス環境のサーバー リソースはオーバーコミットされることが予想され、その結果、同じハードウェア上の計算リソースをめぐってテナント関数が競合することになります。同時マルチスレッド (SMT) を無効にすると、2 つの兄弟スレッドによる CPU リソースの同時使用が無効になり、CPU の計算能力が最大 30% 低下します [34]。顧客が特定の CPU コアをレンタルする場合、このパフォーマンスの低下は許容できる場合があり、CPU コアの両方のスレッドを一緒にレンタルすることもできます。ただし、サーバーレス サービスの場合、パフォーマンスの低下は、特定の時間内にサービス提供できる顧客が 30% 減少することを意味します。このため、ほとんどのサーバーレス CSP は、特に明記しない限り、システムで SMT を有効にしておく必要があります。マイクロアーキテクチャ攻撃対象領域は、SMT が有効で、悪意のあるスレッドが共有コアに同時アクセスする場合に最大になります。しかし、攻撃者のスレッドが、CPU コアを被害者のスレッドに渡す前にマイクロアーキテクチャを準備したり、被害者のスレッドが実行を一時停止した直後に実行したりすると、同様に機能する攻撃のバリエーションもあります。また、CSP によって SMT が無効にされている場合でも (AWS Lambda の場合など)、テナントは依然としてこのタイムスライス方式で複数のテナントと CPU を共有します。

AWS は、最新のマイクロアーキテクチャ防御を備えたシステムで Firecracker を実行すると、マイクロアーキテクチャ攻撃に対して十分な強化が実現されると主張しています [1]。Firecracker のドキュメントには、有効にする必要があるマイクロアーキテクチャ セキュリティ対策に関する具体的な推奨事項も含まれています。この研究では、Firecracker のセキュリティに関する主張と推奨事項を調査し、そのガイダンスの見落としと完全に軽減されていない脅威を明らかにします。

要約すると、私たちの主な貢献は次のとおりです。

• Firecracker VM をベースにしたサーバーレス コンピューティングのクロステナントおよびテナント ハイパーバイザー分離の包括的なセキュリティ分析を提供します。

• マイクロコードの更新と Linux カーネルを通じて利用可能な保護を採用し、マイクロアーキテクチャ攻撃の概念実証 (PoC) に対する Firecracker の防御機能をテストします。仮想マシン自体は、主要なマイクロアーキテクチャ攻撃に対してほとんど保護を提供しないことがわかります。

• ホスト上に存在しないにもかかわらず、Firecracker VM 内から悪用可能になる Medusa MDS 攻撃の亜種を特定しました。このエクスプロイトやほとんどの既知の Medusa 亜種から保護するカーネル緩和策は、AWS の Firecracker ホスト設定の推奨事項では言及されていません。さらに、SMT を無効にしても、特定された Medusa 亜種に対して十分な保護が提供されないことが示されており、カーネル緩和策の必要性が強調されています。

• 推奨される対策を講じてもデータを漏洩する Spectre-PHT および Spectre-BTB の亜種を特定しました。Spectre-PHT の亜種は、攻撃者と被害者がタイムスライス方式で CPU コアを共有している場合、SMT が無効になっていても問題が残ります。

1.1 責任ある開示

私たちは AWS セキュリティ チームに調査結果を報告し、技術的な詳細について話し合いました。AWS セキュリティ チームは、追加のセキュリティ対策により、AWS サービスは調査結果の影響を受けないと主張しています。AWS は、Firecracker は単独ではマイクロアーキテクチャ セキュリティを提供せず、マイクロコードの更新と安全なホストおよびゲスト オペレーティング システムとの組み合わせでのみマイクロアーキテクチャ セキュリティを提供することに同意し、Firecracker インストール用のホスト設定推奨事項を更新する予定です。