Spectre v2 Branch Target Reuse Sicherheitslücke

Forscher haben am 29. September eine neue Spectre v2 Branch Target Reuse Sicherheitslücke offengelegt, mit der Angreifer den Root-Passwort-Hash eines Linux-Systems innerhalb weniger Minuten auslesen können, selbst auf einem vollständig gepatchten Intel-System. Ausgenutzt wird eine Lücke zwischen der Arbeitsweise von CPUs und Just-in-Time-Compilern beim Wiederverwenden von Speicherbereichen. Betroffen sind Intel-, AMD- und Arm-Prozessoren gleichermaßen, und auf Hardware-Ebene schließt kein Patch die Lücke vollständig.

Was ist passiert

Wissenschaftler von VUSec (VU Amsterdam) und der Scuola Superiore Sant’Anna veröffentlichten „Branch Target Reuse“ (BTR), eine neue Variante der 2018 bekannt gewordenen Spectre-v2-Angriffsfamilie. Jeder moderne Prozessor nutzt Sprungvorhersage, um zu erraten, wohin ein Programm als Nächstes springt, und führt entlang dieser Vorhersage spekulativ Code aus. BTR nutzt eine subtile Inkonsistenz aus: Wenn ein Just-in-Time(JIT)-Compiler einen Block kompilierten Codes freigibt und später genau diese Speicheradresse für neuen Code wiederverwendet, stellt die CPU das korrekte architektonische Verhalten zwar wieder her, löscht aber nicht zuverlässig, was sich der Sprungvorhersage-Mechanismus über die alte Adresse gemerkt hat. Ein Angreifer, der einen JIT-Motor dazu bringen kann, Code an einer gewählten Adresse zuzuweisen, freizugeben und neu zuzuweisen, kann die CPU dazu verleiten, spekulativ zum alten, längst ungültigen Code statt zum eigentlichen Ziel zu springen, und Geheimnisse anschließend über den bekannten Cache-Timing-Seitenkanal auslesen.

Die Forscher bestätigten das zugrunde liegende Hardware-Verhalten auf jedem getesteten Intel-, AMD- und Arm-Prozessor und bauten zwei funktionierende Exploits gegen den classic-BPF(cBPF)-Filtermechanismus des Linux-Kernels, der unter anderem in Seccomp-Sandboxing und Paketfilterpfaden von Software wie Docker und Chrome zum Einsatz kommt. Ihr veröffentlichter Proof of Concept durchläuft die interne Prozessliste des Linux-Kernels und gewinnt den Passwort-Hash des Root-Kontos aus einem vollständig gepatchten Intel-System mit Standardkonfiguration innerhalb weniger Minuten, bei einer Leckrate von rund 8 Byte pro Sekunde. Auch Mozillas JavaScript-Engine SpiderMonkey (Firefox) und Oracles GraalVM-Laufzeitumgebung erwiesen sich als grundsätzlich angreifbar, mit geringeren Leckraten, die die Forscher als weiteres Ingenieursproblem, nicht als fundamentale Hürde einordnen.

CPU-Hersteller teilten den Forschern mit, dass bestehende Hardware-Gegenmaßnahmen wie die Indirect Branch Predictor Barrier (IBPB) bereits existieren und BTR softwareseitig geschlossen werden müsse. Der Linux-Kernel hat inzwischen einen Fix veröffentlicht, erfasst als CVE-2026-64507 und CVE-2026-64508, der bei jeder Wiederverwendung eines classic- oder extended-BPF-JIT-Bereichs einen IBPB-Flush erzwingt. Oracles GraalVM entschärft das Problem durch zufällige Platzierung des JIT-kompilierten Codes im Speicher. Mozilla priorisiert nach eigenen Angaben die vollständige Einführung der Site-Isolation in Firefox gegenüber einem provisorischen IBPB-basierten Patch.

Warum das wichtig ist

