Branch Target Reuse: wie die neue Spectre-v2-Variante JIT, den Linux-Kernel und Sandboxes angreift

Forscher haben eine neue Variante der Angriffsklasse Spectre v2 vorgestellt, die den Namen Branch Target Reuse (BTR) trägt, Prozessoren von Intel, AMD und Arm betrifft und es ermöglicht, über JIT-Engines und den Linux-Kernel Geheimnisse aus dem Speicher auszulesen – bis hin zum Root-Passwort-Hash – und das innerhalb weniger Minuten. Verwundbar sind alle Umgebungen, in denen nicht vertrauenswürdiger Code JIT ausführen oder Filter/Programme im Kernel nutzen kann (zum Beispiel cBPF). Der Schutz erfordert ein Update des Linux-Kernels (CVE-2026-64507, CVE-2026-64508), die Konfiguration hardwareseitiger Barrieren für den Branch-Predictor und eine Überprüfung der JIT-Nutzungspolitik in isolierten Umgebungen.

Technische Details des Branch-Target-Reuse-Angriffs

Der BTR-Angriff wird von Forschern der VUSec und der Scuola Superiore Sant’Anna beschrieben und auf der Projektseite Branch Target Reuse ausführlich analysiert. Im Kern handelt es sich um eine Weiterentwicklung von Spectre v2: Der Angreifer vergiftet nicht nur den Indirect-Branch-Predictor, sondern nutzt auch aus, dass der Zustand des Predictors länger lebt als der entsprechende Maschinencode im Speicher.

Der zentrale Mechanismus:

• indirekte Sprünge (indirect branch) werden im Branch-Predictor zusammen mit dem Sprungziel gespeichert;
• JIT oder Kernel geben die Code-Seite frei und verwenden anschließend dieselbe Speicheradresse für neuen Code;
• der Predictor hält weiterhin das „alte“ Sprungziel vor, das zu dem bereits freigegebenen Code gehörte;
• die CPU kann beim Ausführen des neuen Codes spekulativ zum veralteten Ziel springen und einen für den Angreifer nützlichen Codepfad ausführen.

Die Autoren bezeichnen dies als „spekulatives Execute-after-Free“ für Code: Selbst nach dem Freigeben und Wiederverwenden des Speichers zielt der Sprung spekulativ weiter auf das alte Fragment, bis der Predictor geleert wird.

Exploitation über cBPF im Linux-Kernel

Als praktisches Szenario demonstrierten die Forscher die JIT-Kompilierung des klassischen BPF (cBPF) im Linux-Kernel. Die JIT-Engine im Kernel erzeugt Maschinencode für Filter im Speicher und kann diese Seiten anschließend freigeben bzw. wiederverwenden – ideale Bedingungen für BTR.

Es wurden zwei Proof-of-Concept-Exploits für Linux entwickelt:

• für eine Kernel-Konfiguration mit Standardeinstellungen;
• für eine Konfiguration mit aktivierter constant blinding-Schutzfunktion (erschwert die direkte Kontrolle von Konstanten im generierten Code).

Im ersten Fall wird eine einfache Abfolge ausgenutzt:

1. Der Angreifer lädt ein erstes cBPF-Programm, dessen Aufgabe es ist, den Branch-Predictor auf ein bestimmtes Muster indirekter Sprünge zu „trainieren“;
2. dieses Programm wird gelöscht, wodurch der für den Code genutzte Speicher freigegeben wird;
3. im selben Adressbereich wird ein zweites cBPF-Programm platziert, das so gestaltet ist, dass es Daten über einen Seitenkanal exfiltriert;
4. der Branch-Predictor hält weiterhin das Ziel des indirekten Sprungs aus dem ersten Programm vor, und die CPU führt spekulativ den für den Angreifer nützlichen Codeabschnitt des zweiten Programms aus.

Das reicht aus, um beliebige Speicherinhalte mit einer Geschwindigkeit von etwa 8 Byte pro Sekunde auszulesen. In der Demonstration lokalisierten die Forscher den Prozess su und extrahierten aus dessen Speicher den Root-Passwort-Hash; die Attacke dauerte nur wenige Minuten.

In der zweiten Exploit-Variante, auf einem System mit aktivierter constant blinding, kodierten die Forscher steuerbare Instruktionen in die Sprung-Offsets. Trotz der zusätzlichen Komplexität ließ sich der Root-Passwort-Hash ebenfalls in weniger als fünf Minuten extrahieren. Auf Prozessoren der Architekturen Raptor Cove und Lion Cove lag die durchschnittliche Angriffszeit bei rund drei beziehungsweise fünf Minuten.

Die damit verbundenen Probleme im Linux-Kernel erhielten die Kennungen CVE-2026-64507 und CVE-2026-64508. Eine Beschreibung der Schwachstellen ist sowohl in der Linux-Mailingliste CVE-2026-64507 und CVE-2026-64508 als auch in der NVD-Datenbank verfügbar: CVE-2026-64507 in NVD, CVE-2026-64508 in NVD.

