Onderzoekers hebben een nieuwe hardwareaanval onthuld, de DDRop aanval, die de bescherming van confidential computing bij Intel en AMD kan ondermijnen. Het opvallende is dat de encryptie intact lijkt, maar dat het systeem “vertraagde” of oude geheugeninformatie toch als actueel blijft lezen.
Vooral in cloudomgevingen die TDX, Scalable SGX of SEV-SNP inzetten om workloads te beveiligen tegen nieuwsgierige partijen, vormt dit een belangrijke waarschuwing: het probleem zit niet in de softwarelaag, maar in de onderliggende hardware-aanname rondom geheugenen integriteit.
Wat is de DDRop aanval precies?
DDRop richt zich op het geheugenbeschermingsmechanisme van confidential computing. De kern van de methode is dat writes naar het servergeheugen stil worden weggelaten terwijl het systeem denkt dat de update wel is doorgevoerd.
Daardoor blijft er een eerder opgeslagen waarde achter in het geheugen. Vervolgens leest de processor opnieuw die oude waarde terug en behandelt die alsof hij net is bijgewerkt. Omdat de geheugenversleuteling nog steeds werkt, valt er aan de encryptielaag niets te “zien” dat op sabotage wijst.
Waarom werkt confidential computing zonder ‘freshness’?
Confidential computing houdt geheugengebieden versleuteld, zodat gegevens tijdens gebruik niet zichtbaar worden voor partijen met fysieke toegang. In de onderliggende designs zit echter een extra eigenschap die niet altijd wordt gegarandeerd: freshness.
De processor kan wél verifiëren dat de inhoud versleuteld is, maar niet dat het geheugen echt de nieuwste geschreven waarde bevat. Als oude versleutelde data nog steeds correct decodeert, dan kan een aanvaller misbruik maken van het verschil tussen “versleuteld” en “actueel”.
De rol van de interposer: goedkoop maar ingrijpend
DDRop vereist een aanvaller die al controle heeft over de serversoftware en bovendien kort toegang tot de machine kan krijgen. Tijdens die korte toegang plaatst de aanvaller een klein hardwarecomponent tussen de processor en het geheugen: een interposer.
De onderzoekers beschrijven dat een interposer voor relatief lage kosten kan worden gebouwd. De interposer werkt als een schakelbordje op de geheugenbus en kan op volle DDR5-snelheid functioneren.
Hoe zorgt DDRop ervoor dat de write verdwijnt? Door het systeem te laten falen op het commandpad: het ontwerp forceert een fout op de command bus en verbreekt vervolgens de lijn waarlangs het geheugenknooppunt normaal rapporteert dat er een error is. Het geheugenmodule verwerkt de opdracht dan stil, waardoor de processor nooit krijgt dat de write niet is uitgevoerd.
Welke technologieën worden geraakt?
De DDRop aanval richt zich op de geheugenencryptie en integriteitsafspraken in verschillende confidential-computing varianten. Volgens de onderzoekers werkt DDRop tegen:
- Intel TDX
- Intel Scalable SGX
- AMD SEV-SNP
Deze technologieën worden door grote cloudproviders ingezet om klantdata privé te houden terwijl die in gebruik is—dus ook tegen de cloudprovider zelf.
Er zijn wel uitzonderingen. De onderzoekers noemen dat Intel Client SGX niet wordt geraakt, omdat dat ontwerp een hardware integrity tree gebruikt die stale data kan betrappen. Intel heeft Client SGX daarnaast al geretireerd.
Ook wordt genoemd dat NVIDIA’s confidential-computing GPU’s buiten bereik zijn, omdat het geheugen in het chippakket zit waar geen interposer tussen kan worden geplaatst. Voor Arm CCA is het nog niet getest; de onderzoekers verwachten dat het mogelijk ook kan gelden, maar geven geen bewijs.
DDRop op Intel TDX: van write-dropping naar (gerichte) controle
Voor Intel TDX is de impact volgens het onderzoek verdergaand: de onderzoekers vertalen write-dropping naar feitelijke controle over aspecten van een beschermde virtuele machine.
TDX houdt onder meer pagina-tabellen versleuteld en onder controle van trusted firmware. DDRop kan daarbij helpen door writes te laten verdwijnen die de firmware gebruikt bij het opzetten van paginatabellen. Als bepaalde entries niet aankomen, blijft er data achter die is gekozen door de aanvaller.
Met die situatie kunnen aanvallers geheugenpagina’s mappen en vervolgens beschermde geheugensegmenten uitlezen of aanpassen via hun eigen gecontroleerde virtuele machine. In de demonstraties konden onderzoekers zo privégeheugen lezen en een slachtoffer VM daarna terugzetten, zodat er weinig aanwijzingen van tampering zichtbaar zouden zijn.
Debugmodus en attestation: waarom ‘vertrouwen’ kan worden vervalst
De onderzoekers beschrijven ook aanvallen op onderdelen die bedoeld zijn om vertrouwen te onderbouwen, zoals debugmodus en metingen voor remote attestation.
Door specifieke stappen (die volgens de paper demonstraties onder de default manier van TDX betroffen) konden ze een systeem in debug-mode zetten. Vervolgens konden ze geheugen in plaintext kopiëren en daarna de originele data herstellen, zodat het slachtoffer bij observatie “terug” lijkt te zijn naar een ongewijzigde staat.
Daarnaast konden ze launch measurement wijzigen die een VM gebruikt om aan een externe partij te laten zien dat hij in een bekend, vertrouwd beginstatus is gestart. Met een aangepaste meting zou een VM onder controle van de aanvaller de check kunnen doorstaan.
Wat is het verschil met de strengere cryptographic integrity-modus?
TDX kent naast een default modus een optionele strengere variant: cryptographic integrity. Volgens de onderzoekers zou die modus een deel van de beschreven aanvallen blokkeren, omdat ze gaan over het veranderen van data die niet van de aanvaller is.
Toch geven de onderzoekers aan dat het vervalsen van attestation niet per se wordt tegengehouden door cryptographic integrity, omdat die write binnen de aanvalsvriendelijke context gebeurt. Bovendien bevat cryptographic integrity volgens hen niet automatisch een echte freshness-check; daardoor kan het systeem mogelijk niet detecteren dat “oude” inhoud opnieuw is gebruikt.
In hun testopstelling was cryptographic integrity niet ondersteund, waardoor ze niet konden bevestigen hoe alles precies uitpakt.
Geen eenvoudige patch: waarom het probleem hardware-gedreven is
Een belangrijke boodschap uit het onderzoek: er is geen simpele patch die dit probleem direct wegneemt. De reden is dat de zwakte in het hardware-ontwerp zit.
De onderliggende geheugen-encryptie biedt bescherming tegen veel vormen van uitlezen, maar laat in ruil voor schaalbaarheid een eigenschap vallen: freshness. DDRop maakt precies dat gat bruikbaar.
Softwareaanpassingen kunnen de aanval niet volledig uitsluiten, maar wél de drempel verhogen. De onderzoekers noemen daarbij maatregelen zoals:
- het beperken van de geheugenmanagementfuncties die misbruikt kunnen worden
- controleren of belangrijke writes daadwerkelijk zijn geland
- nagaan of er tijdens het opstarten een interposer aanwezig is
Het blijft echter een lastige situatie omdat het om een fysiek hardwarecomponent gaat die met toegang tot de server kan worden geplaatst.
Responsible disclosure en wat Intel/AMD aangeven
Volgens de onderzoekers is er coordinated disclosure uitgevoerd: Intel en AMD zijn vooraf geïnformeerd. Beiden erkennen de bevindingen volgens het artikel, maar zouden geen concrete mitigeringsrichtlijnen of tijdschema hebben gedeeld.
AMD stelt dat de aanval een fysieke access-randvoorwaarde heeft en daarom buiten het gepubliceerde threat model voor SEV/SNP valt. Intel hanteert een vergelijkbare lijn voor fysieke interposer-aanvallen tegen servergeheugen.
Intel geeft daarnaast aan dat zulke aanvallen “out of scope” vallen voor de bescherming van geheugen-encryptie, en het bedrijf plant geen CVE voor dit soort fysieke scenario’s. Tegelijkertijd werkt Intel aan sterkere ontwerpen voor toekomstige chips, zoals voorstellen voor freshness checks op het geheugenbusniveau.
Wat betekent dit voor cloudgebruikers?
De DDRop aanval is vooral relevant voor cloudservers, niet voor consumentenapparaten. Dat komt doordat confidential computing daar in de kern draait om datacenters en gespecialiseerde CPU- en geheugenfuncties.
In de praktijk is de vraag voor organisaties: hoe zorg je dat je de voorwaarden verkleint waaronder een aanvaller deze aanpak kan proberen? Omdat DDRop een interposer vereist en dus fysiek ingrijpen mogelijk maakt, draait het vooral om risicobeheersing rondom toegang tot infrastructuur.
Concreet is het verstandig om:
- te controleren of jouw cloudconfiguratie sterke integriteitsmodi gebruikt waar dat kan
- te kijken naar extra checks rondom attestation en VM-startvalidatie
- processen en controles rondom toegang tot datacenterhardware te versterken
- te blijven monitoren op aanwijzingen van fysieke tampering volgens je eigen threat model
Als je breder wilt kijken naar hoe je exposure en zwaktes in omgevingen valideert (bijvoorbeeld na signalen of auditbevindingen), kan dit artikel je helpen: Exposure-issues valideren met AI: zo kies je actie.
Updatebeleid en ‘verifieer eerst’-gedachte
Hoewel DDRop geen simpele patch heeft, is het wel een wake-up call over hoe belangrijk “bewijs van actualiteit” is in beveiligingsontwerpen. Encryptie alleen is niet altijd genoeg; je wilt ook weten of de data overeenkomt met de laatste uitvoering.
Dat principe sluit aan bij een bredere beveiligingsaanpak: behandel beveiliging als een keten. Als één schakel (zoals freshness) ontbreekt, kan een aanvaller manieren vinden om de rest van het model te laten lijken alsof alles normaal werkt.
Wil je ook voorbeelden zien van security-impact die snel kan escaleren door kwetsbaarheden of misbruik in de supply chain? Lees dan bijvoorbeeld: JFrog Artifactory backdoors via 3 kwetsbaarheden.
Conclusie
De DDRop aanval laat zien dat confidential computing—ondanks sterke versleuteling—kwetsbaar kan zijn als een ontwerp geen freshness-garantie biedt. Door writes naar geheugen stil weg te laten vallen, kan oude versleutelde data als actueel worden gelezen, zonder dat de encryptie-engine automatisch een alarm geeft.
Er is geen eenvoudige patch, omdat de kernhardware betreft. Wat wél helpt, is een combinatie van strengere configuraties, aanvullende controlemechanismen en het verkleinen van de kans op fysieke of supply-chain gerelateerde toegang. Voor cloudgebruikers is dit vooral een signaal om security niet alleen te beoordelen op “encryptie aan”, maar op echte integriteits- en actualiteitszekerheid.
Bron: https://thehackernews.com/2026/09/new-ddrop-attack-breaks-intel-tdx-and.html
