Mior und Skyfall: Bösartige Cloud-Hosts können Geheimnisse aus AMD-SEV-SNP-VMs auslesen

SEV-SNP bringt Confidential Computing auf AMD-EPYC-Serverprozessoren. Hardwaregestützte Speicherverschlüsselung und Zugriffskontrolle sollen eine VM selbst vor dem Hypervisor des Hosts schützen. Kunden sollen das BIOS-Update von ihrem Serverhersteller beziehen; Korrekturen für Embedded-Chips folgen später.

Mior: Angriff beim Start

Das Team der ETH Zürich hinter Mior griff SEV-SNP während der Initialisierung an. Dabei befüllt ein Sicherheits-Coprozessor auf dem Chip, der Platform Security Processor (PSP), die Reverse Map Table (RMP). Diese Tabelle legt fest, wem jede Speicherseite gehört und was mit ihr geschehen darf.

Die Forscher leiteten die Schreibzugriffe des PSP statt in den Hauptspeicher in den Speicher einer von ihnen kontrollierten Grafikkarte um. Eine Karte wählten sie, weil der PSP die Werte nach ihrer Einschätzung zur Kontrolle zurückliest und die Karte sie liefern konnte. Der Start lief fehlerfrei durch, doch ein Teil der echten RMP – einschließlich des Eintrags, der die Tabelle selbst schützt – blieb uninitialisiert.

Damit konnte der Hypervisor die Schutzeinstellungen der RMP umschreiben. Das Team aktivierte anschließend das Debugging bei einer vertraulichen VM, bei der es abgeschaltet war, und las und schrieb deren Speicher über die Debug-Befehle des PSP. Das gelang in allen 1.000 Versuchen beider Testläufe.

SEV-SNP misst beim Start einer VM außerdem deren Software-Image; der PSP signiert Attestierungsberichte mit diesem Messwert. In einem zweiten Test kopierten die Forscher den Messwert einer harmlosen VM in eine bösartige, deren Attestierungsberichte danach das harmlose Image beschrieben.

Laut dem Mior-Paper braucht der Angriff Kontrolle über Hypervisor und BIOS (UEFI) sowie ein PCIe-Gerät wie eine Grafikkarte. Für die Tests veränderte das Team das BIOS so, dass die Speicher-Routing-Einstellungen des Chips nicht gesperrt wurden. „Wir bewegen uns im Bedrohungsmodell, das AMD für SEV-SNP definiert hat. AMD vertraut dem UEFI ausdrücklich nicht, daher kann ein Angreifer das UEFI verändern“, erklären die Forscher. Gewöhnlichen VMs, die ihrem Host und dessen Firmware ohnehin vertrauen, bringe Mior einem Angreifer nichts Neues.

Getestet wurde Mior auf einem EPYC 9135 (Zen 5). Zen-3- und Zen-4-Chips hält das Team für potenziell betroffen, konnte sie aber mangels eines Aufbaus mit veränderbarem BIOS nicht prüfen. Debugging- und Attestierungsangriff funktionierten auch mit aktiviertem Ciphertext Hiding, einer optionalen SEV-SNP-Funktion, die dem Hypervisor schon das Lesen des verschlüsselten VM-Speichers verwehrt.

Teils dieselben Forscher hatten mit Fabricked und RMPocalypse bereits früher die RMP beim Start von SEV-SNP manipuliert. Mior sei eine eigenständige Lücke, unabhängig von Fabricked und dessen Fix, so das Team; der Angriff funktionierte auch mit älterer Firmware von vor diesem Fix.

Skyfall: Reste im Cache

Skyfall stammt von einem Team der ETH Zürich und Google und baut auf den Transient Scheduler Attacks (TSA) auf, einer am 8. Juli 2025 erstmals offengelegten Gruppe von Schwachstellen in AMD-Prozessoren, die Daten über Befehls-Timing preisgeben. Lässt ein Hypervisor den Start einer VM absichtlich scheitern, hat der Prozessor bereits einen Teil ihres gespeicherten Zustands zwischengespeichert. Diese Daten bleiben ohne die übliche Bereinigung zurück und lassen sich per TSA auslesen.

