Das Exploit „Fabricked“ zerstört die Hardware-Schutzmechanismen der EPYC-Chips vollständig und effektiv – AMD hat bereits ein Fix veröffentlicht

Kurzfassung

Im April entdeckten Forscher von ETH Zürich eine Schwachstelle in der Hardware-Schutzfunktion AMD SEV‑SNP, die es Angreifern ermöglicht, vollen Zugriff auf den geschützten Speicher einer virtuellen Maschine (CVM) auf AMD EPYC-Prozessoren zu erlangen. Der Exploit, genannt Fabricked, nutzt Schwächen bei der Speicherweiterleitung über Infinity Fabric während des Bootvorgangs aus und kann die kryptografische Attestierung täuschen, auf die Benutzer vertrauen, um die Integrität ihrer Umgebung zu überprüfen.

1. Was ist AMD SEV‑SNP und wozu dient es
* Confidential Computing ermöglicht Cloud-Mandanten sicherzustellen, dass der Anbieter ihre Daten nicht lesen kann.
* SEV‑SNP erzeugt hardware-isolierte virtuelle Maschinen: Speicher wird verschlüsselt und der Zugriff wird von einem eingebetteten Sicherheitsprozessor – PSP (Platform Security Processor) – kontrolliert.
* Beim Booten initialisiert der PSP die Reverse Map Table (RMP) – eine Zugriffs-Tabelle für jede Speicherseite.
Die Attestierung (kryptografische Prüfung) hängt von einer korrekten RMP-Implementierung ab.

2. Wie funktioniert Fabricked
1. Problem im UEFI
* AMD-Geräte nutzen UEFI zur Konfiguration von Infinity Fabric – dem interchip-Netzwerk, das den Speicherverkehr zwischen Kernen, Controllern und Peripherie routet.
* Während des Bootvorgangs ruft UEFI zwei PSP‑APIs auf, die die Konfigurationsregister von Infinity Fabric „sperren“, nachdem sie gesetzt wurden.
* Wenn UEFI manipuliert wird (was möglich ist, da es von Cloud-Anbietern kontrolliert wird), können diese Aufrufe übersprungen werden, sodass das Data Fabric weiterhin schreibbar bleibt, selbst nach Aktivierung von SEV‑SNP.
2. Mangelhafte MMIO-Prüfung
* Bei PSP-Anfragen zum Speicherzugriff erfolgt die Prüfung zunächst über MMIO-Regeln (für Hardwaregeräte), anschließend über normale DRAM-Regeln.
* Ein Angreifer kann MMIO-Zuordnungen so konfigurieren, dass sie den RMP-Bereich „verbergen“. Dadurch werden PSP-Schreibvorgänge ignoriert, SEV‑SNP meldet jedoch weiterhin eine erfolgreiche Initialisierung.
3. Ergebnis – die nicht initialisierte RMP bleibt unter Kontrolle des Angreifers. Der Hypervisor kann beliebige Speicherbereiche der CVM lesen und schreiben, ohne dass das Gastbetriebssystem dies bemerkt.

3. Demonstration von Exploits
* Aktivierung des Debug-Modus auf einer laufenden CVM nach Attestierung – dem Hypervisor gelingt es, jeden Teil des Speichers zu entschlüsseln, ohne entdeckt zu werden.
* Massiver Austausch von Attestationsberichten – ermöglicht es Angreifern, falsche Integritätsbestätigungen auszugeben.

4. Was bedeutet das für Benutzer
* Die Schwachstelle ist vollständig deterministisch und hat 100 % Erfolgschancen ohne physischen Zugriff auf den Server.
* Es wird keine Codeausführung innerhalb der VM benötigt – ein Cloud-Host, der UEFI kontrolliert, reicht aus.
* Benutzer, die sich auf SEV‑SNP für Confidential Computing verlassen, riskieren den Verlust der Kontrolle über ihre Daten.

5. Was die Forscher sagen
Die Ergebnisse wurden in einem Artikel *USENIX Security 2026* veröffentlicht. Die Autoren betonen, dass Fabricked den Schlüsselmechanismus der Attestierung umgeht und praktische Exploits demonstriert, die die Ernsthaftigkeit der Bedrohung belegen.

Fazit:

Fabricked deckt eine fundamentale Schwachstelle in der Schutzkette von AMD SEV‑SNP auf. Ohne Maßnahmen zur Aktualisierung des UEFI und zur Verstärkung der RMP-Prüfung können Cloud-Anbieter vollen Zugriff auf den geschützten Speicher virtueller Maschinen erlangen, ohne dass die Mandanten dies bemerken.