Branch-Target-Reuse macht verworfenen JIT-Code zur Spectre-Datenleck-Primitive

Forschende haben Branch Target Reuse, kurz BTR, vorgestellt – eine Variante von Spectre v2, die Branch-Vorhersagen ausnutzt, die zurückbleiben, nachdem Just-in-Time-kompilierter Code aus dem Speicher entfernt wurde.

Das Team von VUSec an der Vrije Universiteit Amsterdam und der Scuola Superiore Sant’Anna demonstrierte die Technik am Linux-Kernel. Mit ihrem Exploit extrahierten sie über nicht privilegierte klassische BPF-Programme den Hash des Root-Passworts aus einem laufenden su-Prozess.

Der Angriff konnte acht Byte pro Sekunde auslesen. Die vollständige Wiederherstellung dauerte im Durchschnitt drei Minuten auf Intel Raptor Cove und fünf Minuten auf Intel Lion Cove, wie aus der am 29. September 2026 veröffentlichten Forschungsarbeit hervorgeht.

Das zugrunde liegende Prozessorverhalten wurde auf allen getesteten CPUs von Intel, AMD und Arm bestätigt. Ob sich die Technik praktisch ausnutzen lässt, hängt jedoch von der Softwareumgebung, der Prozessorgeneration und den aktivierten Schutzmaßnahmen ab.

Veraltete Vorhersagen überdauern die Wiederverwendung von JIT-Speicher

Moderne Prozessoren sagen das Ziel indirekter Sprünge voraus, damit sie weiter Befehle ausführen können, ohne auf die Auflösung des korrekten Ziels warten zu müssen. Angriffe der Spectre-Klasse manipulieren dieses spekulative Verhalten oder nutzen es aus, um auf Informationen zuzugreifen, die bei regulärer Ausführung nicht offengelegt werden dürften.

BTR setzt dort an, wo ausführbarer JIT-Speicher wiederverwendet wird.

Eine JIT-Engine kann ein Programm kompilieren, dessen Maschinencode an einer bestimmten Speicheradresse ablegen und den Code später freigeben. Anschließend kann derselbe Speicher ein anderes Programm aufnehmen. Obwohl sich die Bytes im Speicher geändert haben, kann der Prozessor weiterhin Branch-Target-Informationen zum vorherigen Code vorhalten.

Ein indirekter Sprung kann deshalb spekulativ in den neuen Code verzweigen und dabei ein veraltetes Ziel verwenden. Dieses kann auf eine unbeabsichtigte oder falsch ausgerichtete Stelle innerhalb der neuen Befehlsfolge zeigen.

Bei der regulären Ausführung wird der falsche Pfad letztlich verworfen. Bis dahin können spekulativ ausgeführte Befehle jedoch auf sensible Daten zugreifen und den Cache verändern. Ein Angreifer kann diese Cache-Effekte messen und die Daten Byte für Byte ableiten.

So entsteht eine Primitive, die die Forschenden als spekulatives „Execute-after-free“ bezeichnen: Der Prozessor verhält sich, als sei eine alte Kontrollflussbeziehung weiterhin gültig, obwohl der zugehörige Code nicht mehr existiert.

Linux-Exploit liest Root-Passworthash aus

Für ihre Linux-Demonstration nutzten die Forschenden nicht privilegierte klassische BPF-Programme, kurz cBPF. Sie trainierten die Branch-Vorhersage mit einem Programm, gaben dieses anschließend frei und sorgten dafür, dass anderer JIT-kompilierter Code denselben Speicher belegte.

Dann zielten sie auf einen laufenden su-Prozess und lasen dessen Root-Passworthash aus dem Speicher aus. Dem Bericht zufolge konnte der Exploit im getesteten Szenario auf modernen Intel-Prozessoren beliebige Speicherinhalte auslesen – auch auf vollständig aktualisierten Systemen mit den standardmäßigen Sicherheitseinstellungen.

Das Team entwickelte zwei vollständige cBPF-Exploits. Einer funktionierte mit der Standardkonfiguration. Der andere zielte auf Systeme mit aktiviertem BPF Constant Blinding ab. Diese Schutzmaßnahme soll verhindern, dass vom Angreifer kontrollierte Konstanten direkt im erzeugten Maschinencode erscheinen.

Für die zweite Variante kodierten die Forschenden vom Angreifer kontrollierte Befehle über Sprung-Offsets. Trotzdem konnten sie den Passworthash innerhalb von fünf Minuten wiederherstellen.

