Twee nieuwe onderzoeksresultaten laten zien dat zelfs AMD SEV-SNP, bedoeld om een virtual machine (VM) af te schermen van de beheerder van de host, onder specifieke omstandigheden kan worden omzeild. De aanvallen heten Mior en Skyfall en draaien om het uitlezen of manipuleren van informatie binnen versleutelde VM’s.
Het belangrijke punt: de onderzoekers tonen dat dit niet zomaar lukt vanuit een gewone VM. In de praktijk is er (in wisselende mate) controle nodig over de hypervisor en de BIOS/UEFI van de server, plus aanvullende voorwaarden voor toegang tot bepaalde registers of geheugenstructuren.
Wat maakt AMD SEV-SNP interessant (en kwetsbaar in deze casussen)?
SEV-SNP is ontworpen voor confidential computing. Het systeem versleutelt geheugen en gebruikt hardware-afgedwongen toegangsregels, zodat een host/hypervisor niet zomaar bij de inhoud van een VM kan. In de ideale situatie blijft de operator van de server daarmee buiten beeld.
De onderzoekers richten zich echter op het begin van het opstartproces en op gevallen waarin de vertrouwensketen niet klopt. Ze benadrukken bovendien dat het om een scenario gaat dat past binnen het (door AMD gedefinieerde) dreigingsmodel waarbij de UEFI niet volledig wordt vertrouwd.
Attack 1: Mior — geheime data lezen én VM’s manipuleren
Mior gaat verder dan alleen uitlezen. Volgens de paper kan een aanvaller:
- gegevens binnen een SEV-SNP beschermde VM beïnvloeden;
- een deel van het opstartproces verstoren zodat de VM’s geheugenbeschermingen verkeerd worden ingevuld;
- een beveiligingsrapport (attestation) misleiden door de softwaremeting te faken.
De kern speelt tijdens de startup. Tijdens het opstarten vult een beveiligingscoprocessor op de chip een tabel die bijhoudt wie welke geheugenpagina bezit en wat die mag. De onderzoekers noemen dit de Reverse Map Table (RMP).
In hun lab-aanpak sturen ze writes van de beveiligingscoprocessor om naar het geheugen van een PCIe-apparaat (een grafische kaart) dat zij beheren, in plaats van naar het hoofdgeheugen. Hun gedachte daarachter is dat de coprocessor de waarden terug leest om te verifiëren. Door de timing en terugleeslogica blijft een deel van de echte RMP niet goed geïnitialiseerd.
Daarna kan de hypervisor de RMP-beschermingen aanpassen. Vervolgens zetten de onderzoekers debugging aan in een confidential VM waar debug eerder was uitgeschakeld, en gebruiken ze debugcommando’s van dezelfde security processor om geheugen te lezen en te schrijven. In de tests lukte dit in alle pogingen (1.000 keer in twee reeksen).
Attestation misleiden met SEV-SNP metingen
Naast geheugenmanipulatie richten de onderzoekers zich ook op de attestation. SEV-SNP meet de software-image wanneer de VM start en de platformsecurity processor tekent een rapport dat die meting bevat.
In de tweede test gebruiken ze een meting van een onschuldige VM en plaatsen die in een kwaadaardige VM. Daardoor beschrijven attestation-rapporten in hun scenario niet wat er daadwerkelijk draait, maar wat de aanvaller heeft laten lijken.
Benodigde voorwaarden voor Mior
De aanval vraagt om:
- controle over de hypervisor;
- controle over de BIOS/UEFI;
- een PCIe-apparaat (bijvoorbeeld een grafische kaart) om de omleiding van geheugenrouting mogelijk te maken.
De onderzoekers geven aan dat ze opereren binnen AMD’s dreigingsmodel, waarin AMD expliciet de UEFI wantrouwt. Verder stellen ze dat normale VM’s die de host en firmware al vertrouwen, met deze aanpak geen extra winst krijgen ten opzichte van bestaande trust-problemen.
Attack 2: Skyfall — datalekken via timing en cache-inhoud
Skyfall is een andere aanval met een andere insteek. De onderzoekers bouwen voort op Transient Scheduler Attacks (TSA), die op eerdere datum waren besproken als timinggerelateerde lekken in AMD-processors.
Hun bevinding: wanneer een hypervisor bewust probeert een VM te laten falen bij het opstarten, blijft er een deel van de opgeslagen toestand in cache achter. Dat restdeel wordt niet opgeruimd zoals je zou verwachten, waarna de hypervisor het kan uitlezen via TSA.
In een test haalden ze onder meer saved register values uit een VM en zelfs een disk-encryption key. Voor die key maakten ze het proces haalbaar door de kernel te laten pauzeren op het moment dat de sleutel in registers zat. In een “echtere” aanval is hun idee dat een techniek zoals SEV-Step kan helpen om het proces gericht te onderbreken.
Beperkt uitlezen: slechts specifieke cache-regels
Skyfall kan ook VM-geheugen aanboren, maar volgens de paper alleen binnen een heel beperkt bereik. Concreet gaat het om drie vaste “cache lines” in een doelpagina, met offsets rond 0x0c0, 0x380 en 0x3c0. Het grootste deel van die geheugenpagina blijft buiten bereik.
De onderzoekers testten op verschillende generaties: ze vonden geen lek op Zen 5-chips, maar wel op Zen 3 en Zen 4 (in hun testopstellingen).
Ook microcode en SMM: aanvullende datapunten
Verder rapporteerden de Skyfall-onderzoekers dat ze:
- gedeelde microcode-updates konden lezen (in gedecrypte vorm) op de testchips;
- registre-achtige waarden uit System Management Mode (SMM) geheugen konden terughalen.
Opvallend is dat SMM-geheugen doorgaans niet leesbaar is door de normale operating system kernel. Voor Skyfall blijft wel gelden dat de aanvaller privile ge software op de machine nodig heeft (bij dit type scenario dus: een kwaadwillende host/hypervisor-positie).
Welke CVE’s horen hierbij en hoe ernstig is het?
AMD koppelt de bevindingen aan twee advisories:
- Mior: CVE-2026-0462 met een CVSS 4.0-score van 5,9 (volgens de broncontext).
- Skyfall: CVE-2026-40671 met een CVSS 4.0-score van 4,9 (volgens de broncontext).
Daarnaast is er binnen de bredere Skyfall-context ook sprake van een SMM-gerelateerde classificatie: het EDK II project koppelt dit aan CVE-2026-18448, met een score van 5,6, en koppelt het aan ontbrekende TSA-mitigaties in firmwarecode.
De ernst is daarmee niet alleen “theoretisch”. Het scenario vereist wel een hoge mate van controle, maar in omgevingen waar die controle al aanwezig is (of waar beheer- en firmwarerechten niet goed gescheiden zijn), kan het de vertrouwelijkheid van confidential computing ondermijnen.
Updates en fixes: wat je nu praktisch moet doen
AMD geeft in de broncontext aan dat de firmware- en microcode-updates per onderdeel en per tijdstip verschillen. Belangrijk voor het praktische werk: de fixes zitten in host-firmware en microcode, waardoor klanten die confidential VMs huren vaak afhankelijk zijn van hun cloudprovider (of serverleverancier) om dit door te voeren.
Voor Mior noemt AMD in de broncontext alleen SEV-SNP als getroffen. Voor Skyfall gaat het om specifieke microcodefixes en mitigaties voor de betrokken chips.
De onderzoekers vermelden ook dat er geen duidelijke workaround is. In elk geval in hun advisories wordt geen alternatieve route genoemd om het risico te omzeilen zonder de aangewezen updates door te voeren.
BIOS/UEFI-aanpak via serverleveranciers
Omdat het gaat om platformfirmware, is de BIOS/UEFI-update meestal bij de servermaker te verkrijgen. Zo publiceerde Supermicro in de broncontext een BIOS-fixlijst voor meerdere H12/H13/H14 moederborden en geeft het aan dat ook BMC-firmwareupdates nodig kunnen zijn.
Voor organisaties die zelf de infrastructuur beheren, is dit dus geen “wacht op één patch”-vraag, maar een gecontroleerde updateflow: BIOS/UEFI, BMC (indien van toepassing) en bijbehorende microcode.
Waarom dit ook relevant is buiten “virtuele machines”
De scope beperkt zich niet tot VM’s in engere zin. Skyfall toont dat er ook informatie kan lekken uit microcode-updates en uit SMM-gerelateerde geheugengebieden, mits de aanvaller de juiste positie en voorwaarden heeft.
Daarom is dit onderwerp breder dan alleen VM-isolatie. Het gaat ook over de integriteit van firmware, mitigaties in EDK II, en het gedrag van het systeem tijdens mislukte startscenario’s.
Wat kun je vandaag doen om jezelf te beschermen?
Als je AMD SEV-SNP in productie gebruikt, richt je maatregelen op het reduceren van “rogue host”-risico’s:
- Controleer of updates beschikbaar en geïmplementeerd zijn voor de relevante platformfirmware en microcode van de getroffen CVE’s.
- Werk BIOS/UEFI en (waar relevant) BMC bij via de serverleverancier en verifieer dat die wijzigingen ook echt draaien.
- Versterk beheer-scheiding: beperk toegang tot hypervisor- en firmwareinstellingen tot alleen geautoriseerde rollen.
- Stem cloudverantwoordelijkheden af: als jij geen host-firmware beheert, vraag je provider expliciet naar de status van de SEV-SNP mitigaties.
Wil je breder leren over het “stoppen” van misbruik en containment wanneer er tekenen van compromittering zijn? Lees dan ook AI-agent stoppen: zo reageer je bij misbruik.
Extra context: wat eerdere RMP-gerelateerde issues laten zien
De broncontext noemt dat er eerder al aanvallen waren die de Reverse Map Table corrumpeerden bij SEV-SNP startup. Mior wordt daarbij als een aparte flaw gepositioneerd, zonder directe afhankelijkheid van die eerdere aanpak.
Als je meer wilt weten over de achtergrond van SEV-SNP en RMP-gerelateerde incidenten, bekijk dan gerelateerde samenvattingen in je eigen threat model-dossiers en houd ook algemene updates rond confidential computing bij. (Voor een algemene overzichtsblik op incidenten en hacks kan cybersecurity roundup: incidenten, hacks en fixes nuttig zijn.)
Conclusie
De publicatie van AMD SEV-SNP aanvallen met Mior en Skyfall laat zien dat confidential computing alleen zo sterk is als de volledige keten: firmware, hypervisor-integriteit en het gedrag tijdens opstart- en foutscenario’s. De aanvallen vereisen doorgaans uitzonderlijke privileges en specifieke condities, maar dat maakt het niet minder belangrijk voor teams die SEV-SNP gebruiken in omgevingen met strenge vertrouwelijkheidseisen.
De beste volgende stap is praktisch: breng de getroffen platformen in kaart, installeer de BIOS/UEFI- en microcode-updates volgens de advisories en verifieer dat de mitigaties actief zijn. Zo voorkom je dat een rogue host de bescherming van versleutelde VM’s kan omzeilen.
Bron: https://thehackernews.com/2026/11/new-mior-and-skyfall-attacks-let-rogue.html
