AMD hat Sicherheitsupdates für die Schwachstelle RMPocalypse (CVE-2025-0033) veröffentlicht. Die Lücke betrifft Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) und berührt damit zentrale Garantien für Vertraulichkeit und Integrität in Confidential-Computing-Umgebungen. Forschende der ETH Zürich zeigen, dass sich während der frühen Initialisierung eine gezielte Einzel‑Schreiboperation in die Reverse Map Table (RMP) erzwingen lässt – eine Kernstruktur, die Sicherheitsmetadaten für alle DRAM‑Seiten verwaltet.
RMPocalypse erklärt: Warum die SEV-SNP-Vertrauensbasis angreifbar wurde
SEV-SNP isoliert und verschlüsselt den Speicher von Gast‑VMs derart, dass selbst ein privilegierter Hypervisor keinen direkten Zugriff erhält. Dieses Modell setzt voraus, dass Attributierung und Zuordnung von Speicherseiten unveränderlich und hardwaregestützt abgesichert sind.
Die Rolle der Reverse Map Table (RMP) als Vertrauensanker
Die RMP bildet System‑physische Adressen (sPA) auf Gast‑physische Adressen (gPA) ab und hält kritische Sicherheitsattribute jeder Seite. Sie wird über x86‑MSRs konfiguriert, unter Mitwirkung des Hypervisors verwaltet und vom Platform Security Processor (PSP/ASP) initialisiert. Für SEV‑SNP ist die Korrektheit und Unveränderlichkeit der RMP ein nicht verhandelbarer Bestandteil der Vertrauenskette.
Technischer Kern: Race-Condition bei der RMP-Initialisierung
Laut AMD handelt es sich um eine Race‑Condition während der RMP‑Initialisierung durch den Sicherheitsprozessor. In dieser kurzen Phase kann die RMP unzureichend geschützt sein, sodass ein Angreifer eine gezielte Einzel‑Schreiboperation durchsetzt. Ergebnis: Die erwartete Unveränderlichkeit der RMP beim VM‑Start kann verletzt werden, wodurch SEV‑SNP‑Prüfungen umgangen und die Integrität des Gastspeichers unterlaufen werden.
Auswirkungen in der Praxis: Von Attestationsmanipulation bis Code‑Injection
Die Manipulation der RMP in der Startphase eröffnet mehrere Angriffsvektoren: das Aktivieren versteckter Modi (z. B. Debug‑Funktionen), das Fälschen von Attestationsdaten, Replay‑Angriffe auf Speicherzustände sowie das Einschleusen fremden Codes. In mandantenfähigen Cloud‑Umgebungen kann dies zur Exfiltration sensibler Daten aus vertraulichen VMs führen – trotz aktivierter SEV‑SNP‑Isolation.
Bewertung, Betroffenheit und Patches im Ökosystem
AMD bewertet CVE‑2025‑0033 mit einem CVSS‑Basiswert von 5,9 (mittel), da in der Regel Hypervisor‑Privilegien erforderlich sind. Der Hersteller hat Firmware‑/Plattformupdates und CPU‑Microcode bereitgestellt, die das Zeitfenster der Race‑Condition schließen und die RMP‑Härtung verbessern. Diese Maßnahmen zielen darauf ab, die Initialisierungssequenz zu serialisieren und unautorisierte Schreibzugriffe zuverlässig zu verhindern.
Ökosystempartner bestätigen die Relevanz: Microsoft meldet Auswirkungen auf Azure Confidential Computing mit AMD‑Hosts und rollt Fixes aus; Supermicro weist auf notwendige BIOS‑Updates für betroffene Mainboards hin. AMD hat zudem eine Liste betroffener Prozessoren publiziert. Betreiber sollten die Vendor‑Dokumentation zur eigenen Plattform prüfen und zeitnah aktualisieren.
Risikoeinordnung und empfohlene Gegenmaßnahmen
Die praktische Ausnutzung setzt in der Regel Kontrolle über den Host oder einen böswilligen Hypervisor voraus. In Multi‑Tenant‑Szenarien mit strengem Trust‑Boundary zwischen Cloud‑Betreiber und Kunde ist das Risiko daher besonders relevant, obwohl der CVSS‑Wert „mittel“ lautet. Die Schwachstelle zeigt, dass Hilfsstrukturen wie die RMP genauso kritisch sind wie die Speicherverschlüsselung selbst.
Maßnahmen für Betreiber: BIOS/UEFI beim OEM aktualisieren, inklusive aktueller PSP/AGESA‑Pakete und Microcode; Hypervisor und VM‑Management‑Stack patchen, um Eingriffe während der frühen Initialisierung zu unterbinden.
Attestation stärken: Richtlinien für gemessenen Start konsequent prüfen, Attestationsprotokolle erfassen und auf Anomalien (z. B. unerwartete RMP‑Attribute) überwachen; Ergebnisse automatisiert verifizieren.
Berechtigungen minimieren: Host‑Zugriffe strikt nach Least Privilege vergeben, sensible Workloads segmentieren und Administrationspfade trennen; in Cloud‑Setups „Host‑Bypass“‑Risiken in der Threat‑Modellierung berücksichtigen.
Vulnerability‑Management etablieren: Inventarisierung, Priorisierung von CVE, regelmäßige Wartungsfenster und Compliance‑Checks automatisieren; Rollback‑Pläne und Attestations‑Re‑Baselining nach Updates einplanen.
Unternehmen sollten die von AMD und den Hardware‑Partnern bereitgestellten Updates umgehend anwenden, Bedrohungsmodelle für SEV‑SNP‑Workloads aktualisieren und die Attestation‑Pipelines verschärfen. Je schneller das Initialisierungsfenster geschlossen und überwacht wird, desto verlässlicher bleibt die Isolation vertraulicher VMs und der Schutz geschäftskritischer Daten.
