Neue Forschung aus dem Umfeld von MIT CSAIL zeigt, dass Spectre-v2-Schutzmaßnahmen unter bestimmten Bedingungen doch nicht ausreichen können. Das zentrale Stichwort lautet Interrupt Injection: Ein Angreifer mit lokalem Code kann einen Hardware-Interrupt so timen, dass er in das enge Zeitfenster fällt, in dem der Prozessor seine Branch-Predictor-Daten neutralisiert und die Kernel-Nutzung unmittelbar danach erfolgt. Dadurch kann der Angreifer den Zustand des Predictors erneut „neu beimpfen“ – nachdem die Schutzroutine bereits gelaufen ist.
Das Thema ist vor allem deshalb brisant, weil der Angriff ohne Privilegien auskommt. Damit verschiebt sich das Risiko insbesondere auf gemeinsam genutzte Systeme, auf denen ein Nutzer Programme ausführen kann, die den benötigten Timing-Trick realisieren. In den Ergebnissen der Forschenden geht es um Informationslecks aus dem Kernel – unter bestimmten Konfigurationen mit messbaren Erfolgsraten.
Was ist „Interrupt Injection“?
Die Technik nutzt eine grundlegende Annahme vieler Spectre-v2-Abwehrmechanismen: Zwischen der Phase der Neutralisierung des Branch-Predictors und der eigentlichen Nutzung sollen keine fremden Aktivitäten laufen. Für klassische Software-Engpässe spricht man von Time-of-Check-to-Time-of-Use-ähnlichen Rennen (TOCTOU), hier nur in anderer Form.
Interrupts durchbrechen genau diese Erwartung. Sie können praktisch jederzeit ausgelöst werden und Linux erlaubt es Benutzern, sie mit sehr feiner Granularität zu planen. Dadurch wird der Interrupt-Pfad selbst zu einem Teil des Verteidigungsablaufs: Er kann die „Gültigkeit“ der zuvor neutralisierten Daten untergraben, sobald die Abwehr nicht auch die Rückkehr aus dem Interrupt vollständig neu absichert.
Warum Spectre-v2-Abwehrmechanismen ins Leere laufen können
Alle gängigen Verteidigungen zielen darauf ab, den Branch-Predictor so zu bereinigen oder zu isolieren, dass frühere Trainingsdaten eines Angreifers keine Sprungziele in Kernelcode steuern können. Laut der Analyse implementieren verschiedene Plattformen das an unterschiedlichen Stellen.
- Intel führt die Bereinigung beim Kernel-Einstieg durch. Je nach Prozessor können dafür eIBRS genutzt werden sowie zusätzliche Maßnahmen wie das Leeren relevanter Buffer oder Kontrollen wie BHI_DIS_D.
- AMD setzt die Bereinigung direkt vor jeder Kernel-Rückkehr ein, über saferet.
Der Knackpunkt: Wenn ein Interrupt zwischen Neutralisierung und Verwendung kommt, reicht diese „einmalige“ Absicherung nicht mehr. Selbst wenn die Abwehr beim Entry oder beim Return geplant war, kann der Interrupt dazwischen den relevanten Zustand wieder in eine angriffstaugliche Form bringen.
Angriffsszenario unter Linux: lokal, unprivilegiert, präzise getimt
Die Forschenden benennen die Klasse des Problems als TONTOU, also Time-of-Neutralization-to-Time-of-Use. Auf einer AMD Zen-2-Maschine unter Linux 6.14 mit aktivierten Spectre-v2-Mitigationen gelang es ihnen, Kernelinformationen auszulesen.
Die gemessenen Ergebnisse auf dieser Testumgebung waren eindrucksvoll: Es gab ein Leakage-Tempo von 5,47 Bytes pro Sekunde bei 91,97% Genauigkeit. Damit konnten die Forschenden in fünf von zehn Versuchen die Datei /etc/shadow finden und auslesen, in der die Kennworthashes eines Systems liegen.
Wichtig ist dabei: Für den Angriff wurden keine erhöhten Rechte benötigt. Er setzt lediglich lokalen Code-Ausführungszugriff voraus. Genau deshalb spielt die Frage nach dem Schutz auf Systemen mit mehreren Nutzern eine große Rolle.
Wie gelingt die präzise Platzierung des Interrupts?
Auf Zen 2 ist das relevante Zeitfenster extrem klein. Laut Beschreibung der Forschenden handelt es sich dort um zwei Instruktionen, nur sechs Bytes. Genau in diesen Bereich muss der Interrupt „landen“, damit der Branch-Predictor nach der Neutralisierung wieder vom Angreifer profitieren kann.
Um die Erfolgswahrscheinlichkeit zu erhöhen, erweiterten die Forschenden ihre Chancen auf mehreren Ebenen:
- Sie evicteten die betreffenden Bytebereiche aus L1 und L2 Cache. Dafür nutzten sie einen Sibling-Thread (Hyperthreading), um die Zeitsteuerung zu verlangsamen und stabiler zu machen.
- Sie wählten zudem den passenden Systemcall (write), sodass der Angreifer Kontrolle über zwei Register behielt.
Die Interrupts trafen in einem Bereich von etwa 5% bis 12% der Fälle in das Zielintervall. Unter den Bedingungen mit Angreifer-kontrollierten Registern lag der Wert näher an rund 2%. Sobald der Interrupt im Fenster landete, wurde der Interrupt-Handler selbst zum „Training-Gadget“.
Inception als Baustein: Return Stack Buffer gezielt füllen
Damit aus dem Timing-Teil auch ein praktischer Spectre-v2-Angriff wird, brauchten die Forschenden eine Möglichkeit, den Return Stack Buffer so zu befüllen, dass eine kontrollierte Weiterleitung in Kernelpfaden entsteht. Dafür nutzten sie Inception (CVE-2023-20569), eine Schwachstelle, die saferet ursprünglich adressieren sollte.
Das Zusammenspiel ist dabei entscheidend: Der Interrupt Injection-Pfad schafft den „falschen“ Zustand zur falschen Zeit, und Inception liefert die nötige Grundlage, um den Return Stack Buffer mit einem vom Angreifer gewünschten Ziel zu füllen. So entstehen die Voraussetzungen für fehlerhafte Vorhersagen (Mispredictions) in Kernelcode.
Ergebnisse auf AMD und Intel: nicht überall gleich weit
Die Forschenden beobachteten Mispredictions in Kernelcode auf drei von vier getesteten Systemen. Die gemeldeten Erfolgsraten unterschieden sich dabei je nach Plattform:
- Zen 2: 0,75%
- Intel Arrow Lake: 0,22%
- Cascade Lake Refresh: 0,037%
Auf Zen 4 traten in diesem Test keine entsprechenden Mispredictions auf. Für Intel wurde außerdem kein vollständiger End-to-End-Leak demonstriert, weil der Angreifer auch ein geeignetes Disclosure-Gadget im Kernel bereits braucht. Laut den Forschenden ist das jedoch kein prinzipielles Hindernis.
Sie argumentieren, dass Mispredictions zwar notwendig, aber nicht hinreichend sind. Da frühere Arbeiten gezeigt hätten, dass Disclosure-Gadgets in Kernels existieren, sei ein End-to-End-Angriff auf Intel aus ihrer Sicht grundsätzlich möglich. Dafür müsse man lediglich den Ansatz um das passende Disclosure-Gadget ergänzen.
Reaktionen von AMD und Intel: Patchstatus bleibt für Admins schwer greifbar
Zur Einordnung der Risikolage sind die Herstellerreaktionen wichtig. Die Forschenden hatten AMD und Intel am 5. Februar über die Technik informiert.
AMD plant(e) laut damaliger Aussage einen Kernel-Änderungsplan. MIT beschreibt, dass ein entsprechender Fix inzwischen veröffentlicht sei und in einem normalen Betriebssystem-Update ankommt.
Am 6. August veröffentlichte AMD zudem ein Bulletin mit der Bezeichnung AMD-SB-7061 und dem Titel „Safe RET Interrupt Vulnerability“. Dort werden Zen-1- bis Zen-4-Prozessoren als betroffen genannt. In der Zusammenfassung heißt es, ein Angreifer könnte einen Interrupt zu einem präzisen Zeitpunkt injizieren, um „Safe RET“ zu stören. Das könne potenziell die Schutzwirkung schwächen und zu Informationslecks führen. AMD ordnet die Lage dabei dem Linux-Implementationskontext der Safe-RET-Mitigation zu.
Gleichzeitig ist das Bulletin für Systemadministratoren praktisch schwer zu nutzen: Es nennt keine Patch-Version, keinen Kernel-Commit und auch keine CVE-Nummer. In der Folge gibt es laut Bericht keine einfache Vergleichsgrundlage, ob ein konkretes System bereits gefixt ist oder noch auf den Fix wartet.
Als weitere Orientierung existiert auf Systemen mit Linux eine Datei zur SRSO-Statusprüfung unter /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow. Allerdings wurde bei einer Überprüfung am 6. August kein Hinweis gefunden, der Interrupts explizit als relevanten Faktor in die Bewertung einbezieht.
Intel betrachtet laut den Forschenden keine zwingende Mitigation als notwendig. Zur Begründung verweist Intel darauf, dass Exploitability von vielen Faktoren abhänge und dass die Technik durch bestehende Richtlinien abgedeckt sei. Die berichtete Prüfung dieser Guidance fand jedoch keine Erwähnung von Interrupts.
Welche Gegenmaßnahmen diskutieren die Forschenden?
Für eine Abhilfe schlagen die Forschenden eine zweite Neutralisierung auf dem Weg aus einem Interrupt vor. Konkret geht es darum, den Return Stack Buffer vor dem iret so zu „stuffen“, dass der schädliche Zustand nicht weiterwirkt. Auf neueren Intel-Teilen nennen sie alternativ eine entsprechende IBHF-Aktion am gleichen Punkt.
Eine andere Möglichkeit wäre, Interrupts für die Dauer des sehr kleinen Zeitfensters zu blockieren. Die Forschenden quantifizieren allerdings in der Beschreibung keine Performance-Auswirkungen, weshalb das als Option eher in einer weiteren Abwägung bleibt.
Einordnung für die Praxis: Was bedeutet das für betroffene Systeme?
Wenn Ihre Umgebung gemeinsam genutzte Rechner enthält und unprivilegierte Nutzer Code ausführen können, wird die Relevanz klarer. Die Technik richtet sich nicht primär gegen spezielle Root-Konfigurationen, sondern gegen Timing-Lücken zwischen Schutzphasen.
Da AMD zwar eine verwertbare Herstellerzuordnung (Zen 1 bis Zen 4) gibt, aber keine konkrete Patchversion oder CVE nennt, sollten Admins besonders genau darauf achten, ob Updates eingespielt wurden, die den genannten Fix enthalten. Ohne belastbare Versionsangaben bleibt das Vorgehen leider fragmentiert.
Die Sicherheitslage wird zusätzlich durch den Umstand erschwert, dass die Linux-Dokumentation zur SRSO-Statusdatei bei einer schnellen Prüfung keine Interrupt-bezogenen Hinweise bot. Das heißt: Selbst wenn bekannte Statusinformationen gepflegt werden, ist daraus nicht automatisch ersichtlich, ob der spezielle Interrupt Injection-Pfad bereits vollständig adressiert ist.
Ausblick: Paper, weitere Tests und offene Artefakte
Die Forschenden präsentierten ihre Arbeit auf Black Hat USA. Das Paper soll als nächstes auf USENIX Security in Baltimore eingereicht werden. Stand 6. August war außerdem das in der Arbeit erwähnte Artefakt-Repository noch nicht öffentlich.
Für die Community bedeutet das: Sobald Code, genaue Details oder zusätzliche Messergebnisse zugänglich werden, dürfte sich zeigen, wie universell das Timing auf verschiedenen Kernel- und Hardware-Konfigurationen ist und wie gut die empfohlenen Gegenmaßnahmen in der Praxis greifen.
Fazit
Interrupt Injection zeigt, wie engmaschige Schutzmechanismen bei Spectre v2 an Grenzen stoßen können, wenn Interrupts die Annahme „keine feindliche Aktivität zwischen Neutralisierung und Nutzung“ verletzen. Auf AMD Zen 2 unter Linux gelang ein Kernel-Informationsleck bis hin zur Suche und zum Lesen von /etc/shadow, ohne dass der Angreifer privilegiert sein musste.
Für AMD existiert laut Herstellerkommunikation ein Patchplan bzw. ein verfügbares Update, während Intel die Notwendigkeit einer zusätzlichen Mitigation offenbar nicht sieht. Entscheidend bleibt für Admins jedoch die Frage, wie sicher sich der Patchstatus im konkreten System erkennen lässt – und genau hier bleibt in der berichteten Lage noch ein praktisches Loch.
Quelle: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
