Een nieuw soort timing-aanval op processors brengt Spectre v2-mitigaties onder druk. In onderzoek van MIT CSAIL staat interrupt injection Spectre v2 centraal: een techniek waarbij een niet-geprivilegieerde Linux-gebruiker een hardware-interrupt precies op het juiste moment triggert. Daardoor kan het “veilig maken” van branch prediction toch worden verstoord, nadat een verdedigingsmechanisme al heeft gedraaid.
Wat dit extra spannend maakt, is dat de aanval niet om root-rechten vraagt. Alleen lokale code-uitvoering is voldoende, waardoor gedeelde systemen met kwetsbare CPU’s een reëel risico vormen. De onderzoekers melden daarnaast dat de impact verschilt per platform: op AMD Zen 2 konden ze in hun opzet gericht kernelgeheugen uitlekken, terwijl end-to-end uitlek demonstraties op Intel lastiger bleken in hun tests.
Wat is interrupt injection Spectre v2?
De kern van de methode is het veranderen van de veronderstelling achter veel Spectre v2-mitigaties. Veel verdedigingen gaan ervan uit dat er tijdens een cruciaal stuk code geen vijandige activiteit tussendoor “in de weg kan lopen”. MIT CSAIL noemt dit fenomeen Time-of-Neutralization to Time-of-Use (TONTOU): de tijd tussen het neutraliseren van een toestand en het daadwerkelijk gebruiken ervan.
Bij software-races is het idee herkenbaar, maar hier komt het via hardware binnen. Interrupts kunnen op vrijwel elk moment afgaan, en Linux maakt het relatief toegankelijk om interruptmomenten te plannen. Als een interrupt precies afgaat tussen het “schoonmaken” van de branch predictor en het moment dat de kernel die predictor weer gebruikt, ontstaat er een venster waarin een aanvaller opnieuw kan beïnvloeden.
Waarom interrupts Spectre v2-mitigaties kunnen doorbreken
Spectre v2-mitigaties zijn gericht op het isoleren of sanitizen van de branch predictor. De onderzoekers beschrijven dat Intel- en AMD-aanpakken het branch prediction gedrag op specifieke momenten afschermen:
- Intel voert sanitization uit bij kernel entry en werkt dit in sommige gevallen bij met extra clearing of met controles zoals BHI_DIS_T op basis van CPU-kenmerken.
- AMD doet sanitization direct vóór kernel return via SafeRET.
Allemaal gaan ze ervan uit dat er geen vijandige code kan “tussendoor” tijdens die korte window. INTERRUPT INJECTION doorbreekt precies dat: het interrupt-pad wordt onderdeel van de verdedigingsketen, ook wanneer de mitigatie oorspronkelijk is ontworpen rond kernel entry of kernel return.
Op AMD Zen 2 is het window in de onderzoekersituatie extreem klein—ongeveer twee instructies (zes bytes). Toch is dat voldoende wanneer je het interrupt-timingproces tot op nagenoeg dezelfde schaal kunt pushen.
Onderzoeksresultaten op AMD Zen 2
In de beschreven opzet draaide de aanval op een AMD Zen 2-systeem met Linux 6.14, met standaard Spectre v2-mitigaties aan. In die omgeving konden de onderzoekers ongeveer 5,47 bytes per seconde lekken met 91,97% nauwkeurigheid. Dat is volgens de onderzoekers genoeg om in hun scenario /etc/shadow te lokaliseren en te lezen, waar password hashes worden opgeslagen.
Ze rapporteerden dat dit in vijf van tien pogingen lukte. Daarbij speelde mee dat ze de kansen verhoogden door cache-effecten te benutten (ze evicteden relevante bytes uit L1/L2 met behulp van een sibling hyperthread) en door een syscall te kiezen die meer controle gaf over registergebruik.
Hoe de aanval in de praktijk verloopt
Volgens het beschreven onderzoek werden interrupts met succes in het kritieke venster geraakt in een bereik van 5% tot 12%. Met een specifieke registerconfiguratie lag dat rond 2% in hun omstandigheden. Zodra een interrupt precies in die window landt, wordt de interrupt handler zelf een “training gadget” voor de branch predictor.
De onderzoekers beschrijven ook dat de handler vervolgens een return stack buffer voorbereidt richting een aanvallergekozen doel. Daarbij noemen ze Inception (CVE-2023-20569) als onderdeel van de keten: een AMD-kwetsbaarheid die SafeRET van oudsher helpt tegen te gaan, maar in combinatie met de nieuwe interrupt-injectie kan het mechanisme alsnog worden misbruikt.
Belangrijk: het onderzoek schetst dat mispredictions in kernelcode niet overal op dezelfde manier terugkomen. In hun test zagen ze mispredictions op drie van de vier machines die ze onderzochten, met verschillende success rates afhankelijk van de CPU-familie.
Intel: wel model, maar minder makkelijk aantoonbaar
In de paper en de context eromheen stellen de onderzoekers dat “misprediction” niet genoeg is om ook altijd tot een volledig end-to-end Spectre-uitlek te komen. Het blijft nodig dat er in de kernel geschikte disclosure gadgets bestaan. Die zitten er in veel kernels, zo blijkt uit eerder werk.
In hun concrete demonstraties lag het zwaartepunt op AMD, terwijl Intel minder direct een volledige uitlek liet zien binnen de testopstelling. Voor Intel noemden ze daarbij success rates als lager in de genoemde tests, en dat end-to-end uitlek op Intel extra eisen kent: een disclosure gadget moet beschikbaar én bruikbaar zijn binnen de kernelcode-route die de aanvaller kan activeren.
Tegelijk geloven de onderzoekers dat ook Intel-omgevingen aan te vallen zijn, bijvoorbeeld door interrupt injection Spectre v2 te combineren met eerder gedocumenteerde disclosure-gadget inzichten. Hun boodschap is dus niet “alleen AMD”, maar: de bouwstenen bestaan en de techniek kan breder toepasbaar zijn.
Wat zeggen AMD en Intel over mitigaties?
Na melding op 5 februari hebben de onderzoekers hun bevindingen gedeeld met AMD en Intel. Volgens de berichtgeving wil AMD een kernel patch voorbereiden. MIT meldt vervolgens dat er inmiddels een fix is geleverd die in een normale besturingssysteemupdate aankomt.
Daarbovenop publiceerde AMD op 6 augustus een bulletin met de titel AMD-SB-7061: “Safe RET Interrupt Vulnerability”. In dat bulletin staat dat aanvallers code op een getroffen systeem mogelijk kunnen gebruiken om een interrupt op een precies moment in te injecteren om Safe RET te verstoren. Daardoor kan de bescherming verzwakken en kan informatiedisclosure optreden. AMD koppelt dit bovendien aan de Linux-implementatie van Safe RET.
AMD noemt daarin CPU’s uit de Zen 1 tot en met Zen 4-families als beïnvloed, en baseert de demonstratie op Zen 1 en Zen 2. Zen 3 en Zen 4 worden genoemd als plausibel, maar zonder dezelfde aantoonbaarheid in hun testopzet. In het bulletin is de lijst met “Affected Products and Mitigation” opvallend: er staat vooral hardware-informatie, maar geen duidelijke patchversie, geen kernel commit en geen CVE.
Dat laatste bemoeilijkt voor beheerders de praktische check: zonder versienummers of commit-ID is het lastig om één-op-één vast te stellen of een specifieke machine al de door MIT gemelde fix bevat. The Hacker News controleerde daarnaast de SRSO-status via /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow, maar die documentatie vermeldde op het moment van controle geen interrupts.
Intel geeft volgens de bron aan dat zij geen specifieke mitigatie noodzakelijk achten. Ze stellen dat exploitabiliteit afhankelijk is van meerdere factoren, en dat de techniek onder bestaande richtlijnen valt. The Hacker News heeft die guidance (INTEL-SA-00598, laatst bijgewerkt in mei 2025) bekeken en vond daarin geen expliciete verwijzing naar interrupts.
Voorgestelde fix: tweede neutralisatie via interrupt-pad
De onderzoekers zien een oplossing die aansluit op het probleem zelf: zorg dat de branch predictor state niet alleen wordt geneutraliseerd op entry/return, maar ook op de weg uit het interruptpad. Concreet stellen ze voor om de return stack buffer “opnieuw” te vullen voordat iret plaatsvindt, of bij nieuwere Intel-onderdelen om daar een IBHF-operatie uit te voeren.
Een alternatief—interrupts blokkeren voor de extreem korte window—noemen ze, maar ze kwantificeren niet welke performance impact dat zou hebben. Dat maakt de haalbaarheid en het kiezen van een defensieve strategie afhankelijk van een afweging tussen security en throughput.
Waarom dit vooral impact heeft op gedeelde systemen
Een belangrijk verschil met klassieke processor-bugs is dat exploitbaarheid vaak samenhangt met privileges. In dit geval benadrukken de onderzoekers dat de aanval geen extra privileges vereist—en dus draait op het niveau van lokale code-uitvoering.
Daarom is de impact niet alleen theoretisch voor onderzoekers of security-labs. Op gedeelde omgevingen—waar meerdere klanten of workloads hetzelfde platform gebruiken—kan de drempel lager zijn wanneer een aanvaller lokaal code kan uitvoeren. Zelfs als de exacte uitkomst per CPU-familie verschilt, blijft het risico bestaan op systemen die binnen de getroffen categorieën vallen.
Wat kunt u nu doen?
Omdat de berichtgeving over patchnummers en CVE’s beperkt is, ligt de focus voor beheerders op het zo snel mogelijk toepassen van de updates die volgen uit de vendorcommunicatie en de normale OS-updatekanalen. In plaats van alleen naar één specifieke kwetsbaarheidsindicator te kijken, is het verstandiger om een bredere patch-strategie te hanteren voor Spectre v2-gerelateerde mitigaties.
Daarnaast helpt het om de status van uw mitigaties voor moderne speculatieve beveiliging te verifiëren en te controleren of updates betrekking hebben op de kwetsbaarheidscategorie die AMD beschrijft. Als u werkt met virtualisatie of containeromgevingen, bekijk ook waar uw workloads op CPU-pinning draaien, aangezien timing-gevoelige aanvallen praktische verschillen kunnen opleveren tussen hardwareconfiguraties.
Wilt u meer context over recente Spectre/Mitigation-risico’s en hoe die in de praktijk doorwerkt? Lees dan ook gerelateerde analyses binnen onze securitydekking, zoals onderzoeken rondom micro-architectuur en exploitketens.
Conclusie
Interrupt injection Spectre v2 laat zien dat beveiligingsmechanismen rond branch prediction niet alleen technisch juist moeten zijn, maar ook moeten rekenen op onverwachte timing van hardware-events. MIT CSAIL heeft aangetoond dat een lokale aanvaller via het interruptpad de neutralisatie-naar-gebruik-aanname kan doorbreken. Op AMD Zen 2 kon dat leiden tot het gericht uitlekken van kerneldata, inclusief /etc/shadow.
Voor Intel lijkt de end-to-end aantoonbaarheid in deze publicatie minder direct, maar de onderzoekers onderbouwen waarom een bredere exploit mogelijk blijft. AMD heeft inmiddels een bulletin gepubliceerd voor meerdere Zen-generaties, terwijl de praktische “is het al gepatcht?”-vraag nog lastiger is door het ontbreken van concrete patchdetails. Tot er volledige afbakening beschikbaar is, is het devies: update snel via gangbare OS- en vendorkanalen en beoordeel het risico vooral op gedeelde omgevingen.
Bron: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
