465 測定値

AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: マイクロアーキテクチャ攻撃と防御の分析

に Auto Encoder: How to Ignore the Signal Noise10m2024/06/13

長すぎる; 読むには

この研究論文では、Firecracker がマイクロアーキテクチャ攻撃に対してどれほど安全であるかを調査します。

featured image - AWS Firecracker VMM のマイクロアーキテクチャセキュリティ: マイクロアーキテクチャ攻撃と防御の分析

著者:

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

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

（３）Thore Tiemann、リューベック大学、リューベック、SH、ドイツ {[email protected]}

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

リンク一覧

5. Firecracker MicroVMS におけるマイクロアーキテクチャ攻撃と防御の分析

このセクションでは、Firecracker microVM 上のマイクロアーキテクチャサイドチャネル攻撃と投機的攻撃の PoC の分析を紹介します。これらの PoC をベアメタルと Firecracker インスタンスでテストし、さまざまなシナリオで関連するマイクロコード防御をテストします。テストは Intel Skylake 4114 CPU を搭載したサーバーで実行します。

仮想化ハードウェア拡張機能とSMTが有効になっています。CPUはマイクロコードバージョン0x2006b06[2]で動作します。ホストOSはLinux 5.10カーネルのUbuntu 20.04です。クイックスタートガイド[3]に従ってAmazonが提供するLinuxカーネル5.4のUbuntu 18.04ゲストを実行するために、2023年7月時点で最新バージョンのFirecracker v1.0.0およびv1.4.0を使用しました。

まとめると、AWS Firecrackerで提供される推奨の本番ホスト設定は、テナントを悪意のある隣人から保護する上で不十分です。そのため、Firecrackerは主張する分離保証を提供できません。これは、

（1）マイクロVM上で実行された場合にのみ悪用可能となるMedusaの亜種を特定しました。さらに、推奨される対策には、サイドチャネルや他のほとんどのMedusaの亜種を緩和するために必要な手順が含まれていません。

（２）推奨される対策を適用した場合、テナントはSpectre-PHTまたはSpectre-BTBによって引き起こされる情報漏洩から適切に保護されないことを示しています。Spectre-PHTの亜種は、SMTを無効にしても問題が残ります。

（３）Firecracker v1.0.0とv1.4.0のPoCパフォーマンスに違いは見られませんでした。

Firecracker が提供する仮想化レイヤーはマイクロアーキテクチャ攻撃にほとんど効果がなく、Firecracker のシステムセキュリティ推奨事項は不十分であると結論付けました。

5.1 メデューサ

私たちは、テストシステムのベアメタルとFirecracker VMで、Medusa [37]サイドチャネル（IntelではMDS [25]のMLPDSバリアントとして分類）に対するMoghimiのPoC [35]を評価しました。セクション2.4.2で説明した3つの既知のバリアントごとに、漏洩PoCが1つあります。私たちはPoCライブラリから2つの被害者プログラムを使用しました。

• 「ブロック書き込み」プログラムは、ループ内で大量の連続データを書き込みます（これにより、プロセッサは繰り返しの保存を識別し、それらを結合します）。

• 「REP MOV」プログラムは同様の操作を実行しますが、ループ内で小さなデータブロックを移動する多数の命令の代わりに、REP MOV 命令を使用します。

5.1.1 結果。表 1 は、カーネルのすべてのマイクロアーキテクチャ保護を無効にして、データ漏洩に成功したケースを示しています。左の 2 つの列は、3 つの Medusa PoC と 2 つの含まれる被害者プログラムの可能な組み合わせを示しています。右の列は、ベアメタルで機能する構成と、シークレットと漏洩プログラムを Firecracker インスタンスで並列実行している構成を示しています。特に注目すべきは、キャッシュインデックスバリアントでは、ブロック書き込みシークレットが Firecracker でのみ機能することです。これは、仮想マシンが提供するメモリアドレス仮想化によるものと考えられます。ゲストは KVM によってマップされた仮想メモリ領域のみを認識し、KVM はメモリアクセス命令をトラップして、ゲストに代わってトランザクションを処理します。

