L1TF Reloaded に対する Amazon EC2 の防御の仕組み

本ブログは 2025 年 8 月 11 日に公開された AWS Blog “Amazon EC2 defenses against L1TF Reloaded” を翻訳したものです。

AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータが、「L1TF Reloaded」と呼ばれる攻撃によって危険にさらされることはありません。お客様による追加の対応は不要です。ただし AWS は、AWS の公開ドキュメントに記載されているとおり、インスタンス、エンクレーブ、または関数の境界を使用してワークロードを分離することを引き続き推奨しています。AWS Nitro System と Nitro Hypervisor は、この種の攻撃からの保護に役立つように設計されています。

研究論文「Rain: Transiently Leaking Data from Public Clouds Using Old Vulnerabilities」と、その講演「Spectre in the real world: Leaking your private data from the cloud with CPU vulnerabilities」では、L1TF Reloaded という攻撃が実証されています。この攻撃は、ハーフ Spectre ガジェット (half-Spectre gadget) と L1 Terminal Fault (L1TF) を組み合わせてゲストデータを漏洩させるものです。アップストリームの Linux/カーネルベース仮想マシン (KVM) や他のクラウドプロバイダーからはゲストデータを漏洩させることに成功していますが、AWS Nitro System および Nitro Hypervisor を使用する AWS のお客様のゲストデータには影響しません。

Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、AWS がセキュリティに対してプロアクティブなアプローチを取っているためです。Nitro Hypervisor の基本的なセキュリティ設計原則は、この種の攻撃に対して強力な保護を提供します。特に重要なのが、XPFO (eXclusive Page Frame Ownership) の概念 (文脈によってはプロセスローカルメモリとも呼ばれます) を広範に活用したシークレットハイディング (secret hiding) の実装です。L1TF Reloaded は、一時的実行攻撃 (transient execution attack) における革新的な手法です。この攻撃は、一見すると緩和済みの脆弱性を脅威アクターが組み合わせることで、個々の要素の総和を超える新たな攻撃を生み出せることを示しています。この研究はすばらしいもので、実環境に適用可能な多層的なエンドツーエンドのエクスプロイトを構築しています。AWS はこの研究の一部をスポンサーとして支援しました。また、研究者の皆様の協力と協調的な情報開示に感謝いたします。以降では、公開された研究について詳しく解説します。

Nitro Hypervisor: セキュリティのための専用設計

Nitro Hypervisor は AWS Nitro System の基盤となるコンポーネントであり、セキュリティを最優先事項として一から設計されています。汎用オペレーティングシステムから発展してきた従来のハイパーバイザーとは異なり、Linux/KVM をベースとする Nitro Hypervisor は意図的に最小化されており、割り当てられた役割の遂行に必要な機能だけを備えた専用設計となっています。

Nitro Hypervisor の役割は、意図的に限定されています。Nitro Hypervisor は、Nitro Controller から仮想マシン (VM) の管理リクエストを受け取り、ハードウェアの仮想化機能を使用してメモリと CPU リソースを分割し、PCIe デバイスを VM に割り当てます。これらの PCIe デバイスには、Nitro ハードウェアが提供する物理機能 (PF) とシングルルート I/O 仮想化 (SR-IOV) の仮想機能 (VF) の両方が含まれます。例えば、EBS およびインスタンスストレージ用の NVMe や、ネットワーク用の Elastic Network Adapter がこれに該当します。さらに、サードパーティーのデバイス (GPU) も含まれます。重要な点として、Nitro Hypervisor では、従来のハイパーバイザーに存在する機能がカテゴリごと除外されています。ネットワークスタック、汎用ファイルシステムの実装、周辺機器のデバイスドライバーのサポート、シェル、対話型アクセスモードは一切ありません。このように不要な機能を徹底的に除外することで、リモートネットワーク攻撃やドライバーを悪用した権限昇格など、他のハイパーバイザーに影響しうる問題や攻撃ベクトルのカテゴリ全体を回避しやすくなります。

一時的実行の脆弱性の理解

Nitro Hypervisor の防御が L1TF Reloaded に有効である理由を理解するには、まず 2018 年に明らかになった一時的実行の脆弱性の基本を理解しておくことが重要です。現代の CPU は、アウトオブオーダー実行や、予測に基づく投機的実行を実装しています。これにより、操作が必要になる前、あるいはその操作を実行すべきかどうかを CPU が判断する前に操作を実行して、パフォーマンスを最適化しています。予測が誤っていた場合や、実行時のフォールトが発生した場合、CPU は最終的にこれらのエラーを検出し、投機的に計算されたアーキテクチャ状態への変更をすべてロールバックします。しかし、こうした「一時的実行」の痕跡は、CPU キャッシュに投機的に読み込まれたデータなど、マイクロアーキテクチャ状態に検出可能な形で残ります。その結果、サイドチャネル攻撃によってデータが漏洩する余地が生まれます。