Einen Hash auszulesen ist nicht dasselbe, wie das Klartextpasswort zu erhalten. Der Angreifer müsste den Hash separat knacken, etwa mit Offline- oder Cloud-Rechenressourcen. Ob das gelingt, hängt von der Stärke des Passworts und dem verwendeten Hashing-Algorithmus ab.

Der demonstrierte Angriffsweg setzt außerdem voraus, dass der Angreifer nicht privilegierte cBPF-Programme ausführen kann. Die leistungsfähigeren eBPF-JIT-Funktionen erfordern in der von den Forschenden beschriebenen Umgebung privilegierten Zugriff. cBPF ist jedoch weiterhin für seccomp, Socket-Filter und Paketfilter relevant. Zu den Anwendungen, die diese Funktionen nutzen, zählen Docker und Chrome.

Welche Linux-Kernelversionen betroffen sind, wurde nicht offengelegt. Administratoren können daher nicht allein anhand eines Abgleichs mit einer Liste bekanntermaßen verwundbarer Versionen feststellen, ob ihre Systeme betroffen sind.

Zwei CVEs betreffen die BPF-JIT-Wiederverwendung und das Leeren des Prädiktors

Die Änderungen für Linux stehen im Zusammenhang mit CVE-2026-64507 und CVE-2026-64508. Den vorliegenden NVD-Angaben zufolge sind weder CVSS-Scores und -Vektoren noch CWE-Klassifizierungen oder betroffene Versionsbereiche verfügbar.

CVE-2026-64507 betrifft eine Härtungsmaßnahme, die greift, wenn Spectre-v2-Schutzmaßnahmen aktiv sind. Wird BPF-JIT-Speicher wiederverwendet, löst der Kernel eine Indirect Branch Prediction Barrier (IBPB) aus. Dadurch sollen veraltete Vorhersagen nicht auf neu geschriebenen Code übertragen werden.

Die beschriebene Implementierung überspringt das Leeren des Prädiktors, wenn der BPF-Dispatcher bereits eine Retpoline-Sequenz verwendet. Die Änderung greift nur, wenn der BPF-JIT aktiv ist, und ist durch CONFIG_BPF_JIT abgesichert. So lassen sich auch Kernel mit CONFIG_BPF_JIT=n korrekt kompilieren.

CVE-2026-64508 betrifft den Umgang des BPF-JIT-Allokators mit ausführbarem Speicher. Der Allokator bündelt kleine Programme in größeren Speicherbereichen und gibt Platz wieder frei, wenn Programme geladen oder entfernt werden. Eine für ein altes Programm erzeugte Vorhersage kann daher die spekulative Ausführung in neuen Code lenken, der dieselbe Speicheradresse belegt.

Die zugehörige Härtungsmaßnahme leert die Prädiktoren für indirekte Sprünge, bevor dieser JIT-Speicher wiederverwendet wird. Berichten zufolge implementierten Linux-Entwickler eine x86-Schutzmaßnahme, die für alle Prozessorkerne eine IBPB auslöst, wenn cBPF-Code in einen Bereich gelangt, der zuvor von BPF-Code belegt war.

Korrekturen wurden in den Linux-Kernel übernommen, konkrete Versionsnummern mit den Fehlerbehebungen sind jedoch nicht bekannt. Für keine der beiden CVEs ist anhand der verfügbaren Daten bestätigt, dass sie im Katalog der CISA zu bekannten, aktiv ausgenutzten Schwachstellen aufgeführt ist oder dass eine Behebungsfrist gilt. Der demonstrierte Forschungs-Exploit sollte daher nicht als bestätigte Ausnutzung in freier Wildbahn bezeichnet werden.

Firefox und GraalVM bieten weitere Angriffsflächen

BTR beschränkt sich nicht auf den Linux-BPF-JIT. Die Forschenden beobachteten entsprechendes Verhalten auch in der SpiderMonkey-Engine von Firefox und in Oracle GraalVM. In keinem der beiden Fälle gelang ihnen jedoch ein vollständiger End-to-End-Exploit.

In SpiderMonkey blieben veraltete Vorhersagen erhalten, nachdem JIT-Code-Adressen auf Intel-Prozessoren wiederverwendet worden waren. Die Forschenden schätzten, dass sich mit einer ausgereiften Technik Dutzende Byte pro Sekunde auslesen ließen. Um aus dem Proof of Concept einen funktionierenden Browser-Angriff zu machen, wären jedoch weitere Arbeiten nötig.

