Onderzoekers waarschuwen voor een nieuwe variant binnen de Spectre v2-familie. Deze aanval heet Spectre v2 BTR (Branch Target Reuse) en richt zich op hoe moderne CPU’s omgaan met code die tijdens runtime wordt aangepast, bijvoorbeeld door just-in-time (JIT) compilers. Dat maakt niet alleen servers en besturingssystemen interessant, maar ook webbrowsers en runtimes waar code dynamisch wordt vertaald.
Het onderzoek is uitgevoerd door onderzoekers van de Vrije Universiteit Amsterdam (VUSec) en Scuola Superiore Sant’Anna in Italië. Zij laten zien hoe een aanvaller die code op een doelmachine kan uitvoeren gevoelige informatie uit het geheugen kan afleiden, waaronder wachtwoordhashes.
Waarom Spectre v2 BTR anders werkt
Bij Spectre v2 draait het om misbruik van speculatieve uitvoering. Wat BTR toevoegt, is een specifieker inzicht in het gedrag van de processor bij zelfaanpassende code. Volgens de onderzoekers herstellen CPU’s wel de architectural code coherence wanneer code wordt aangepast, maar ze hoeven daarbij niet automatisch ook oude voorspellingen voor indirecte branches te wissen.
In de praktijk betekent dat: de processor kan “stale” branch target entries blijven gebruiken nadat de code waarvoor ze bedoeld waren al is vervangen. Wanneer later weer nieuw codefragment op hetzelfde geheugen terechtkomt, kan die oude voorspelling opnieuw worden ingezet. De aanval wordt daarmee een vorm van een speculative execute-after-free-achtige primitief, waarbij speculatieve execution kan worden gestuurd naar obsolete offsets in het nieuwe stuk code.
Effect op Intel, AMD en Arm
Het belangrijkste punt voor organisaties is dat de onderliggende gedragspatronen niet beperkt blijven tot één chipset. De onderzoekers bevestigen het onderliggende principe op systemen met Intel-, AMD- en Arm-processors. Daarmee is Spectre v2 BTR relevant voor een breed spectrum aan omgevingen: van x86-machines tot Arm-gebaseerde platformen.
Dat neemt niet weg dat mitigaties en haalbaarheid per omgeving kunnen verschillen. Wel is het signaal duidelijk: als je systemen JIT-gedreven code uitvoeren, kan je threat model veranderen.
Linux blijkt kwetsbaar: BTR in de kernel
Voor Linux laten de onderzoekers twee end-to-end exploits zien die data kunnen lekken uit het geheugen. Hun aanpak maakt gebruik van classic BPF (cBPF), niet van de (meer capabele) eBPF JIT. Dat is belangrijk, omdat toegang tot eBPF JIT typisch beperkt is tot bevoorrechte gebruikers, terwijl cBPF ook door niet-bevoorrechte programma’s kan worden benut.
In moderne deployments spelen cBPF en BPF-achtige filtering ook mee in componenten waar je als organisatie juist op vertrouwd: think aan seccomp, socket filtering en packet filtering in tools zoals Docker en Chrome. Met andere woorden: ook in omgevingen waar je denkt “we draaien wel met security-instellingen”, kan de kwetsbaarheid via het verkeerde pad alsnog misbruikt worden.
Op moderne Intel CPU’s kan de exploit naar zeggen van de onderzoekers arbitraire geheugeninhoud uitlezen en bovendien alle ingeschakelde mitigaties omzeilen. In een demo gebruikten ze de aanval om een root password hash te vinden en te lekken zodra die in het geheugen was geladen.
De snelheid is niet indrukwekkend op het eerste gezicht: de exploit lekt ongeveer 8 bytes per seconde. Toch kan dat voldoende zijn om kleine hoeveelheden data te verzamelen waarmee je uiteindelijk de benodigde geheime waarde kunt reconstrueren, mits je slim zoekt en pointer-chasing toepast.
Browsers en sandboxed runtimes: wat al kan en wat nog niet
Naast kernels kijken de onderzoekers ook naar browser- en runtimeomgevingen. In Firefox verwachtten ze dat de aanval kan worden gestart vanaf een malicious website die JavaScript uitvoert in de browser. Cruciaal hierbij is de status van site isolation: als content uit verschillende tabs (nog) adresruimte deelt, kan een aanvaller mogelijk data in die gedeelde context benaderen.
Hun proof-of-concept laat zien dat verouderde branch entries in SpiderMonkey op Intel-platformen lang genoeg blijven bestaan om later te worden hergebruikt. Ze schatten dat een datalek in de orde van tientallen bytes per seconde kan liggen, maar geven ook aan dat er nog werk nodig is om een volledige browserexploit te bouwen.
GraalVM (Oracle) komt eveneens aan bod. De onderzoekers verwachten dat BTR een aanvaller speculatief kan laten overslaan van masking die sandboxbescherming biedt. In hun experiment konden ze geheugenadressen betrouwbaar hergebruiken, maar de eigen codecompilatie en garbage collection van GraalVM wissten de verouderde branch entries vóór misbruik. Dat zou volgens hen “niet fundamenteel” zijn: met andere omstandigheden of technieken kan het alsnog beter werken.
Mitigaties: waarom fixes vooral in software liggen
De boodschap van het onderzoek is deels geruststellend: CPU- en softwareleveranciers erkennen de resultaten en wijzen op bestaande en toe te passen mitigaties. Toch is de kern dat er geen hardwaremechanisme is dat branch prediction entries gegarandeerd synchroon houdt met de code die echt in geheugen staat.
In de praktijk betekent dat: tot vendors een passend mechanisme toevoegen, blijft er een klas risico’s bestaan. De onderzoekers formuleren het scherp: zolang de CPU geen manier heeft om voorspelling en code exact op elkaar te laten aansluiten, is de processor volgens hen kwetsbaar voor de beschreven raceconditie.
Linux-mitigatie via IBPB-trigger
Voor Linux is er al een x86-mitigatie geïntroduceerd die een Indirect Branch Prediction Barrier (IBPB) triggert op elke CPU-core zodra een cBPF-programma in een geheugenregio wordt geladen die eerder gebruikt is voor eerder uitgevoerde BPF-code. Door die barrier te activeren, wordt de kans kleiner dat stale indirect branch prediction entries bruikbaar blijven.
IBPB en site isolation in browsers
CPU-vendors wijzen in hun reactie onder meer op IBPB als bestaande mitigatie voor Spectre v2. Tegelijk zien we dat in browserland niet alleen IBPB telt: Mozilla zet vooral in op het afronden van site isolation. Daarmee wil men voorkomen dat content over tabs heen dezelfde adresruimte kan delen, wat de kans op succesvol misbruik vanuit een kwaadwillende website verkleint.
Onderzoekers bespreken daarnaast hardware control-flow protections, zoals x86’s IBT en Arm’s BTI. Deze maatregelen maken exploitation moeilijker, maar nemen de dreiging niet volledig weg. Op oudere Intel-generaties kan speculatieve uitvoering voorafgaan aan de check, waardoor een race kan ontstaan. Ze noemen ook dat de onderzoekers geen raceconditie vonden vanaf de vroege Intel-generatie “Lion Cove”.
Wat betekent dit voor organisaties?
De praktische vraag is natuurlijk: wat doe je morgen met Spectre v2 BTR in je omgeving? Het onderzoek zelf geeft vooral richting via getroffen software en mitigaties, maar je kunt als organisatie een aantal logische stappen nemen.
1) Inventariseer JIT- en runtimegebruik
JIT-compilers spelen een centrale rol in het aanvalsidee. Denk aan omgevingen waarin kernels, browsers of applicatieruntimes dynamisch code vertalen of optimaliseren. Dat geldt voor ontwikkelplatformen, platforms met embedded browsers en voor software die zware script- of bytecode-uitvoering doet.
2) Zorg dat relevante patches en kernelupdates op tijd binnen zijn
Voor Linux wijzen de onderzoekers expliciet naar een IBPB-achtige x86-mitigatie rondom cBPF-geheugenregio’s. Als je kernels en systemen niet actueel houdt, vergroot je de kans dat je nog in een kwetsbare configuratie draait.
3) Herzie security-instellingen rondom sandboxing en isolatie
In browsers speelt site isolation een rol. In runtimes kan gedrag rond codecompilatie en garbage collection juist bepalen of stale predictions herbruikbaar blijven. Daarom helpt het om niet alleen “security aan” te denken, maar ook te controleren of isolatiecomponenten echt volledig zijn uitgerold.
Wil je breder kijken naar hoe moderne CPU- en OS-mitigaties in de praktijk worden toegepast, dan is het ook nuttig om ontwikkelingen rond Spectre v2 in Linux te volgen. Op onze site lees je bijvoorbeeld over een verwante context waarin Spectre-achtige effecten aan het licht komen: Spectre v2 BTR: aanval lekt geheugen via Linux JIT.
Gerelateerde dreigingen: waarom dit past in de grotere trend
Spectre v2 BTR laat zien dat moderne beveiliging niet alleen draait om bekende bugs in applicaties. Ook microarchitectuurgedrag en optimalisaties op CPU-niveau kunnen een ingang vormen. In die zin sluit het onderzoek aan bij een bredere beweging waarin aanvallers steeds vaker zoeken naar “grensgevallen” tussen code en machinegedrag.
Als je binnen je organisatie kijkt naar het totaalplaatje van aanvallen op runtime- en authenticatielagen (bijvoorbeeld via misbruik van agentic tooling of gestolen credentials), dan is het interessant om ook de governance- en zichtbaarheidkant mee te nemen. Daarbij passen bijvoorbeeld stukken over Zero Trust voor AI-agents, waar het idee centraal staat dat je minder vertrouwen geeft aan wat er “lokaal” draait en meer stuurt op detectie en beperking van impact.
Conclusie
Spectre v2 BTR is een serieuze variant binnen Spectre v2 die zich richt op JIT-gedreven code en de herbruikbaarheid van verouderde indirect branch predictions. Onderzoekers tonen aan dat aanvallen gevoelige data uit het geheugen kunnen lekken op platforms met Intel, AMD en Arm, met concrete exploitvoorbeelden voor Linux en proof-of-concepts voor browser- en runtimecontexten.
De verdediging zit vooral in softwaremitigaties zoals IBPB-triggers en het verder uitrollen van site isolation. Tegelijk is er geen universele hardwareschakelaar die het probleem automatisch “uit” zet. Voor organisaties betekent dit: houd systemen up-to-date, inventariseer JIT- en runtimegebruik en bevestig dat isolatie- en mitigatiepaden daadwerkelijk actief zijn.
Bron: https://www.securityweek.com/new-spectre-v2-variant-exposes-intel-amd-arm-cpus-to-data-leaks/
