BALTIMORE / LONDON (IT BOLTWISE) – MIT-Forschende beschreiben die „Interrupt Injection“-Attacke, die zeitlich genau zwischen Sanitizing und Kernel-Nutzung eingreift. Dadurch kann ein Angreifer den Branch-Predictor nach Ausführung der Spectre-v2-Abwehr erneut „umtrainieren“. Die getesteten Werte reichen auf einem AMD-System bis zu 91,97% Genauigkeit, genug für das Auslesen von /etc/shadow. AMD kündigt einen Kernel-Patch an, während die Linux-Community bereits einen Commit zur Robustheit von Safe-RET nachliefert.

Unter dem Namen „INTERRUPT INJECTION“ hat ein Forscherteam um Daniël Trujillo und Mengjia Yan eine neue Klasse von Spectre-v2-Angriffen beschrieben, die nicht nur klassische Annahmen über den Kontrollfluss ausnutzt, sondern auch die Zeitschiene der Betriebssystemlogik. Der Kernpunkt ist banal und zugleich heikel: Viele Spectre-v2-Mitigationen säubern oder isolieren Branch-Predictor-Zustände in einem klar definierten Abschnitt des Codes. Sobald dieser Schritt „fertig“ ist, gehen die Mitigation-Designs jedoch stillschweigend davon aus, dass zwischen Sanitizing und tatsächlicher Nutzung kein untrusted Code dazwischenfunkt. Genau diese Lücke schließt Interrupt Injection, indem ein unprivilegiertes Linux-Programm einen Hardware-Interrupt so taktet, dass er in den Winz-Zeitbereich fällt, in dem der Prozessor gerade seinen Predictor bereinigt und die Kernel-Implementierung den „bereinigten“ Zustand anschließend wirklich verwendet.
Technisch zielt der Angriff auf den Spectre-v2-Mechanismus der spekulativen Ausführung über die Return-Stack-Struktur: Auf AMD-Systemen ist dafür die Safe-RET-Mitigation relevant. Safe-RET setzt vor jedem Kernel-Return darauf, dass der Rücksprungpfad nicht durch zuvor trainierte Zustände fehlgelenkt wird. Trujillo und Yan argumentieren jedoch über das Konzept TONTOU („Time-of-Neutralization to Time-of-Use“): Auch wenn Safe-RET den Predictor neutralisiert, gehört der Interrupt-Return-Pfad in den Verteidigungsbereich, sobald Interrupts zwischen Neutralization und Use eintreten. Dass Linux Interrupts mit sehr feiner Granularität zur Verfügung stellt und dass Handler- und Rückkehrpfade zeitlich unvorhersehbar in den Ablauf einschneiden können, macht diesen Race-Effekt möglich. Auf Zen 2 ist der relevante Zeitfensterbereich dabei extrem klein: Es entspricht nach Angaben der Forschenden zwei Instruktionen, also nur sechs Bytes.
Die Demonstration auf einem AMD Zen-2-System unter Linux 6.14 erfolgte ohne Privilegien, lediglich mit lokaler Code-Ausführung. In den berichteten Ergebnissen gelang es dem Angriff, Kernel-Speicher bei 5,47 Bytes pro Sekunde mit 91,97% Genauigkeit zu leaken. Der Output war nicht nur abstrakt: Die Forschenden geben an, dass dadurch das Lokalisieren und Auslesen von /etc/shadow möglich war, also dem Dateispeicher mit Passwort-Hashes, in fünf von zehn Versuchen. Die Erfolgsquote hängt dabei an Details, die im Paper beschrieben werden: Die Forschenden vergrößerten ihre Chancen, indem sie die fraglichen Bytes aus L1- und L2-Cache verdrängten, unter anderem durch eine passende Ausnutzung eines Sibling-Hyperthreads, und indem sie eine Write-syscall-Variante wählten, um Kontrolle über zwei Register zu erlangen. Die Interrupts trafen das kritische Zeitfenster danach in 5% bis 12% der Fälle; mit den beschriebenen Registerbedingungen lag die Rate laut Bericht bei rund 2%.
Nach dem erfolgreichen „Einschub“ wird die Interrupt-Handler-Ausführung selbst zum Training-Gadget. Das Team verbindet dabei die Interrupt-Injection-Primitive mit einer weiteren bekannten Schwachstelle aus dem Kontext der saferet-Verteidigung, die als Inception (CVE-2023-20569) bezeichnet wird: Dort füllt ein Angriffsweg die Return-Stack-Buffer-Strukturen mit einem attacker-chosen Ziel. In den Tests kam es auf drei der vier getesteten Maschinen zu Mispredictions in Kernel-Code. Die gemeldeten Erfolgsraten liegen bei 0,75% auf Zen 2, 0,22% auf Intel Arrow Lake und 0,037% auf Cascade Lake Refresh. Auf Zen 4 traten in diesem Test keine passenden Mispredictions auf; zudem gelang auf Intel-Seite kein end-to-end Leak in der beschriebenen Konfiguration, weil der Angreifer zusätzlich ein geeigneten Disclosure-Gadget im Kernel benötigt. Für das Team ist das dennoch kein prinzipielles Hindernis, sondern eher ein Hinweis auf die benötigte Kombination aus Primitiv und Gadget: Mispredictions seien „not sufficient“, und frühere Arbeiten zeigten bereits das Vorhandensein passender Disclosure-Gadgets im Kernel, sodass eine End-to-End-Attacke auf Intel durch Kombination möglich sei.
AMD reagierte laut Angaben in der Meldung mit einem Bulletin (AMD-SB-7061) und nennt „Safe RET Interrupt Vulnerability“ als Titel. Darin wird für Zen 1 bis Zen 4 ein mögliches Szenario beschrieben: Ein Angreifer mit Codeausführung auf einem betroffenen System könne einen Interrupt in einem präzisen Moment einschleusen, um Safe-RET zu stören; das könne die Schutzwirkung schwächen und zu Informationsoffenlegung führen. Der Text ordnet das Problem ausdrücklich der Linux-Implementierung von Safe-RET zu, nennt jedoch zunächst keinen konkreten Kernel-Commit und auch keine CVE. Gleichzeitig wird im Bulletin erwähnt, dass das Verhalten auf Zen 1 und Zen 2 demonstriert wurde, während Zen 3 und Zen 4 lediglich als plausibel adressiert, aber in der Demo nicht belegt wurden. Auf der Linux-Seite findet sich inzwischen ein konkreter Fix: Der Commit „x86/bugs: Make Safe-RET robust against interrupt injection“ ist datiert auf den 2. Juni und adressiert genau den von den Forschenden beschriebenen Pfad, indem der Registerzustand so zurechtgesetzt wird, als hätte die Safe-RET-Sequenz bereits vollständig durchlaufen. Zusätzlich wird das Ausführen einer RET-Instruction nach dem Interrupt-Return vermieden.
Auch Intel ordnet die Lage differenziert ein: In der Quelle heißt es, Intel sehe keine zwingende Mitigation, weil die praktische Exploitierbarkeit von mehreren Faktoren abhänge und die Technik bereits durch bestehende Guidance abgedeckt sei. Aus Sicht der Betriebssystempflege ist das allerdings nur der Auftakt zur eigentlichen Abwägung. Ohne CVE und ohne direkte Referenz auf den Kernel-Commit müssen Admins im Zweifel gezielt nach dem Commit-Subjekt suchen oder den SRSO-/Spec-Rstack-Overflow-Status unter „/sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow“ interpretieren. Interessant ist dabei, dass die Dokumentation zum betreffenden Status in dem Berichtskontext beim Abgleich keinen Hinweis auf Interrupt-Injection enthalten habe. Vor diesem Hintergrund verschiebt sich die Priorität für die Patch-Verifikation: Nicht nur „Vulnerability-Flag“ und Kernel-Version zählen, sondern ob die Safe-RET-Robustheit gegen Interrupt-Einschub tatsächlich implementiert ist.
Mit Blick auf die übergreifende Architektur verdeutlicht die Meldung, warum Spectre-v2-Abwehrstrategien schnell an ihre Annahmen gebunden sind. Intel setzt Sanitizing typischerweise bereits beim Kernel-Eintritt über eIBRS und ergänzt je nach CPU weitere Mechanismen wie das Zurücksetzen der Branch History Buffer oder ein passendes BHI_DIS_S-Steuerverhalten; AMD führt die entscheidende Komponente hingegen unmittelbar vor dem Kernel-Return aus. Alle Ansätze unterstellen damit denselben Grundsatz: Es darf kein feindlicher Code in den kritischen Bereich „hinein“ laufen. Interrupt Injection zeigt, dass Interrupt-Handling genau diesen Grundsatz brechen kann, weil Handler- und Rückkehrpfade Teil der gleichen Spekulativitäts- und Predictor-Wirkstrecke werden. Für Unternehmen bedeutet das, dass der Spectre-v2-Patch-Status künftig stärker als Zusammenspiel von CPU-Mikroarchitektur, Kernel-Implementierungsdetails und Timing-Effekten betrachtet werden muss – und dass „nur“ das Aktivieren von Standard-Mitigations nicht automatisch gleichbedeutend mit vollständiger Absicherung gegen neue Race-Varianten ist. Das Paper wird auf einer US-Security-Konferenz vorgestellt, die Veröffentlichung des Artefakt-Repositoriums war zum Stichtag noch nicht öffentlich.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!

- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Interrupt Injection: neue Spectre-v2-Schutzlücke bei Intel- und AMD-CPUs" für unsere Leser?


#Sophos
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Interrupt Injection: neue Spectre-v2-Schutzlücke bei Intel- und AMD-CPUs" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Interrupt Injection: neue Spectre-v2-Schutzlücke bei Intel- und AMD-CPUs« bei Google Deutschland suchen, bei Bing oder Google News!