freax13/cve-2024-21978-poc
Dieses Repository enthält einen Exploit für eine Schwachstelle in der SEV-Firmware. Der Exploit ermöglicht es, beliebigen Speicher eines laufenden SEV-SNP-Gasts zu entschlüsseln.
Getestet mit Version 1.55.16 (zum Zeitpunkt des Schreibens die neueste).
Das Feld nv_paddr des Befehls SEV_INIT_EX kann verwendet werden, um der Firmware einen Speicherbereich zu überlassen, damit dieser anstelle des persistenten Flash-Speichers verwendet werden kann. Wenn SEV-SNP aktiviert ist, muss sich dieser Speicher im Zustand FIRMWARE befinden. Die Firmware überprüft dies einmal während der Ausführung des Befehls SEV_INIT_EX. Von da an geht die Firmware davon aus, dass sich dieser Speicher im Zustand FIRMWARE befindet, und schreibt ohne weitere Prüfungen darauf.
Die Annahme, dass sich der Speicher noch im Zustand FIRMWARE befindet, ist nicht immer korrekt: Nichts hindert den Host daran, den Zustand mithilfe des Befehls SNP_PAGE_RECLAIM zurück in den Zustand HYPERVISOR zu ändern. Sobald sich die Seiten im Zustand HYPERVISOR befinden, können sie in andere Zustände überführt werden, z. B. CONTEXT. Obwohl sich die Seiten nicht mehr im Zustand FIRMWARE befinden, schreibt die Firmware weiterhin auf diese Seiten und verletzt damit die Integrität, die bestimmte Seitenzustände erfordern.
Wir können diese Speicherkorruption ausnutzen, indem wir CONTEXT-Seiten angreifen. CONTEXT-Seiten sind ein mächtiges Ziel, aber es gibt einige Probleme:
CONTEXT-Seiten werden mit einem anderen Schlüssel verschlüsselt als anderer Speicher. Daher ist es nicht einfach, den Klartext zu kontrollieren, selbst wenn wir den Chiffretext kontrollieren könnten.Die Speicherkorruption füllt die CONTEXT-Seite effektiv mit zufälligen Daten, sodass es nicht einfach ist, CONTEXT-Seiten so zu korrumpieren, dass es für den Angreifer nützlich ist. Um das zu umgehen, können wir den Fehler wiederholt auslösen, um eine Korruption zu verursachen, und den Befehl SNP_GUEST_STATUS verwenden, um relevante Felder der korrumpierten CONTEXT-Seite auszulesen, bis wir Werte beobachten, die nützlich sind.
Der Befehl SNP_DBG_DECRYPT kann verwendet werden, um den Speicher eines SEV-SNP-Gasts mit aktivierter DEBUG-Richtlinie zu entschlüsseln. Wenn wir eine CONTEXT-Seite so gestalten können, dass das DEBUG-Flag gesetzt ist und sie die ASID eines anderen Gasts enthält, können wir sie verwenden, um den Speicher des anderen Gasts zu entschlüsseln, auch wenn dieser keine DEBUG-Richtlinie gesetzt hat.
Es stellt sich heraus, dass SNP_DBG_DECRYPT die meisten Felder in der CONTEXT-Seite ignoriert; es prüft nur gctx->guest.asid, gctx->guest.policy_snp und gctx->guest.guest_flags. Die Wahrscheinlichkeit, dass diese Felder nach der Speicherkorruption korrekt sind, ist nicht hoch, aber sie liegt auch nicht außerhalb des Bereichs des Möglichen. Die gute Nachricht ist außerdem, dass wir alle diese Felder mit dem Befehl GUEST_STATUS auslesen können.
Zusammenfassend können wir den Fehler mit den folgenden Schritten ausnutzen:
nv_paddr mithilfe der rmpupdate-Instruktion in den Zustand FIRMWARE überführen.SEV_INIT_EX ausführen.nv_paddr mithilfe des Befehls SNP_RECLAIM_PAGE zurück in den Zustand HYPERVISOR überführen.CONTEXT-Seiten an nv_paddr erstellen.SEV_PDH_GEN dazu bringen, auf nv_paddr zu schreiben. Dies korrumpiert die CONTEXT-Seiten.GUEST_STATUS verwenden, um zu prüfen, ob SNP_DBG_DECRYPT erfolgreich wäre; falls nicht, zurück zu Schritt 5. Der Hauptengpass hierbei ist, dass ASIDs in einer 32-Bit-Ganzzahl gespeichert werden, es aber viel weniger gültige ASIDs gibt (509 oder 1006, je nach CPU), sodass es ziemlich viele Versuche dauern wird, bis dies stimmt.Der Exploit verbringt die meiste Zeit mit den Schritten 5 und 6. Die Wahrscheinlichkeit, alle richtigen Bedingungen zu treffen, liegt auf einem EPYC Milan bei etwa 1/20.000.000, und wir schaffen etwa 100 Versuche pro Sekunde. Wir erwarten also, etwa einmal alle zwei Tage die richtigen Bedingungen zu treffen (Warnung: Die Berechnungen sind nur Näherungswerte, und ich könnte etwas falsch gemacht haben, aber anekdotisch fühlt sich einmal alle zwei Tage ungefähr richtig an). Wir können dies beschleunigen, indem wir nicht nur eine CONTEXT-Seite auf einmal angreifen, sondern drei CONTEXT-Seiten bei nv_paddr, nv_paddr+4096 und nv_paddr+8192 (SEV_PDG_GEN wird drei Seiten korrumpieren). Praktischerweise können diese Schritte vor dem Start des Opfer-Gasts durchgeführt werden und müssen nur einmal gelingen, um eine beliebige Anzahl von Gästen anzugreifen (beachten Sie jedoch, dass der PoC derzeit nur einen Gast angreift).
Obwohl ich dies noch nicht testen konnte, glaube ich, dass ein Angreifer, sobald er diese Schwachstelle ausgenutzt hat, um die Kommunikationsschlüssel der virtuellen Maschinenplattform des Gasts abzugreifen, in der Lage sein sollte, im Namen des Gasts Gastnachrichten an die Firmware zu senden und damit Attestierungsberichte anzufordern. Dies verstößt gegen ein zentrales Prinzip von SEV-SNP, bei dem nur der Gast in der Lage sein sollte, Attestierungsberichte anzufordern.
Einige Befehle (z. B. SNP_RECLAIM_PAGE, SNP_GCTX_CREATE, RING_BUFFER, vielleicht mehr?, vielleicht alle, um sicherzugehen?), die eine FIRMWARE-Seite akzeptieren, sollten prüfen, ob diese mit nv_paddr überlappt, und in diesem Fall fehlschlagen.
Ich habe noch eine weitere Sorge, von der ich nicht sicher bin, ob sie berechtigt ist, und zu der ich gerne eure Meinung hören würde: Wenn ich richtig verstehe, kann die SEV-Firmware aktualisiert werden, ohne laufende Gäste zu unterbrechen. Das deutet für mich darauf hin, dass es möglich wäre, die korrumpierte CONTEXT-Seite von einer alten verwundbaren Firmware-Version auf eine neue, gepatchte Firmware-Version zu übertragen. Wäre es möglich, mit einer älteren verwundbaren Version zu starten, den oben beschriebenen Exploit durchzuführen, das Upgrade durchzuführen und die neue, gepatchte Firmware zu übernehmen, den Gast mit der neuen Firmware zu starten (damit die alte Firmware-Version nicht im Attestierungsbericht auftaucht) und dann die mit der alten Firmware erstellte korrumpierte CONTEXT-Seite zu verwenden, um den mit der neuen Version erstellten Gast anzugreifen? Könnte ein Konsument der vom neuen Gast erstellten Attestierungsberichte erkennen, dass die alte Firmware-Version irgendwann vor dem Start des neuen Gasts ausgeführt wurde? Wenn nicht, sind weitere Gegenmaßnahmen erforderlich, um dies zu verhindern?
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, 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
Beachten Sie, dass es normal ist, dass der Exploit eine erhebliche Zeit läuft (in der Größenordnung von Stunden, wenn man Glück hat, Tagen, wenn nicht). Auf einem EPYC Genoa wird es wahrscheinlich schneller gehen, weil es fast doppelt so viele gültige ASIDs gibt.
Während der Schritte 5 und 6 zeigt der PoC einige Metriken an:
CONTEXT-Seite in einem Zustand, in dem die Firmware davon ausgeht, dass noch keine ASID zugewiesen wurde. In diesen Fällen gibt SNP_GUEST_STATUS im ASID-Feld den Wert 0 zurück.In den meisten Fällen führt die Stilllegung korrumpierter CONTEXT-Seiten zu einem Absturz der Firmware (höchstwahrscheinlich hier). Soweit ich das beurteilen kann, verursachen Abstürze der Firmware einen Reset des gesamten Systems. Um solche Abstürze zu vermeiden, verhindern die Kernel-Patches, dass CONTEXT-Seiten stillgelegt werden. Ein Nachteil davon ist, dass das Kernelmodul ccp nicht entladen werden kann. Sobald der PoC gestartet wurde, muss das gesamte System neu gestartet werden, bevor er erneut gestartet werden kann (unabhängig davon, ob der PoC erfolgreich war oder abgebrochen wurde).
CONTEXT-Seite starten (und optional ausführen). Die Secrets-Seite im Auge behalten. Dies ist möglich, weil die SEV-Firmware aktive ASIDs intern verfolgt und die aktiven CONTEXT-Seiten nicht auf Duplikate prüft.CONTEXT-Seite verwenden, um SNP_DBG_DECRYPT auf der Secrets-Seite des Opfer-Gasts auszuführen.