Spectre-v2-Variante BTR: Datenleck bei Intel, AMD und Arm

Eine neu veröffentlichte Spectre-v2-Variante kann auf Systemen mit Prozessoren von Intel, AMD und Arm sensible Daten aus dem Speicher auslesen. Nach Angaben der Forscher funktioniert der Angriff selbst auf vollständig gepatchten Rechnern mit Standard-Sicherheitseinstellungen.

Die Technik mit dem Namen Branch Target Reuse (BTR) stammt von der VUSec-Gruppe der Vrije Universiteit Amsterdam in den Niederlanden und von Forschern der Scuola Superiore Sant'Anna in Italien. Sie zielt auf Just-in-time-Compiler (JIT), mit denen Betriebssystemkerne, Webbrowser und Laufzeitumgebungen Code zur Laufzeit erzeugen.

Ein Angreifer, der bereits Code auf dem Zielrechner ausführen kann, könnte über BTR Speicherinhalte wie Passwort-Hashes auslesen. Die Forscher halten auch Angriffe über präparierte Webseiten für möglich, einen vollständigen Browser-Exploit haben sie bisher aber nicht gebaut.

Veraltete Vorhersagen überleben den Code

BTR nutzt aus, wie Prozessoren mit Code umgehen, der während der Ausführung verändert wird. Moderne CPUs stellen sicher, dass die tatsächlichen Befehle im Speicher konsistent bleiben, wenn sich Code selbst verändert. Beim Sprungvorhersager sieht das anders aus.

"Die zentrale Erkenntnis hinter dem Angriff ist, dass moderne CPUs zwar nach einer Selbstmodifikation die architektonische Code-Kohärenz wiederherstellen, veraltete Einträge der indirekten Sprungvorhersage (also Sprungziele) aber nicht zwingend ungültig machen", erklären die Forscher.

In einer JIT-Engine können diese veralteten Einträge bestehen bleiben, obwohl der Code, zu dem sie gehörten, längst verschwunden ist. Wird neuer Code an dieselbe Stelle im Speicher geschrieben, können die alten Vorhersagen erneut verwendet werden. Die Forscher sprechen von einem spekulativen Execute-after-free-Primitiv. Damit kann ein Angreifer die spekulative Ausführung in den neuen Code lenken, und zwar an Offsets, die dort keinen Sinn mehr ergeben.

Das Team untersuchte drei Ziele: Linux cBPF, Oracles Laufzeitumgebung GraalVM und SpiderMonkey, die JavaScript- und WebAssembly-Engine von Firefox.

Root-Passwort-Hash aus dem Linux-Kernel abgegriffen

Gegen den Linux-Kernel entstanden zwei vollständige Exploits, beide auf Basis von klassischem BPF (cBPF). Dessen Nachfolger eBPF ist privilegierten Nutzern vorbehalten, cBPF steht unprivilegierten Programmen aber weiterhin zur Verfügung. Seccomp, Socket-Filter und Paketfilter in Software wie Docker und Chrome sind nach wie vor darauf angewiesen.

Auf modernen Intel-CPUs liest der Exploit beliebigen Speicher aus und umgeht dabei sämtliche aktivierten Schutzmaßnahmen.

"Unser Exploit leakt 8 Byte pro Sekunde. Das klingt vielleicht langsam, aber mit geschicktem Pointer Chasing müssen wir nur eine kleine Datenmenge abgreifen, um an das Geheimnis zu kommen", so die Forscher. In einer Demonstration spürten sie den Root-Passwort-Hash auf, nachdem er in den Speicher geladen worden war, und lasen ihn aus.

Auch Firefox und GraalVM betroffen

In Firefox würde der Angriff auf einer bösartigen Webseite beginnen, die JavaScript im Browser des Opfers ausführt. Mozilla hat die Site Isolation noch nicht vollständig ausgerollt, daher könnten Inhalte aus anderen Tabs im selben Adressraum liegen wie der Code des Angreifers.

Ein Proof of Concept zeigte, dass veraltete Sprungeinträge in SpiderMonkey auf Intel-Chips lange genug erhalten bleiben, um wiederverwendet zu werden. Die Forscher schätzen die Leckrate auf einige Dutzend Byte pro Sekunde, für einen funktionierenden Browser-Exploit wäre allerdings noch mehr Aufwand nötig.