ハーフ Spectre ガジェット: 不完全だが危険なコードパターン

従来の Spectre 攻撃には、シークレットデータへのアクセスと、サイドチャネルを通じたそのデータの送信の両方を行う、完全な「ガジェット」が必要です。これに対して研究者たちは、「ハーフ Spectre ガジェット」と呼ばれる、より弱いクラスのガジェットを特定しました。これは、投機的な境界外メモリアクセスを実行するものの、それだけで悪用可能になるための送信コンポーネントを備えていない、不完全な Spectre 類似のコードパターンです。

典型的な Spectre v1 ガジェットには、2 つの主要な要素があります。1 つ目は、シークレットデータを読み込む投機的アクセスです (例えば、x = A[index] で index が境界外である場合)。2 つ目は、サイドチャネルを通じてデータを漏洩させる送信メカニズムです (例えば、y = B[64 * x] のように、シークレット値に基づいたキャッシュパターンを生成するもの)。ハーフ Spectre ガジェットには、1 つ目の要素である投機的アクセスのみが含まれ、送信コンポーネントは含まれていません。

ハーフ Spectre ガジェットは単独では無害に見えるため、ハイパーバイザーを含むさまざまなソフトウェアに広く存在しています。これらのガジェットは通常、境界チェックを伴う配列インデックス操作から生じます。しかし、境界チェックの結果が確定する前の一時的実行のウィンドウでは、境界外アクセスが可能になります。ガジェットには、絶対型 (アクセスするアドレスを直接指定する) と相対型 (ベースアドレスからのオフセットを制御する) があり、一般的な配列インデックスのパターンにより、相対型ガジェットの方が多く見られます。L1TF Reloaded の重要な洞察は、ハーフ Spectre ガジェットは単独では無害であっても、L1TF のような他の脆弱性と組み合わせると危険になるという点です。脅威アクターは、ハイパーバイザー内のハーフ Spectre ガジェットをトリガーして任意のデータを L1 データキャッシュに投機的に読み込ませ、その後 L1TF を使用してキャッシュされたデータを抽出できます。これにより、「無害な」ハーフ Spectre ガジェットが、事実上完全なガジェットに変わります。

Intel L1TF: 投機的なアドレス変換の悪用

L1TF は、2018 年 1 月に発見され、2018 年 8 月に公開された、一時的実行の脆弱性の中でも重大なものです。この脆弱性は、Coffee Lake までの Intel プロセッサに影響します。これらのプロセッサは、一部の第 5 世代 EC2 インスタンスファミリーと、それより古いすべてのインスタンスタイプで使用されています。L1TF は、一時的実行中に無効なページテーブルエントリにアクセスした際に発生する、誤ったアドレス変換を悪用します。通常の動作では、present ビットがクリアされている、または予約ビットが設定されているページテーブルエントリ (PTE) に CPU が遭遇すると、アドレス変換は直ちに停止するはずです。しかし、L1TF の影響を受ける Intel プロセッサは、一時的実行中にこうした無効なページテーブルの状態を無視し、部分的に変換されたアドレスを使用します。対象データが L1 データキャッシュに存在する場合、本来はブロックされるべきアクセスであるにもかかわらず、CPU はそのデータを投機的に読み込み、後続の命令から利用できるようにします。この動作は、仮想化環境で特に問題になります。悪意のあるゲストオペレーティングシステムは、自身のページテーブルの present ビットを意図的にクリアして、ターミナルフォールトをトリガーできます。すると CPU は、通常のホストアドレス変換プロセスをスキップし、ゲストの物理アドレスを L1 データキャッシュに直接渡します。これにより、脅威アクターは、所有権や特権の境界に関係なく、システム上のキャッシュされた任意の物理メモリを読み取れる可能性があります。影響を受けるプロセッサにおいて、ソフトウェアで包括的に緩和するには、同時マルチスレッディング (SMT) の無効化、コンテキストスイッチごとの L1 データキャッシュのフラッシュ、拡張ページテーブル (EPT) の完全な無効化といった、コストの高い対策が必要です。これらのパフォーマンスへの影響は非常に大きいため、多くのシステムでは部分的な緩和策しか実装されていません。

L1TF Reloaded 攻撃: Spectre を使って緩和策の不備を悪用