So gewannen die Forscher gespeicherte Registerwerte und einen Festplattenschlüssel aus einer Test-VM. Für den Schlüssel änderten sie den Kernel der VM so, dass er anhielt, während der Schlüssel in Registern lag. In einem realen Angriff könne ein Hypervisor stattdessen mit der Technik SEV-Step die VM schrittweise ausführen, bis der Schlüssel in den Registern landet. VM-Speicher kann Skyfall nur eingeschränkt lesen: drei feste Cache-Lines einer Zielseite an den Offsets 0x0c0, 0x380 und 0x3c0.

Der Angriff erfordert einen bösartigen Host oder Hypervisor, aber keine Hardware-Manipulation. Getestet wurde er auf EPYC 7313 (Zen 3) sowie EPYC 9124 und 9334 (Zen 4); auf Zen 5 zeigte sich das Leck nicht. Zudem las das Team auf allen drei Chips entschlüsselte Microcode-Updates und gewann Registerwerte aus dem Speicher des System Management Mode (SMM), den selbst der Betriebssystemkernel normalerweise nicht lesen kann. Beides erfordert privilegierte Software auf dem System.

Das Programmkomitee des IEEE Symposium on Security and Privacy, das das Skyfall-Paper angenommen hat, merkte an, die Arbeit übergehe, was ein realistischer Angriff auf VMs voraussetze: einen ansonsten unbelegten Prozessorkern, fehlschlagende VM-Starts und Performance-Counter-Abfragen in hoher Frequenz sowie eine VM, die während des Angriffs weder abstürzt noch in ein Timeout läuft.

CVEs und Patches

• CVE-2026-0462 (Mior): CVSS 4.0 Wert 5.9; laut AMD nur SEV-SNP betroffen, nicht SEV und SEV-ES
• CVE-2026-40671 (Skyfall, VM-Leck): Wert 4.9; AMD beschreibt die Lücke als Offenlegung von VM-Registerdaten
• CVE-2026-18448 (Skyfall, SMM-Leck): vom EDK-II-Projekt vergeben, Wert 5.6

Beide AMD-Hinweise nennen dieselben fünf EPYC-Serverlinien. Dasselbe Paket TurinPI_1.0.0.C erhält in beiden Hinweisen unterschiedliche Zielmonate. Der Skyfall-Microcode ist für jede Linie auf den 12. August datiert. Der Beschleuniger Instinct MI300A hat einen Skyfall-Patch vom 21. September, Fixes für Embedded-EPYC-Modelle sind für Januar bis April 2027 vorgesehen. Das Mior-Team erklärt, aktualisierte Firmware sei bereits verfügbar, das Skyfall-Team, neuer Microcode sei veröffentlicht. Ob diese Updates eigenständig oder nur als Teil der BIOS-Updates wirken, geht aus den Hinweisen nicht hervor; Workarounds nennen sie keine.

Supermicro hat eine BIOS-Fixliste für Dutzende Mainboards der Serien H12, H13 und H14 veröffentlicht. Die Boards benötigen demnach zusätzlich ein BMC-Firmware-Update; betroffene Produkte werden noch getestet.

Da die Korrekturen in der Host-Firmware stecken, sind Mieter vertraulicher VMs auf ihren Cloud-Anbieter angewiesen. Der Mior-Hinweis listet zu jeder korrigierten Firmware TCB-Werte (Trusted Computing Base) für die SNP-Attestierung, erklärt aber nicht, wie VM-Besitzer sie prüfen sollen. Ob die Lücken bereits ausgenutzt wurden, sagen die Hinweise nicht. Beide Teams haben Code veröffentlicht; der Mior-Proof-of-Concept benötigt ein BIOS, das die Speicher-Routing-Einstellungen ungesperrt lässt.

AMDs EDK-II-Bulletin führt das SMM-Leck auf fehlende TSA-Gegenmaßnahmen im EDK-II-Firmwarecode zurück. Es nennt EPYC- und Ryzen-Chips einschließlich Embedded-Modellen und empfiehlt die früheren TSA-Gegenmaßnahmen sowie einen EDK-II-Patch, sobald verfügbar. Für die fünf EPYC-Serverlinien ist nur dieser Patch gelistet, fällig im November; für andere Chips wie EPYC 4004 und 4005 gibt es bereits Plattform-Firmware mit dem Fix. Der eigene Hinweis des EDK-II-Projekts nennt bislang keine korrigierte Version.