Das mögliche Ausmaß hängt teilweise von der Prozessisolation ab. Laut dem Bericht von SecurityWeek zu den Ergebnissen hatte Mozilla die Einführung der Site-Isolation noch nicht abgeschlossen. Inhalte aus verschiedenen Tabs könnten deshalb unter bestimmten Umständen denselben Adressraum nutzen, was einen möglichen Weg zum Auslesen von Daten aus anderen Tabs eröffnen würde. Ein abgeschlossener Angriff, der ein solches Szenario demonstriert, wurde nicht gemeldet.

In GraalVM fanden die Forschenden einen spekulativen Ausführungspfad, der im strengsten Sandbox-Modus der Laufzeitumgebung eine Sandbox-Prüfung mit Memory Masking umgehen könnte. Sie konnten die Wiederverwendung von Speicheradressen zuverlässig erzwingen. Während des Angriffs löschten jedoch Kompilierungs- und Garbage-Collection-Aktivitäten die veralteten Branch-Einträge, bevor sie den Angriff abschließen konnten.

Diese Störung schränkte das Experiment ein, widerlegte die Primitive aber nicht. Die Forschenden betrachteten sie nicht als grundsätzliches Hindernis. Berichten zufolge hat Oracle einige Schutzmaßnahmen umgesetzt; genaue Produktversionen und Patch-Stände wurden jedoch nicht offengelegt.

Hardware-Schutzmaßnahmen erhöhen den Aufwand, schließen aber nicht alle Angriffswege

Kontrollfluss-Schutzmaßnahmen wie Intel Indirect Branch Tracking und Arm Branch Target Identification können einen BTR-Angriff erschweren. Sie verhindern jedoch nicht alle von den Forschenden beschriebenen Techniken.

Ältere Intel-Prozessoren können Befehle spekulativ ausführen, bevor die entsprechende Kontrollflussprüfung greift. Lion Cove war die erste Intel-Prozessorgeneration, bei der die Forschenden diese spezielle Race Condition nicht mehr feststellten.

Auch ein racefreies IBT bedeutet nicht, dass ein System vollständig geschützt ist. Berichten zufolge konnten die Forschenden IBT auf Prozessoren ohne diese Race Condition umgehen, wenn Constant Blinding deaktiviert war. Die Kombination aus racefreiem IBT und Constant Blinding bietet einen deutlich stärkeren Schutz.

Die CPU-Hersteller verwiesen im Allgemeinen auf bestehende Schutzmechanismen wie IBPB und betonten, dass Software den Zustand der Prädiktoren leeren sollte, wenn sich die Bedeutung von ausführbarem Speicher ändert. AMD erklärte, die Forschung habe keine neue Schwachstelle in seinen Produkten aufgezeigt, und verwies auf die bestehenden Spectre-v2-Empfehlungen. Stellungnahmen von Intel und Arm wurden nicht veröffentlicht.

Administratoren sollten Kernel- und Firmware-Updates priorisieren

Linux-Betreiber sollten die neuesten Kernel-Updates ihrer Distribution installieren – insbesondere auf Systemen, auf denen nicht privilegierte cBPF-Funktionen verfügbar sind. Da keine Übersicht der Versionen mit Fehlerbehebungen veröffentlicht wurde, sind die Sicherheitshinweise der jeweiligen Distribution der praktikabelste Weg, um aktualisierte Pakete zu ermitteln.

Auch Firmware- und Microcode-Updates sollten eingespielt werden. Sie können bestehende Schutzmaßnahmen gegen spekulative Ausführung verbessern. Die für die Wiederverwendung von BPF-Speicher beschriebene praktische Korrektur besteht jedoch darin, IBPB durch die Software auszulösen.

Teams sollten prüfen, ob ihre Workloads nicht privilegiertes cBPF benötigen – insbesondere auf Mehrbenutzersystemen oder Systemen, auf denen Code weniger vertrauenswürdiger Mandanten läuft. Funktionen ohne Kenntnis ihrer Abhängigkeiten zu deaktivieren, könnte seccomp- oder Filter-Workloads beeinträchtigen. Einschränkungen sollten daher vor der Bereitstellung getestet werden.

Spezifische Malware-Indikatoren, Dateihashes, Domains oder Netzwerk-Signaturen für den Angriff wurden nicht veröffentlicht. Die Erkennung muss sich daher auf eine ungewöhnliche lokale Nutzung von BPF-Funktionen, unerwartetes Laden nicht privilegierter Programme und verdächtige Aktivitäten rund um sensible Prozesse konzentrieren. Diese Anzeichen sind nicht spezifisch für BTR, können aber dabei helfen, die Voraussetzungen des demonstrierten Linux-Angriffs zu erkennen.