Bei GraalVM könnte BTR es einem Angreifer ermöglichen, spekulativ an der Speichermaskierung vorbeizuspringen, die den strengsten Sandbox-Modus der Laufzeitumgebung gegen Spectre absichert. Die Forscher konnten Speicheradressen zuverlässig wiederverwenden, doch Kompilierung und Garbage Collection von GraalVM löschten die veralteten Einträge, bevor sie sich ausnutzen ließen. Diese Hürde erscheine "nicht grundsätzlicher Natur", sagen sie.

Chiphersteller verweisen auf Software-Korrekturen

Die betroffenen Chiphersteller und Softwareentwickler wurden informiert und haben die Ergebnisse bestätigt. Die CPU-Hersteller erklärten, vorhandene Werkzeuge wie die Indirect Branch Prediction Barrier (IBPB) könnten BTR entschärfen, und die Korrekturen gehörten in die Software.

Die Linux-Kernelentwickler haben eine Schutzmaßnahme für x86 eingebaut, die auf jedem CPU-Kern eine IBPB auslöst, sobald ein cBPF-Programm in Speicher abgelegt wird, in dem zuvor ausgeführter BPF-Code lag. Oracle hat bereits einige Gegenmaßnahmen ausgeliefert. Mozilla konzentriert sich darauf, die Site Isolation fertigzustellen, statt auf IBPB-basierte Korrekturen zu setzen.

Die Forscher bestätigten das Verhalten auf allen getesteten CPUs von Intel, AMD und Arm. "Keine aktuelle CPU verfügt über einen Mechanismus, der beides synchron hält. Solange die Hersteller keinen einbauen, ist Ihre CPU verwundbar", warnen sie.

Hardware-Schutz für den Kontrollfluss, also IBT bei x86 und BTI bei Arm, erschwert die Ausnutzung, beseitigt das Risiko aber nicht. Ältere Intel-CPUs können Befehle noch spekulativ ausführen, bevor die Prüfung greift. Lion Cove ist die früheste Intel-Generation, bei der die Forscher diese Race Condition nicht fanden. Selbst dort umgingen sie IBT, wenn Constant Blinding abgeschaltet war, bezeichnen IBT ohne Race Condition in Kombination mit Constant Blinding aber als deutlich stärkere Abwehr.

AMD teilte SecurityWeek mit, die Arbeit decke keine neue Schwachstelle in seinen Produkten auf, und die bestehenden Empfehlungen zu Spectre v2 würden die Technik entschärfen. Intel und Arm reagierten nicht.

Unsere Einschätzung

BTR folgt einem bekannten Muster: Jahre nachdem Spectre erstmals bekannt wurde, finden Forscher immer neue Wege um die Schutzmaßnahmen herum, die die Lücke eigentlich schließen sollten. Das Kernproblem steckt hier in der Hardware, doch die Last der Behebung tragen Kernel-, Browser- und Laufzeitentwickler. Das spricht für eine uneinheitliche Reaktion, weil jedes Projekt die Leistungseinbußen anders gewichtet, wie Mozillas Entscheidung für die Site Isolation zeigt.

Für die meisten Leser heißt das ganz praktisch: Linux-Kernel, Browser und Laufzeitumgebungen wie GraalVM aktuell halten, sobald die Schutzmaßnahmen verfügbar sind. Besonderes Augenmerk verdienen Multi-Tenant-Hosts, auf denen nicht vertrauenswürdige Nutzer cBPF-Filter laden können. BTR reiht sich zudem in andere Forschungsarbeiten ein, etwa jüngste Ergebnisse, wonach Dateibenachrichtigungs-APIs Nutzeraktivitäten preisgeben, und erinnert daran, dass systemnahes Verhalten Daten auf unerwartete Weise offenlegen kann. Es lohnt sich zu beobachten, ob ein vollständiger Browser-Exploit auftaucht und ob die CPU-Hersteller irgendwann einen Hardware-Mechanismus einbauen, der Sprungvorhersager und Speicher im Gleichschritt hält.