ベアメタルおよび Firecracker VM で、攻撃者と被害者の PoC の各組み合わせに対する mds および nosmt 防御の有効性をテストしました。表 2 は、ベアメタルおよび Firecracker シナリオで Medusa 攻撃を防ぐために必要な保護を示しています。Firecracker の 4 つの脆弱性のうち、nosmt のみで軽減されるのは 1 つだけです。また、ほとんどの Linux ディストリビューションではデフォルトで mds 保護が有効になっていますが、AWS は mds 保護を有効にすることを明示的に推奨していません。つまり、マルチテナントクラウドプラットフォームは、AWS が推奨するセキュリティ対策に準拠した方法で Firecracker を使用していても、Firecracker VMM 自体が本来は漏洩しないユーザーデータを漏洩するケースなど、Medusa バリアントの大部分に対して脆弱である可能性があります。

5.2 RIDLとその他

このセクションでは、van Schaikらの2019年の論文[50]と併せて提供されたRIDL PoCプログラム[51]の評価を紹介します。RIDLは、CPU内部のバッファ（キャッシュやメモリからではなく）からの投機的ロードを利用するMDS攻撃の一種です。RIDL PoCリポジトリには、論文の後の補遺で公開された攻撃の例や、Fallout MDS攻撃の1つの変種も含まれています。

5.2.1 結果。表 3 は、テストした RIDL PoC に関する基本情報と、攻撃を防ぐための関連対策の有効性を示しています。ベアメタルと Firecracker での攻撃を比較して、Firecracker microVM システムのハードウェアセキュリティが強化されているという Amazon の主張を評価しました。Firecracker システムでのテストでは、ホストシステム (H) と Firecracker ゲストカーネル (VM) で有効になっている対策フラグを区別しています。nosmt および mds カーネルフラグの他に、kaslr、pti、l1tf など、その他の関連フラグ (セクション 2.4.4、[21] を参照) をテストしましたが、これらのプログラムのいずれにも影響はありませんでした。テストした CPU には mds 緩和策が含まれており、tsx_async_abort カーネルフラグが不要になるため、tsx_async_abort 緩和策は除外しました [20]。

一般的に、mds 保護は RIDL 攻撃の大部分に対して十分な保護を提供しないことがわかりました。ただし、SMT を無効にすると、これらのエクスプロイトの大部分が軽減されます。これは、ハイパースレッド全体にわたる MDS 攻撃を防ぐために SMT を無効にする必要があるという Intel [25] および Linux 開発者 [21] の声明と一致しています。これらの PoC の中で例外的なのは、ホスト上で nosmt と mds の両方を必要とする alignment_write と、mds 対策によってのみ軽減される pgtable_leak_notsx です。alignment_write に依存するリークは、ページテーブルフォールトリークではなくアラインメントフォールトを使用して推測をトリガーします [50]。RIDL の論文 [50] および関連する VRS エクスプロイトに関する Intel のドキュメント [26] では、この攻撃が他の PoC で見つかったページフォールトベースの MFBDS 攻撃と正確に何が違うのかは不明ですが、私たちの実験結果では、リークのマイクロアーキテクチャメカニズムは異なることが示されています。 pgtable_leak_notsx の動作には単純かつ合理的な説明があります。この動作は、1 つの重要な理由により、これらの PoC の中ではユニークです。つまり、これは、別のスレッドからリークするのではなく、単一スレッド内でセキュリティ境界を越える (カーネルからページテーブル値をリークする) 唯一のエクスプロイトです。マルチスレッドを無効にしても、この単一スレッドのエクスプロイトにはほとんど影響がないことは自明です。ただし、mds 対策は、同じスレッド内でカーネル特権実行からユーザー特権実行に切り替える前にマイクロアーキテクチャバッファーをフラッシュし、攻撃側のユーザーコードがリークする前に、カーネルコードによってアクセスされたページテーブルデータを LFB から消去します。

