LONDON (IT BOLTWISE) – Forschende von VUSec und der Scuola Superiore Sant’Anna beschreiben mit Branch Target Reuse (BTR) eine neue Spectre-v2-Variante, die besonders JIT-Engines in Browsern, Sprachruntimes und auch im Betriebssystemkern betrifft. Die Attacke zielt darauf ab, veraltete Einträge im indirekten Branch Prediction-Mechanismus auszunutzen, obwohl moderne CPUs nach Selbstmodifikation zwar die Architekturkohärenz wiederherstellen. Als Beleg zeigen die Autoren End-to-End-Exploits gegen den Linux-Kernel, mit denen sich laut Paper innerhalb weniger Minuten ein Root-Password-Hash aus einer vollständig gepatchten Intel-Umgebung rekonstruieren lässt. Mit den angesprochenen CVEs wurden die ersten Gegenmaßnahmen bereits in Linux integriert.
Die jüngste Sicherheitsanalyse zu Spectre-v2 BTR verschiebt den Fokus vom klassischen „Spekulieren für Datenabgriff“ hin zur Frage, wie lange ein Prozessor falsche Vorhersageinformationen „behält“. Während moderne CPUs beim Umgang mit Selbstmodifikation zwar die architektonische Code-Kohärenz wiederherstellen, können veraltete Ziele aus der Vorhersagelogik erhalten bleiben – und genau dieses Detail macht BTR für JIT-nahe Systeme brisant. JIT-Engines werden in Browsern (etwa in Mozilla Firefox), in Sprachruntimes und auch in Teilen des Betriebssystems eingesetzt, weil sie Code zur Laufzeit dynamisch erzeugen und optimieren. Dass ein CPU-Sicherheitsmechanismus hier „in die falsche Zeitzone“ geraten kann, ist ein Angriffspunkt, der in der Praxis vor allem dort relevant ist, wo Code-Caches mit wiederverwendeten Adressen arbeiten.
Technisch bauen die Forschenden BTR auf dem Zusammenspiel von Self-Modifying Code (SMC) und indirektem Branch Prediction auf. Bei Spectre v2 missbraucht ein Angreifer die indirekte Branch-Vorhersage (indirect branch prediction), um eine spekulative Ausführung zu triggern, bei der der Prozessor zwar die fehlerhafte Pfadanweisung anschließend verwirft, die CPU aber dennoch bestimmte Cache-Effekte erzeugt. Über Messungen des Cache-Zustands lässt sich dann ableiten, welche Daten während der spekulativen Phase berührt wurden. BTR setzt darauf, dass die CPU nach dem Freigeben und späteren Wiederverwenden von Code-Cache-Regionen nicht zwingend die alten Branch-Target-Buffer (BTB)-Einträge entfernt. Die Autoren beschreiben den Ablauf so, dass ein Angreifer eine „Training“-Region erzeugt, eine Zieloperation so lenkt, dass eine BTB-Vorhersage auf den aktuellen Entry Point entsteht, anschließend die Training-Region freigibt und durch eine Ziel-Region ersetzt, die einen teilweise gleichen Adressbereich wiederbesetzt. Beim erneuten Triggern der indirekten Branch kann die CPU dann noch den veralteten BTB-Eintrag auswählen und spekulativ zu einer bereits architektonisch ungültigen Stelle springen.
In der Evaluation prüfen die Forschenden explizit mehrere JIT-Umgebungen auf ihre Verwundbarkeit. Genannt werden SpiderMonkey (der JIT-Engine-Teil von Mozilla Firefox), GraalVM sowie der Linux-Kernel-Komponentenpfad für cBPF JIT. Laut Paper unterscheiden sich dabei jedoch sowohl die „Exploitability“ als auch die Leckage-Raten deutlich. Diese Unterschiede sind für Betreiber wichtig, weil sie darauf hinweisen, dass Gegenmaßnahmen zwar die grundsätzliche Klasse adressieren, die praktische Angriffsfläche aber weiterhin vom konkreten JIT-Design, vom Umgang mit Code-Caches und von der Granularität der Invalidierung abhängt. Besonders auffällig ist der Proof-of-Concept: Die Forschenden geben an, dass sich für den Linux-Kernel zwei End-to-End-Exploits ableiten lassen, mit denen sich innerhalb weniger Minuten aus einem vollständig gepatchten Intel-System der Root-Password-Hash rekonstruieren lässt, selbst wenn Standard-Schutzmechanismen aktiv sind.
Damit wird zugleich klar, warum die Veröffentlichung nicht nur theoretisch bleibt. JIT-Engines sind ein typischer Bestandteil heutiger Web- und Runtime-Ökosysteme, und sie nutzen häufig Mechanismen wie Code Cache Reuse, um Aufwand beim Übersetzen zur Laufzeit zu reduzieren. BTR greift an einer Stelle an, die in vielen Schutzkonzepten implizit „als erledigt“ gilt: dass nach Selbstmodifikation oder nach dem Neuzuweisen von Speicher keine alten Vorhersageziele mehr wirksam sind. Wenn aber ein BTB-Eintrag noch „aus der Vergangenheit“ existiert, reicht es nicht, nur das neu erzeugte Ziel korrekt zu machen – entscheidend wird, ob und wann die Vorhersageinfrastruktur invaldiert oder durch nachgelagerte Barrieren überschrieben wird. Die Forschenden beschreiben deshalb auch Umgehungswege für bestehende Spectre-Härtungen, etwa indem der Angreifer den Kontrollfluss zu einem architektonisch ungültigen Entry Point umleitet oder durch fehlalignierte Instruktionen zusätzliche primitive Ausführungen ermöglicht.
Nach dem Prinzip „Disclosure, dann Fix“ wurden Gegenmaßnahmen in Linux bereits zusammengeführt. Die im Paper genannten Mitigation-Änderungen sind in den Kernel integriert, konkret mit den CVE-2026-64507 und CVE-2026-64508. Für GraalVM skizzieren die Autoren als Ansatz eine Hinderung der Region-Reuse durch Randomisierung der JIT-Code-Cache-Positionen. Bei Mozilla wird wiederum erwähnt, dass ursprünglich auch IBPB-basierte (Indirect Branch Predictor Barrier) Mitigations diskutiert wurden, aktuell aber die Priorität auf der Fertigstellung und Bereitstellung von Site Isolation liegt. Im Markt erklärt das zugleich, warum OS- und Browser-Teams in solchen Fällen oft parallel an mehreren Schichten arbeiten: Barrieren auf CPU-nahem Niveau reduzieren zwar die Vorhersagbarkeit, während Isolation und Code-Cache-Strategien die konkrete Wiederverwendungslogik so verändern, dass die für BTR nötige „Stale Entry“-Fensterbildung seltener oder schwerer wird.
Als zusätzlicher Timing-Hinweis wirkt, dass die Veröffentlichung knapp zwei Monate nach einer weiteren speculative-execution Technik erfolgt, die über Interrupt Injection eine Umgehung von Spectre-v2-Defenses ermöglichen kann und dabei dazu gedacht ist, willkürlichen Kernel-Speicher aus Intel- und AMD-basierten Linux-Systemen zu leaken. Für Entscheidungsträger bedeutet das: „Spectre-v2 geschlossen“ ist als Aussage zu grob, weil sich Varianten an unterschiedlichen internen Zustandsmaschinen festsetzen können – mal am indirekten Branch Prediction, mal an Interrupt- oder Timing-Interaktionen. Praktisch sollten Teams daher nicht nur auf einzelne CVEs reagieren, sondern auch prüfen, welche Laufzeit-Mechanismen im eigenen Stack stark JIT-lastig sind, wie eng ihre Deployment-Pfade zu den betroffenen Kernel-Compilationsvarianten sind und ob Code-Caches in der jeweiligen Runtime-Familie vergleichbar wiederverwendet werden. Genau in diesem Spannungsfeld liegt die unternehmensrelevante Konsequenz: BTR zeigt, dass Hardening-Strategien nur dann zuverlässig wirken, wenn sie die Lebensdauer der relevanten CPU-internen Vorhersageeinträge wirklich mit einschließen.
Gleichzeitig bleibt Raum für technisches Nachschärfen, weil die Forschenden selbst betonen, dass BTR je nach Zielumgebung „markant unterschiedliche“ Leckage- und Ausnutzungsparameter zeigt. Für die nächste Phase heißt das: Patches sind notwendig, aber nicht das Ende der Arbeit. Wer JIT- oder Kernel-JIT-Funktionalitäten betreibt, sollte messen, ob neue Invalidation- oder Randomisierungsmechanismen die erwarteten Schutzwirkungen im realen Workload erreichen und ob Nebenwirkungen auf Latenz und Durchsatz entstehen. Denn bei spekulativen Angriffen entscheidet oft nicht die reine Existenz einer Schwachstelle, sondern wie viel Gelegenheit das System bietet, während einer relativ kurzen spekulativen Phase messbare Zustandsänderungen zu erzeugen. Mit den Linux-Fixes als Startpunkt verschiebt sich die Diskussion damit hin zu robusteren, systemweiten Annahmen über Vorhersagezustände und Code-Caches.
💳 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 "Spectre-v2 BTR: Neuer CPU-Angriff leakt Linux-Speicher trotz Abwehrmaßnahmen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
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 "Spectre-v2 BTR: Neuer CPU-Angriff leakt Linux-Speicher trotz Abwehrmaßnahmen" 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: »Spectre-v2 BTR: Neuer CPU-Angriff leakt Linux-Speicher trotz Abwehrmaßnahmen« bei Google Deutschland suchen, bei Bing oder Google News!