この研究論文は、脅威アクターがハーフ Spectre ガジェットと L1TF を組み合わせることで、前述の緩和策が完全には実装されていないハイパーバイザーに対する強力な攻撃ベクトルを生み出せることを実証しています。この攻撃は、個別には緩和済みとみなされている脆弱性であっても、新しい方法で組み合わせれば依然として悪用できることを示しています。L1TF の緩和策である L1 データキャッシュのフラッシュやコアスケジューリングは、ゲスト間の攻撃の防止には役立ちますが、ゲストからホストへの攻撃を完全には緩和できません。L1TF Reloaded は、この点を突いた攻撃です。この攻撃は、SMT コア内で L1 データキャッシュを共有する論理コアにまたがって動作します。脅威アクターは、一方の論理コアでハーフ Spectre ガジェットをトリガーします。分岐予測器を意図的に誤学習させることで、ハイパーバイザーに境界外メモリへ投機的にアクセスさせ、機密データを共有 L1 データキャッシュに読み込ませます。同時に、もう一方の論理コアで L1TF を使用して、キャッシュされたデータを抽出します。他の研究論文でも L1TF の悪用は実証されていますが、この研究論文は、アップストリームの Linux/KVM や他のクラウドプロバイダーに対する多層的なエンドツーエンドの攻撃の実証に成功しました。著者らが実行した手順は次のとおりです。まず、既存のハーフ Spectre ガジェットを使用してホストのカーネルアドレス空間配置のランダム化 (KASLR) を突破し、ホストのアドレス変換機能を獲得しました。次に、ホスト上で実行されているすべてのプロセスを見つけ出し、被害者の VM を特定しました。さらに、ゲストの KASLR を突破してゲストのアドレス変換機能を獲得し、被害者の VM 内の init プロセスを特定しました。その後、init プロセスの子プロセスを列挙して nginx ウェブサーバーのプロセスを特定し、ゲストプロセスのヒープ内でプライベート TLS 証明書を見つけ出し、最終的にその証明書を漏洩させました。しかし、AWS インスタンスで同じ攻撃を試みたところ、著者らは重大な制約に直面しました。機密性のない一部のホストデータは漏洩させることができたものの、ゲストデータにはアクセスできなかったのです。著者らはその原因を「ハイパーバイザー内に存在する、被害者のデータをハイパーバイザーからアンマップする文書化されていない防御」と説明しています。この「文書化されていない防御」こそが Nitro Hypervisor によるシークレットハイディングの実装であり、この種の攻撃を防いだアーキテクチャ上の基本的な設計判断です。

シークレットハイディング: ハイパーバイザーのメモリアーキテクチャの再考

従来のハイパーバイザーの設計は、上位の特権レベルがそれより下位のレベルのすべてのメモリにアクセスできる、階層型の特権モデルに従っています。従来のシステムでは、最も高い特権レベルで実行されるハイパーバイザーが、正当な管理目的という名目で、すべての VM メモリにアクセスできます。しかし、この設計には脆弱性があります。脅威アクターがハイパーバイザーをだましてゲストデータに投機的にアクセスさせることができれば、そのデータはサイドチャネル攻撃によって抽出可能になってしまうのです。Nitro Hypervisor は、シークレットハイディングと呼ばれる手法によって、根本的に異なるアプローチを採用しています。ハイパーバイザーがすべての VM メモリにアクセスできる従来のモデル (図 1) に従うのではなく、ゲストデータがハイパーバイザーの仮想アドレス空間に存在しないようにしています。AWS は、VM メモリページをハイパーバイザーの仮想アドレス空間から取り除く (図 2) ことで、たとえ脅威アクターがハイパーバイザー内のガジェットをトリガーできたとしても、一時的実行攻撃によってゲストデータにアクセスされる可能性を排除しています。

図 1: VM1 のコンテキストにおける、緩和策のないハイパーバイザーのメモリビュー

図 2: VM1 のコンテキストにおける Nitro Hypervisor のメモリビュー。ゲストメモリはマッピングされておらず、アクセスできるのはアクティブなゲストの状態のみです。他のゲストの状態にはアクセスできません。

このアーキテクチャ上の設計判断により、L1TF、ハーフ Spectre ガジェット、その他の一時的実行の脆弱性のいずれによって Nitro Hypervisor で一時的実行が発生しても、漏洩しうるゲストデータがそもそも存在しません。これが、この種の脆弱性に対する障壁となります。Nitro Hypervisor がアクセスできるのは自身のデータのみであり、ゲストデータは分離され、アクセスできない状態に保たれます。AWS は、L1TF Reloaded そのものを正確に予測できたわけではありません。しかし、一時的実行の脆弱性が今後も発見され続けることはわかっていたため、AWS インスタンス上のゲストデータの抽出を阻止する多層防御の仕組みを構築しました。この設計判断は、Nitro Hypervisor の開発時にプロアクティブに行われたもので、ハイパーバイザーを悪用するゲストからホストへの攻撃を明示的に想定した AWS の脅威モデルに基づいています。AWS は、L1TF のような既知の脆弱性か、将来の未知の攻撃ベクトルかを問わず、脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーする方法を見つけ出す可能性があると想定しました。そのうえで、こうした攻撃の影響範囲を当初から限定するようにシステムを設計しました。