Medusa とは対照的に、これらの PoC のほとんどは、AWS の smt を無効にするという推奨事項によって軽減されます。ただし、Medusa と同様に、Firecracker VMM 自体はこれらの攻撃に対するマイクロアーキテクチャ保護を提供しません。

5.3 スペクター

次に、Spectreの脆弱性に焦点を当てます。Spectre攻撃が最初に発見されて以来、多くの対策が開発されてきましたが、その多くは（重大な）パフォーマンスの低下を伴うか、攻撃を部分的にしか軽減しません。そのため、

システムオペレーターは、パフォーマンスとセキュリティのトレードオフを決定する必要があることがよくあります。このセクションでは、前述の両方の脅威モデルで、Firecracker テナントが利用できる Spectre 攻撃対象領域を評価します。Spectre 攻撃の幅広い範囲を評価するために、[15] で提供されている PoC に依存します。Spectre-PHT、Spectre-BTB、および SpectreRSB の場合、リポジトリにはそれぞれ 4 つの PoC が含まれています。これらは、攻撃者が BPU を誤ってトレーニングする方法が異なります。 4 つの可能性は、(1) 同一プロセス - 攻撃者は被害者プロセスまたはその入力を制御して BPU を誤学習させる、(2) クロスプロセス - 攻撃者は別のプロセスで独自のコードを実行して被害者プロセスの分岐予測に影響を与える、(a) インプレース - 攻撃者は、被害者プロセスで誤学習させたいターゲット分岐と同じ仮想アドレスにある分岐命令を使用して BPU を誤学習させる、(b) アウトオブプレース - 攻撃者は、被害者プロセス内のターゲット分岐と一致するアドレスにある分岐命令を使用して BPU を誤学習させる、です。

（１）同一プロセス：攻撃者は被害者のプロセスまたはその入力を制御してBPUを誤認させる。

（２）クロスプロセス：攻撃者は別のプロセスで自身のコードを実行し、被害者プロセスの分岐予測に影響を与える。

（３）インプレース：攻撃者は、標的の分岐と同じ仮想アドレスにある分岐命令を使ってBPUを誤らせ、被害者のプロセスで誤予測させようとする。

（4）アウトオブプレース：攻撃者は、被害者のプロセス内のターゲット分岐と一致するアドレスにある分岐命令を使用してBPUを誤って制御します。

最初の 2 つの状況と後の 2 つの状況は直交しているため、各 PoC ではその 2 つが組み合わされます。Spectre-STL の場合、同じプロセスのバリアントのみが知られているため、この場合、リポジトリは 2 つの PoC のみを提供します。クロス VM 実験では、ホストとゲストのカーネル、およびホストとゲストのユーザーレベルのアドレス空間レイアウトのランダム化を無効にして、ミストレーニングに使用される一致するアドレスを見つけやすくしました。

5.3.1 結果。AWS 推奨の対策 [8] (使用中の Linux カーネルのデフォルト、図 5 参照) をホストシステムと Firecracker VM 内で有効にすると、Spectre-RSB はホスト上と VM 内および VM 間で正常に軽減されることがわかります (表 4 参照)。一方、Spectre-STL、Spectre-BTB、および Spectre-PHT は、特定の状況で情報漏洩を許しました。

Spectre-STL の PoC では漏洩が示されています。ただし、漏洩は同じプロセスおよび同じ権限レベル内でのみ発生します。プロセス間のバリアントは知られていないため、Spectre-STL の VM 間シナリオはテストしていません。ユーザー間の脅威モデルでは、プロセス間のバリアントが知られていないため、Spectre-STL は攻撃ベクトルになり得ません。2 つのテナントワークロードが同じ VM 内のプロセス内分離によって分離される場合でも、Spectre-STL は有効な攻撃ベクトルになる可能性があります。ユーザーからホストへのモデルでは、Spectre-STL は現在の Linux カーネルに含まれ、デフォルトで有効になっている対策によって軽減されます。