Die Spectre v2 Branch Target Reuse Sicherheitslücke betrifft nicht ein einzelnes Produkt mit einem einzelnen Patch. Es handelt sich um eine Lücke im Zusammenspiel von CPU-Sprungvorhersage-Hardware mit beliebigen JIT-Compilern, und JIT-Compiler stecken in nahezu jedem modernen Browser, jeder Container-Laufzeitumgebung und jeder serverseitigen Sprachplattform, die in einer deutschen Mittelstands-IT-Landschaft läuft. Acht Jahre nach der ersten Offenlegung von Spectre zeigt BTR deutlich, dass die Kategorie auf Silizium-Ebene nie vollständig geschlossen wurde. Jede seit 2018 ausgelieferte Gegenmaßnahme, auch diese, war eine Software- oder Firmware-Notlösung, aufgesetzt auf Hardware, die für dieses Bedrohungsmodell nie konzipiert wurde. Für einen CISO ist die praktische Angriffsfläche heute enger als die Demonstration vermuten lässt: Ein Angreifer benötigt eine Möglichkeit, Code innerhalb einer verwundbaren JIT-Engine auf dem Zielsystem auszuführen, typischerweise über lokalen Zugriff oder über angreiferkontrollierten Code in einem Browser oder Container. Doch genau die Kategorie „CPU-Ebene, braucht Microcode- oder Kernel-Fix vom Hersteller“ wird in Patch-Management-Programmen erfahrungsgemäß nachrangig behandelt, und BTR liefert ein konkretes Argument dafür, sie mit derselben Dringlichkeit wie jede andere kritische Schwachstelle zu behandeln.

Was Sie jetzt tun sollten

1. Aktualisieren Sie Linux-Kernel auf eine Version mit den Fixes für CVE-2026-64507 und CVE-2026-64508, sobald Ihre Distribution diese bereitstellt, mit Priorität auf allen Hosts, die Container, Browser oder andere Software mit JIT-Kompilierung aus nicht vertrauenswürdiger Eingabe ausführen.
2. Prüfen Sie, ob bpf_jit_harden auf Ihren Linux-Hosts als zusätzliche Schutzebene aktiviert ist; beachten Sie, dass die Forscher auch eine Umgehung dieser spezifischen Härtungsoption demonstriert haben, sie ersetzt den Kernel-Patch also nicht.
3. Verfolgen Sie Mozillas Zeitplan für die Firefox-Gegenmaßnahme; bis vollständige Site-Isolation oder ein gleichwertiger Fix ausgeliefert ist, bleibt die browserseitige Angriffsfläche für BTR-artige Angriffe auf betroffenen Systemen offen.
4. Wenn Sie Oracle GraalVM als Sandbox für nicht vertrauenswürdigen Gastcode (Plugins, benutzerdefinierte Skripte) einsetzen, stellen Sie sicher, dass Sie eine Version mit der Randomisierung des JIT-Code-Caches nutzen, bevor Sie sich auf diese Sandbox-Grenze verlassen.

DIESEC Einschätzung

Wir sehen in Mittelstandsumgebungen immer wieder dasselbe Muster: Teams patchen die Anwendungsebene gewissenhaft, behandeln aber alles, was als „CPU“, „Firmware“ oder „Hardware“ bezeichnet wird, als fremdes Problem, oft weil die letzte große CPU-Ebene-Warnung (Meltdown, Spectre, Downfall) vor der Amtszeit des aktuellen IT-Teams lag. BTR ist ein guter Anlass, „CPU- und Kernel-seitige Gegenmaßnahmen gegen spekulative Ausführung“ als eigenen, nachverfolgten Punkt in Ihr Patch-Management-Programm aufzunehmen, statt sie als Fußnote im Linux-Kernel-Changelog zu behandeln.

Nicht sicher, ob Ihr Patch-Management-Programm CPU- und Kernel-Härtungshinweise überhaupt getrennt von der Anwendungspatchung verfolgt? Kontaktieren Sie DIESEC für eine schnelle Überprüfung Ihres Patch-Managements und Ihrer Schwachstellenverfolgung.

Quellen: VUSec | The Hacker News
Veröffentlicht: 01.10.2026 | Kategorie: Tägliche News | ~4 Min. Lesezeit