メモリにとどまらず: ゲスト CPU コンテキストの保護

VM のスケジューリングやコンテキストスイッチの際には、汎用レジスタや浮動小数点レジスタの内容などのゲスト CPU コンテキスト情報を保存および復元する必要があります。ゲスト CPU コンテキストには、機密性の高い情報が含まれる場合があります。例えば、レジスタには、暗号鍵、アドレス空間配置のランダム化 (ASLR) を突破しうるメモリアドレス、アプリケーションがセキュリティのために依存しているその他のシークレットが含まれている可能性があります。従来のハイパーバイザーでは、ゲスト CPU コンテキストはハイパーバイザーからアクセス可能なメモリに保存されることが多く、一時的実行攻撃のもう 1 つの潜在的な標的となります。元の XPFO の実装では、メモリページにアクセスできるのはユーザー空間とカーネルのどちらか一方のみであり、両方がアクセスすることはできません。ただし、ゲスト CPU コンテキストはカーネルが排他的に所有しているため、保護の対象外です。Nitro Hypervisor は、XPFO の概念をゲスト CPU コンテキストにまで拡張しています。前述の図 2 に示すように、ゲスト CPU コンテキストは、プロセス固有のカーネル PTE によってのみマッピングされるメモリ (プロセスローカルメモリとも呼ばれます) に保存されます。このメモリは、所属するプロセスのコンテキストにおいてのみ、Nitro Hypervisor からアクセスできるように設計されています。そのため、たとえ脅威アクターが Nitro Hypervisor 内で一時的実行の脆弱性をトリガーできたとしても、他のゲストの CPU コンテキストにはアクセスできません。研究者たちもこの保護を確認しており、AWS の脅威モデルがゲストからホストへの攻撃を考慮していること、そしてシークレットハイディングが既存の L1 データキャッシュのフラッシュおよびコアスケジューリングと組み合わさることで、ゲストデータの漏洩を防いだことを指摘しています。シークレットハイディングに対するこの包括的なアプローチは、Nitro System の多層防御の理念を示しています。既知の攻撃ベクトルへの対策にとどまらず、AWS は、ゲストデータの漏洩につながる潜在的な発生源を体系的に特定して保護しています。これには、VM メモリとゲスト CPU コンテキストの両方が含まれます。

Xen へのシークレットハイディングの原則の適用

現在、AWS の Xen インスタンスの大部分は AWS Nitro System 上で実行されており、Xen-on-Nitro によって Nitro Hypervisor のメリットを享受しています。AWS Xen Hypervisor 上で実行されるインスタンスファミリーについても、AWS は一時的実行攻撃から保護するために、同様のシークレットハイディングの原則を実装しています。

多層防御: Nitro Hypervisor の実証されたセキュリティモデル

L1TF Reloaded は、一見すると緩和済みの脆弱性を組み合わせて新たな攻撃ベクトルを生み出せることについての理解を大きく深めるものです。Rain 論文の研究者たちは、L1TF とハーフ Spectre ガジェットを連携させて、ハイパーバイザーからゲストデータを漏洩させる方法を実証しました。AWS は、研究者たちの取り組みを支援し、協力できることをうれしく思います。Nitro Hypervisor が L1TF Reloaded を防げているのは、特定のパッチや事後的な緩和策によるものではなく、高度な攻撃者からマルチテナントのクラウド環境を保護するために AWS が多大な投資を続けてきた結果です。この研究により、既知および未知の攻撃ベクトルに対する Nitro System のセキュリティモデルへの確信がさらに強まりました。AWS のプロアクティブなセキュリティアプローチには、多層防御の原則に基づいてシステムを一から設計することが含まれます。脅威の状況は今後も変化し続けます。それと同時に、Nitro Hypervisor や AWS のその他の製品およびサービスに組み込まれた多層防御の仕組みは、お客様が必要とするパフォーマンスと機能を維持しながら、今後も高度な攻撃から AWS のお客様を保護するのに役立ちます。

この記事に関するご質問やフィードバックがある場合は、AWS サポートにお問い合わせください。

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。