freax13/cve-2024-21978-pocAMD SEV-SNP ファームウェアの脆弱性 CVE-2024-21978 のエクスプロイト。コンテキストページのメモリ破損を介して任意のゲストメモリの復号を可能にする。
このリポジトリには、SEVファームウェアの脆弱性を利用したエクスプロイトが含まれています。このエクスプロイトにより、実行中のSEV-SNPゲストの任意のメモリを復号化できます。
執筆時点の最新バージョン1.55.16でテスト済み。
SEV_INIT_EXコマンドのnv_paddrフィールドを使用すると、ファームウェアにメモリの一部を提供し、永続フラッシュの代わりに使用することができます。SEV-SNPが有効な場合、このメモリはFIRMWARE状態でなければなりません。ファームウェアはSEV_INIT_EXコマンドの実行中にこの状態を確認します。その後、ファームウェアはこのメモリがFIRMWARE状態にあると想定し、追加のチェックなしに書き込みを行います。
メモリがまだFIRMWARE状態にあるという想定は常に正しいわけではなく、ホストがSNP_PAGE_RECLAIMコマンドを使用して状態をHYPERVISORに戻すことを妨げるものは何もありません。ページがHYPERVISOR状態になると、他の状態（例：CONTEXT）に遷移させることができます。ページがFIRMWARE状態でなくなっても、ファームウェアはそれらのページに書き込むため、特定のページ状態で必要とされる整合性が損なわれます。
このメモリ破壊をCONTEXTページを標的にすることで悪用できます。CONTEXTページは強力な標的ですが、いくつかの問題があります：
CONTEXTページは他のメモリとは異なる鍵で暗号化されています。そのため、暗号文を制御できたとしても平文を制御するのは容易ではありません。メモリ破壊はCONTEXTページをランダムなデータで埋めることになります。そのため、攻撃者にとって有用な形でCONTEXTページを破壊するのは容易ではありません。これを回避するために、バグを繰り返しトリガーして破壊を引き起こし、SNP_GUEST_STATUSコマンドを使用して破壊されたCONTEXTページの関連フィールドを読み取り、有用な値が観測されるまで繰り返すことができます。
SNP_DBG_DECRYPTコマンドを使用すると、DEBUGポリシーが有効になったSEV-SNPゲストのメモリを復号できます。CONTEXTページにDEBUGフラグが設定され、別のゲストのASIDが含まれるように細工できれば、そのゲストのメモリを、たとえDEBUGポリシーが設定されていなくても復号するために使用できます。
SNP_DBG_DECRYPTはCONTEXTページのほとんどのフィールドを無視し、次のフィールドのみをチェックすることがわかります：gctx->guest.asid、gctx->guest.policy_snp、およびgctx->guest.guest_flags。メモリ破壊後にこれらのフィールドが正しい確率は高くありませんが、不可能でもありません。朗報は、GUEST_STATUSコマンドを使用してこれらのフィールドをすべて読み取れることです。
結論として、以下の手順でバグを悪用できます：
rmpupdate命令を使用してnv_paddrをFIRMWARE状態に遷移させる。SEV_INIT_EXコマンドを実行する。SNP_RECLAIM_PAGEコマンドを使用してnv_paddrをHYPERVISOR状態に戻す。nv_paddrに1つ以上のCONTEXTページを作成する。SEV_PDH_GENコマンドを使用してファームウェアにnv_paddrへの書き込みを仕掛ける。これによりCONTEXTページが破壊される。GUEST_STATUSコマンドを使用してSNP_DBG_DECRYPTが成功するか確認し、失敗したら手順5に戻る。ここでの主なボトルネックは、ASIDが32ビット整数で格納されているが、有効なASIDははるかに少ない（CPUに応じて509または1006）ため、正しい値になるまでかなりの試行が必要なことです。エクスプロイトはほとんどの時間を手順5と6に費やします。EPYC Milanですべての条件が揃う確率は約1/20,000,000で、毎秒約100回の試行が可能なため、約2日に1回条件が揃うと予想されます（注意：計算は概算であり、私が何かを間違えている可能性もありますが、経験的には2日に1回が妥当に感じられます）。一度に1つのCONTEXTページだけでなく、nv_paddr、nv_paddr+4096、nv_paddr+8192の3つのCONTEXTページを攻撃することで高速化できます（SEV_PDG_GENは3ページを破壊します）。これらの手順は被害ゲストを起動する前に行うことができ、一度成功すれば任意の数のゲストを攻撃できます（ただし、現在のPoCは1つのゲストのみを攻撃します）。
まだテストできていませんが、攻撃者がこの脆弱性を使用してゲストの仮想マシンプラットフォーム通信キーを漏洩した場合、ゲストに代わってファームウェアにゲストメッセージを送信し、これを使用してアテステーションレポートを要求できると考えています。これは、アテステーションレポートを要求できるのはゲストのみであるべきというSEV-SNPの重要な原則に違反します。
FIRMWAREページを受け入れるいくつかのコマンド（例：SNP_RECLAIM_PAGE、SNP_GCTX_CREATE、RING_BUFFER、おそらく他にも？安全のためすべて？）は、nv_paddrと重複するかどうかを確認し、重複する場合は失敗するようにすべきです。
もう1つ懸念点があり、それが有効かどうか確信が持てず、皆さんの意見を聞きたいです：IIUC、SEVファームウェアは実行中のゲストを中断せずにアップグレードできます。つまり、古い脆弱なファームウェアバージョンから新しい修正済みファームウェアバージョンに、破損したCONTEXTページを引き継ぐことが可能ではないかと思います。古い脆弱なバージョンで開始し、上記のエクスプロイトを実行し、新しい修正済みファームウェアにアップグレードしてコミットし、新しいファームウェアでゲストを起動し（これによりアテステーションレポートに古いファームウェアバージョンが表示されないようにする）、その後、古いファームウェアで作成された破損したCONTEXTページを使用して、新しいバージョンで作成されたゲストを攻撃することは可能でしょうか？新しいゲストによって作成されたアテステーションレポートの消費者は、新しいゲストが起動される前に古いファームウェアバージョンが実行されていたことを知ることができるのでしょうか？もしできないのであれば、これを防ぐためにさらなる緩和策が必要ですか？
root@server:~/sev-exploit# cargo run --release
Finished release [optimized] target(s) in 0.12s
Running `target/release/sev-exploit`
Corrupt guest context page so that ASID is in range 1..510
Smallest ASID: 0x0000001f iterations: 14052175 zeros: 10539628 unique asids: 31500727 elapsed time: 1d 19h 20m 31s
Creating VM with same ASID
[03, 00, 00, 00, 00, 00, 00, 00, 11, 0f, a0, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, f0, 51, a5, 03, 3f, 69, 6b, 93, e8, d8, 61, 0d, 2e, 5a, 45, f1, ea, 6d, bf, 49, fe, e4, a9, 2d, 8d, af, 76, 5e, 2e, 56, e0, fa, a9, b3, a7, e0, bc, 09, d9, 4f, 28, 5c, 9f, 84, d2, 7e, 34, eb, ea, 3f, 29, 88, 30, 01, 28, 65, 8b, 73, 3c, 84, 00, ae, 4a, 74, a2, 7a, d1, c7, 4f, 63, 7f, 72, 7b, 3b, 2f, 08, b3, 1a, 8c, 99, 1b, ad, b5, 1d, 42, 0b, 4d, 98, d4, 7d, c1, 0b, d6, 2f, b4, 6c, 6b, 51, a2, 92, 17, 3b, 01, e8, 82, 11, 1e, cb, cb, a2, 8f, c9, b0, 52, 1d, 1d, b7, d2, 25, 8d, 32, a9, 7a, 6f, 86, e4, 40, 44, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 80, 00, 88, 00, 00, 00, 00, ee, ff, 00, 00, f0, ff, ff, ff, ff, ff, ff, ff, ff, 3f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, <cut off zeros>]
thread 'main' panicked at src/main.rs:170:13:
not yet implemented: use the leaked secrets to send guest messages
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
エクスプロイトがかなりの時間（運が良ければ数時間、悪ければ数日）実行されるのは正常です。EPYC Genoaで実行すると、有効なASIDが約2倍あるため、おそらく高速になります。
手順5と6の間、PoCはいくつかのメトリクスを表示します：
CONTEXTページがファームウェアによってまだASIDが割り当てられていないと見なされる状態にあります。その場合、SNP_GUEST_STATUSはASIDフィールドに0を返します。ほとんどの場合、破損したCONTEXTページの廃棄はファームウェアのクラッシュを引き起こします（おそらくここ）。AFAICT、ファームウェアのクラッシュはシステム全体のリセットを引き起こします。このようなクラッシュを回避するために、カーネルパッチはCONTEXTページが廃棄されるのを防ぎます。これの欠点の1つは、ccpカーネルモジュールをアンロードできないことです。PoCが開始されると、システム全体を再起動しない限り再び開始できません（PoCが成功したか中断されたかに関係なく）。
CONTEXTページの破損したASIDを使用して被害ゲストを起動（およびオプションで実行）する。シークレットページを追跡する。これは、SEVファームウェアがアクティブなASIDを内部で追跡し、重複をチェックするためにアクティブなCONTEXTページをチェックしないため可能です。CONTEXTページを使用して、被害ゲストのシークレットページに対してSNP_DBG_DECRYPTを実行する。