Spectre-PHT に対するカーネル対策には、ユーザーポインタのサニタイズと、権限レベルスイッチでのバリア (lfence) の利用が含まれます。したがって、SpectrePHT はホストシステムに対してほとんど脅威を与えない、またはまったく脅威を与えないと結論付けています。ただし、これらの

2 つのハイパースレッドが同じ物理コアで並行して実行されている場合、緩和策はそれらのハイパースレッドを相互に保護しません。これが、Spectre-PHT のミストレーニングバリアント 4 つすべてがホストシステム上だけでなく Firecracker VM 内でも完全に機能する理由です。表 4 に示すように、これは SMT が無効になっている場合でも当てはまります[4]。実際、両方の VM を同じ物理スレッドに固定すると、クロスプロセスアウトオブプレースバージョンの Spectre-PHT が有効になりますが、SMT の場合はリークは確認されませんでした。これにより、Spectre-PHT はユーザー間にとって重大な脅威になります。

Spectre-BTB PoCは、AWS推奨の対策が有効になっている場合、部分的に機能します。同じプロセスで同じアドレスのBTBを誤ってトレーニングする元のバリアントは完全に機能しますが、同じプロセスのアウトオブプレースミストレーニングは

正常に軽減されました。また、アウトオブプレースミストレーニングによるプロセス境界を越えた情報漏洩の試みでは、漏洩は見られませんでした。ただし、プロセス間のインプレースミストレーニングでは、漏洩が見られました。ホストシステムでは、漏洩は SMT とは無関係に発生しました。VM 内では、すべての仮想 CPU コアが別の物理スレッドに割り当てられている場合にのみ漏洩が発生しました。VM 全体では、SMT を無効にすると漏洩がなくなりました。

図5に記載されている対策に加えて、ホストカーネルには、VMのエントリポイントと終了ポイントにコンパイルされたSpectre対策[5]があり、カーネルがVMの終了を処理している間、悪意のあるゲストがホストカーネルを攻撃するのを完全に無効にします。

まとめると、AWS Firecracker が推奨する Linux のデフォルトの対策では、Spectre を部分的にしか軽減できないと言えます。具体的には、次のようになります。

• Spectre-PHT および Spectre-BTB は、AWS が推奨する対策 (SMT の無効化を含む) を実施している場合でも、ゲスト間のシナリオでテナント間で情報を漏洩する可能性があります。

• ホストカーネルは、VM のエントリと終了を保護するために Linux カーネルにコンパイルされた追加の予防措置によって十分に保護されている可能性があります。ただし、これは Firecracker によって提供されるセキュリティ対策とは直交しています。

観察されたすべての漏れは、使用されている Firecracker のバージョンとは無関係でした。

5.3.2 評価。Firecrackerは Spectre に対する緩和策を追加せず、ホストカーネルとゲストカーネルによって提供される緩和策やオプションのマイクロコード更新などの一般的な保護推奨事項のみに依存していることがわかりました。さらに悪いことに、推奨される対策では、サーバーレスアプリケーションが他のテナントに情報を漏らすことを十分に防ぐことができません。したがって、マイクロアーキテクチャ攻撃は Firecracker 脅威モデルの範囲内であると考えられていますが、Firecracker はマイクロアーキテクチャレベルで分離の目標を達成していないと主張します。

注意深い読者は、STIBP対策が実施されているのになぜSpectre-BTBが問題のままなのか疑問に思うかもしれません（図5を参照）。このマイクロコードパッチは、別のスレッドから生成された予測情報を使用して分岐予測を行わないように設計されているからです。これも私たちもしばらく困惑していましたが、最近Googleがセキュリティアドバイザリ[6]を公開しました。このアドバイザリでは、IBRSが有効になっているとSTIBP緩和策が無効になり続けるというLinux 6.2の欠陥が特定されています。私たちは、この問題の原因として特定されたコードセクションがLinux 5.10のソースコードにも存在することを確認しました。したがって、Googleが特定したのと同じ問題が私たちのシステムでも発生すると推測しています。