Versuche, SpiderMonkey und GraalVM anzugreifen

BTR wurde außerdem gegen höherstufige JIT-Engines getestet:

• SpiderMonkey (die JavaScript-Engine in Firefox) – veraltete Vorhersagen überdauerten tatsächlich die Wiederverwendung des Speichers, was die grundlegende Natur des Effekts bestätigt. Ein funktionsfähiger Browser-Exploit ließ sich jedoch nicht umsetzen: Zusätzliche Schutzmechanismen und die komplexe interne Dynamik des Browsers verhindern dies.
• Oracle GraalVM – den Forschern gelang es, spekulativ den Mechanismus zur Maskierung von Speicheradressen zu umgehen, der eigentlich die Sandbox vor Spectre-ähnlichen Angriffen schützen soll. Zu einem funktionierenden Angriff kam es dennoch nicht: Hintergrundaktivitäten von GraalVM löschten die Predictor-Einträge zu schnell.

Zentrale Erkenntnis: Der Branch-Target-Reuse-Effekt ist auf allen getesteten Prozessoren von Intel, AMD und Arm reproduzierbar und tritt in verschiedenen JIT-Typen auf – selbst dann, wenn deren interne Schutzmechanismen bereits sehr aggressiv sind.

Die hardwareseitige Barriere Indirect Branch Predictor Barrier (IBPB), beschrieben im Intel-Dokument Software Security Guidance: Indirect Branch Predictor Barrier, erschwert die Ausnutzung von BTR, führt aber zu spürbaren Performance-Verlusten.

Bedrohungskontext: Einordnung von BTR in die Spectre-Familie

BTR ist kein neues „Loch“ in einem bestimmten Produkt, sondern eine Demonstration eines systemischen Limitierung moderner Mikroarchitekturen. Die Methoden von Spectre v2 gelten bei Herstellern seit einigen Jahren als „geschlossen“ – durch eine Kombination von Barrieren, Retpoline und Compiler-Anpassungen. BTR zeigt, dass der Branch-Predictor selbst mit diesen Maßnahmen nur unzureichend mit dem Lebenszyklus des Codes im Speicher synchronisiert ist.

Wichtige Konsequenzen:

• jede Plattform, auf der nicht vertrauenswürdiger Code die Erzeugung und das Entladen von JIT-Code anstoßen kann, ist potenziell betroffen: Browser, Java-VMs, .NET, GraalVM, Smart-Contract-Engines, Regex-Engines in Datenbanken und so weiter;
• der Betriebssystemkernel ist keine Ausnahme: JIT in Paketfilter-Subsystemen (cBPF, eBPF) wird zu einem weiteren Kanal für die Exfiltration von Geheimnissen zwischen Prozessen;
• klassische Grenzen vom Typ „Prozess – Adressraum“ werden aufgeweicht: Ein Angreifer mit niedrigen Privilegien kann Daten von höher privilegierten Prozessen oder dem Kernel auslesen, ohne direkte Speicherzugriffsfehler ausnutzen zu müssen.

Die Studie führt keine Beispiele für Angriffe in freier Wildbahn an und bringt BTR nicht mit bestimmten Angreifern oder Operationen in Verbindung. Die Erfahrungen mit Spectre und Meltdown zeigen jedoch, dass derartige Angriffstechniken mit zunehmender Vereinfachung und Optimierung allmählich in das Arsenal fortgeschrittener Gruppen übergehen.

Bewertung der Auswirkungen auf Organisationen und Infrastrukturen

Den größten Risikobeitrag leistet BTR in Szenarien mit gemeinsam genutzten Ressourcen und komplexer Isolation:

• Allgemeine Server und Virtualisierung – insbesondere in Umgebungen, in denen Container oder virtuelle Maschinen von Kunden eigene Filter oder Programme in BPF-Subsysteme des Kernels laden können;
• Entwickler-Workstations und Systeme mit intensiver Nutzung von GraalVM, JVM und anderen JIT-intensiven Plattformen – erhöhte Wahrscheinlichkeit für lokalen Missbrauch auf demselben Rechner;
• Unternehmens-Browser – bei breitem Einsatz von Firefox ist der Reifegrad der Site-Isolation wichtig, die den Nutzen von Seitenkanälen zwischen Tabs reduziert;
• Systeme mit hochsensiblen Geheimnissen im Speicher (Kryptoschlüssel, Zugriffstokens, administrative Passwörter) – selbst ein langsamer Leckkanal von wenigen Byte pro Sekunde ist gefährlich.

Ohne Gegenmaßnahmen sind unter anderem folgende Folgen möglich:

