Een lezing op 39C3 heeft op indrukwekkende wijze laten zien dat CPU-kwetsbaarheden zoals Spectre nog steeds een zeer relevant gevaar vormen.
Speculatieve uitvoering als aanvalsvector
Aanvallen op kwetsbaarheden zoals Spectre domineren het security-onderzoek sinds begin 2018. Maar na de aanvankelijke grote opwinding in de IT-securitycommunity vragen velen zich vandaag de dag af of de voortdurend verschijnende nieuwe varianten nog praktische relevantie hebben of louter academische experimenten zijn.
Spectre is een architectonische kwetsbaarheid van moderne processors. Die beheersen speculatieve instructie-uitvoering, waarbij de CPU raadt welke instructie waarschijnlijk als volgende komt en ermee begint die uit te voeren voordat de instructiereeks vaststaat.
Dat dient voor prestatieoptimalisatie, maar kan worden misbruikt door aanvallen zoals Spectre: met code die een jump-voorspelling gericht manipuleert, zetten aanvallers de CPU ertoe aan om gevoelige gegevens uit beveiligde geheugengebieden tijdelijk te verwerken en via zijkanalen zoals de CPU-cache prijs te geven.
Bij scenario’s die lokale code-uitvoering vereisen, is er vaak al sprake van een kritieke compromittering, en is de daarop voortbouwende aanval niet zo relevant meer. Dergelijke aanvallen ontplooien hun volledige kracht echter in cloudomgevingen. Daar delen verschillende clients door virtualisatie dezelfde fysieke hardware.
In theorie garandeert virtualisatie een strikte scheiding van die workloads, maar in de praktijk hebben onderzoekers herhaaldelijk aangetoond dat de isolatie kan worden omzeild via cache-timing-sidechannels. Dat maakt het mogelijk om gevoelige informatie over VM-grenzen heen te extraheren uit eigenlijk geïsoleerde instanties.
De afgelopen jaren hebben security-onderzoekers talrijke van dergelijke kwetsbaarheden gevonden – meestal onder gecontroleerde laboratoriumomstandigheden.
Maar komen de noodzakelijke randvoorwaarden in de praktijk überhaupt samen? Moderne processorarchitecturen bieden immers slechts minimale externe interfaces en implementeren meestal meerlaagse beveiligingsmechanismen.
Bovendien hebben CPU-fabrikanten sinds de opkomst van dit type aanvallen vergaande hardware-mitigaties en microcode-updates geïmplementeerd om het probleem te bestrijden, en hebben ze dus de architectuur en het gedrag van hun chips zodanig aangepast dat aanvallers afgeremd worden.
Thijs Raymakers wijdde zich aan deze vraag tijdens het 39e Chaos Communication Congress (39C3) afgelopen december. Zijn lezing was gebaseerd op een onderzoekssamenwerking tussen de Vrije Universiteit Amsterdam en de Universiteit van Birmingham, waarin Raymakers samen met andere wetenschappers aantoonde hoe de combinatie van bekende en zogenaamd verholpen beveiligingslekken een succesvolle aanvalsketen mogelijk maakte.
De onderzoekers konden gevoelige gegevens uit de Google Cloud halen – een scenario met verstrekkende gevolgen.
Krachtige tegenmaatregelen zijn onrendabel
In cloudomgevingen draaien processen van verschillende gebruikers parallel op één en dezelfde hardware. Door Simultaneous Multithreading (SMT, ook bekend als HyperThreading) worden zelfs afzonderlijke fysieke CPU-kernen gedeelde bronnen.
Het probleem: optimalisaties die de efficiëntie van de hardware en daarmee de rendabiliteit voor cloudproviders verhogen, verminderen de veiligheid vaak. Volledig effectieve tegenmaatregelen vergen vaak een nieuw hardware-ontwerp.
Intel en AMD voeren voortdurend de nodige wijzigingen door, maar de onmiddellijke vervanging van complete processorgeneraties is voor individuele cloudproviders economisch meestal geen optie en voor alle betrokkenen niet haalbaar – al was het maar vanwege de beperkte productiecapaciteit voor nieuwe chips.
Daarom worden voornamelijk softwarematige maatregelen en microcode-updates toegepast, die de problemen vaak slechts kunnen verzachten. Zo wissen CPU’s als tegenmaatregel de Level 1-cache (L1d) bij een contextwisseling naar een volgend clientproces – een zogenaamde flush – zodat er geen gevoelige gegevensresten achterblijven.
Dat lost het probleem bij SMT echter niet op wanneer twee clientprocessen (het slachtoffer en de aanvaller) parallel op verschillende logische kernen binnen dezelfde fysieke kern opereren en de L1d-cache delen. Aangezien het volledig uitschakelen van SMT prestatieverlies van ongeveer 30 procent veroorzaakt, is dat voor cloudproviders economisch nauwelijks haalbaar.
In plaats daarvan maken ze gebruik van core-scheduling om te voorkomen dat twee verschillende contexten tegelijkertijd op dezelfde fysieke kern draaien. Een enkele context mag echter nog steeds alle logische kernen parallel gebruiken.
Tussen de contextwisselingen vindt ook daar een L1d-flush plaats. Zo hebben twee virtuele machines nooit tegelijkertijd en zonder voorafgaande opschoning toegang tot dezelfde cache.
Maar ook die maatregel lost het probleem helaas niet helemaal op. Er is namelijk nog een ander proces dat op de CPU-kernen wordt uitgevoerd en dat om prestatieredenen nauwelijks naar eigen kernen kan worden verbannen.
De aanval: een combinatie van oude bekenden
Dat proces is de hypervisor. Die fungeert als een softwarelaag die virtuele machines creëert, uitvoert en van elkaar isoleert door hun toegang tot CPU-, geheugen- en I/O-bronnen te controleren. De hypervisor bemiddelt tussen gastbesturingssystemen en de hardware en handhaaft daarbij de veiligheidsgaranties van virtualisatie.
Maar juist die instantie kan worden misbruikt om willekeurige gegevens uit het fysieke RAM-geheugen naar de cache te laden. De door Raymakers gepresenteerde aanval is gebaseerd op een combinatie van twee technieken en laat geen sporen na.
De eerste truc heet Half-Spectre, wat verwijst naar een techniek waarbij speculatieve instructie-uitvoering wordt gebruikt om gegevens buiten de beoogde geheugengrenzen te laden in microarchitecturale staten – doorgaans caches – zonder die direct te kunnen uitlezen.
In dat scenario maakt men gebruik van de speculatieve uitvoering binnen de programmastroom van de hypervisor om gegevens gericht uit het RAM-geheugen naar de L1d-cache te sluizen. Daarvoor communiceert de aanvaller in een gast-VM op slimme wijze met de hypervisor en zet die aan tot geheugenopvragingen.
Door passende inputs voor de hypervisor kan de jump-voorspellingseenheid van de CPU misleid worden. Vervolgens vindt tijdens de speculatieve uitvoering van de geheugenopvragingen een out-of-bounds-toegang plaats en worden gevoelige gegevens in de cache geladen.
De CPU herkent de voorspellingsfout en daardoor heeft de out-of-bounds-toegang geen direct effect – maar de reeds geladen gegevens blijven in de cache.
In tegenstelling tot bij de klassieke Spectre dient die stap alleen ter voorbereiding. De daadwerkelijke exfiltratie vindt plaats via de tweede kwetsbaarheid L1 Terminal Fault (L1TF), die wordt misbruikt door een tweede proces van de aanvaller dat parallel draait op de andere virtuele CPU van een fysieke kern met SMT (zie afbeelding).
L1TF is een bekend beveiligingslek dat Intel-processors tot en met de vroege modellen van de 9e generatie (Coffee Lake) treft. Latere modellen beschikken over hardware-mitigaties. L1TF maakt het mogelijk om gegevens via een timing-sidechannel rechtstreeks uit de L1d-cache te halen.
Ook AMD vertoont met TSA-L1 een zeer vergelijkbare kwetsbaarheid voor bepaalde processorgeneraties (2021–2024). Dergelijke hardware is nog steeds wijdverbreid in veel public cloud-omgevingen.
Recordbeloning voor Google Cloud
Die combinatie van kwetsbaarheden bleek uiterst effectief. De onderzoekers slaagden erin de aanval in verschillende cloudomgevingen te reproduceren en zo gericht gevoelige informatie te extraheren, zoals cryptografisch sleutelmateriaal of toegangsgegevens van VM’s van andere gebruikers.
Het team informeerde de betrokken providers in het kader van een Responsible Disclosure-proces. Google keerde voor die vondst een beloning uit van ruim 150.000 dollar – de hoogste bug-bounty die het bedrijf tot nu toe voor een cloudkwetsbaarheid heeft toegekend.
Bij AWS leidde de aanval door een afwijkende hypervisorarchitectuur slechts tot een gedeeltelijk succes. De gegevens van externe gast-instanties konden daar niet worden uitgelezen.
Andere, niet nader genoemde cloudproviders, waarbij de exploit eveneens werkte, toonden zich volgens de onderzoekers daarentegen aanzienlijk minder coöperatief dan Google.
Om het risico van dergelijke aanvallen te minimaliseren, stellen de onderzoekers twee maatregelen voor:
eXclusive Page Frame Ownership (XPFO). Dat mechanisme zorgt ervoor dat een fysiek geheugenframe op elk moment exclusief aan precies één context (zoals een VM of de hypervisor) toegewezen is. Dat voorkomt dat andere instanties de inhoud ervan kunnen observeren, noch via de reguliere programmastroom, noch via sidechannels.
Address Space Isolation (ASI). Daarbij gebruiken verschillende processen of domeinen strikt gescheiden virtuele adresruimten. Toegang tot geheugen buiten het eigen gebied wordt zo zowel hardwarematig als logisch verhinderd, wat het aanvalsoppervlak binnen de CPU enorm verkleint.
Beide technieken leiden echter tot merkbare prestatieverliezen, wat de implementatie ervan voor cloudproviders tot een economische afweging maakt.
Google heeft inmiddels gekozen voor de invoering van Address Space Isolation (ASI) om de cruciale scheiding tussen hypervisor en gastsystemen te versterken. AWS maakte al vóór de aanval gebruik van XPFO, wat de aanval zoals hierboven beschreven heeft beperkt.
Conclusie
Raymakers’ presentatie op 39C3 heeft de IT-securitycommunity opnieuw op een aantal centrale inzichten gewezen: het slim combineren van bekende kwetsbaarheden kan leiden tot nieuwe, verwoestende aanvallen die een hoge praktische relevantie hebben en via onverwachte wegen met elkaar verbonden worden – zoals in dit geval de hypervisor.
Beveiliging in cloudomgevingen moet fundamenteel vanuit de hardware benaderd worden. Oplossingen die puur op software zijn gebaseerd, zijn vaak slechts ontoereikende compromissen – met name gezien de daaruit voortvloeiende prestatieverliezen.
Daar staan de economische belangen van de cloudproviders onvermijdelijk in conflict met de best mogelijke gegevensbeveiliging.
Aanvallen van het type Spectre zijn ook in 2026 nog zeer relevant en moeten absoluut een onderdeel blijven van actief white-hat-onderzoek. Alleen zo kunnen gecombineerde aanvalsmogelijkheden vroegtijdig worden geïdentificeerd en verholpen. Aangezien dergelijke sidechannel-aanvallen geen sporen achterlaten in logbestanden, kunnen ze volledig onopgemerkt plaatsvinden – wat ze tot een gevaarlijke bedreiging voor moderne infrastructuren maakt.
Praat mee