• Extraktion von Passwort-Hashes privilegierter Konten und anschließendes Offline-Knacken der Passwörter;
• Diebstahl kryptografischer Schlüssel, Zugriffstokens und anderer langlebiger Geheimnisse aus Prozessen von Anwendungen oder Diensten;
• unbemerkte Schwächung von Vertrauensmodellen wie „niedrig privilegierter Code – hoch privilegierte Daten“, auch innerhalb von Sandboxes und Containern;
• Compliance-Risiken, falls von der Leckage Daten betroffen sind, die unter Branchen- oder staatliche Regulierung fallen.

Praktische Handlungsempfehlungen zum Schutz

1. Update des Linux-Kernels

Die in CVE-2026-64507 und CVE-2026-64508 beschriebenen Probleme sind im Linux-Kernel bereits behoben. Empfohlene Schritte:

• sicherstellen, dass der verwendete Linux-Distributor Patches für die genannten CVEs integriert hat;
• prüfen, ob es Einträge zu diesen Schwachstellen in den Sicherheitshinweisen des Anbieters und in NVD gibt: CVE-2026-64507, CVE-2026-64508;
• das Update von Servern priorisieren, auf denen BPF-Subsysteme für nicht privilegierte Nutzer zugänglich sind.

Bis zum Einspielen der Updates ist es sinnvoll:

• das Recht zum Laden von BPF-Programmen auf administrative Konten zu beschränken;
• zu prüfen, ob sich JIT für cBPF/eBPF in hochsensiblen Umgebungen vorübergehend deaktivieren lässt, sofern dies mit den Workloads vereinbar ist.

2. Einsatz hardwareseitiger Branch-Predictor-Barrieren

In Hochrisiko-Segmenten (Server mit mehreren Vertrauensdomänen, Systeme zur Verarbeitung geheimer Daten) sollte der Einsatz von Mechanismen wie IBPB erwogen werden. Das Intel-Handbuch zu IBPB ist unter Indirect Branch Predictor Barrier verfügbar.

Praktisches Vorgehen:

• IBPB nur bei Kontextwechseln zwischen Prozessen mit unterschiedlichen Vertrauensdomänen aktivieren (zum Beispiel beim Wechsel von einem nicht vertrauenswürdigen Client zu einem Prozess, der mit branchenspezifischen oder staatlichen Daten arbeitet);
• den Einfluss auf die Performance unter typischen Workloads testen, bevor IBPB breitflächig aktiviert wird.

3. Steuerung von JIT und Isolation im Userspace

• für Firefox-Browser sicherstellen, dass aktuelle Versionen mit vollständiger Site-Isolation eingesetzt werden, die den Wert potenzieller Seitenkanäle zwischen Tabs verringert;
• in Umgebungen mit GraalVM und anderen Java-VMs Updates von Oracle einspielen und deren Empfehlungen zum Schutz vor Spectre-ähnlichen Angriffen befolgen;
• die Richtlinien zur Aktivierung von JIT in Szenarien überprüfen, in denen eine Deaktivierung akzeptabel ist (zum Beispiel spezialisierte Server-Instanzen ohne Bedarf an maximaler Skript-Performance).

4. Monitoring und operative Maßnahmen

Auch wenn Seitenkanal-Angriffe nur schwer direkt zu erkennen sind, lassen sich Begleitindikatoren überwachen:

• ungewöhnliche Muster beim Laden und Entladen von BPF-Programmen im Kernel, insbesondere von nicht privilegierten Nutzern;
• auffällige Nutzung von Tools zur Rechteerhöhung (wie su) auf Applikationsservern;
• Erzeugung und häufige Aktualisierung einer großen Anzahl von JIT-Programmen in nicht vertrauenswürdigen Kontexten.

Strategisch ist BTR ein Anlass, die Segmentierung zu verstärken: Die kritischsten Geheimnisse sollten auf Systemen liegen, auf denen überhaupt kein nicht vertrauenswürdiger Code ausgeführt wird – einschließlich Kundencontainern und JIT-basierten Laufzeitumgebungen.

BTR zeigt, dass die Klasse Spectre v2 auch nach mehreren Wellen von Gegenmaßnahmen weiterlebt und dass die Branch-Predictoren moderner Prozessoren der Dynamik von JIT und Kernel-Code grundsätzlich hinterherhinken. In der Praxis ist jetzt wichtig: den Linux-Kernel auf Versionen mit Fixes für CVE-2026-64507 und CVE-2026-64508 zu aktualisieren, nach Möglichkeit hardwareseitige Branch-Predictor-Barrieren für kritische Knoten zu aktivieren, den Einsatz von JIT und BPF in nicht vertrauenswürdigen Kontexten zu beschränken und die Isolationsarchitektur dort zu überarbeiten, wo auf derselben Hardware unterschiedliche Vertrauensdomänen koexistieren.