- Aufgrund einer Race Condition im Branch Predictor wurde auf Intel-CPUs eine neue Sicherheitslücke namens Branch Privilege Injection entdeckt
- Der Angriff wird durch asynchrone Updates und unzureichende Synchronisierung zwischen Sicherheitsdomänen ermöglicht
- Bestehende Hardware-Gegenmaßnahmen wie eIBRS und IBPB werden durch die Race Condition unwirksam
- Intel entschärft die Schwachstelle mit einem Microcode-Update, das mit Leistungseinbußen verbunden ist
- Die Schwachstelle betrifft alle Intel-CPUs ab der 9. Generation und tritt unabhängig vom Betriebssystem auf
Überblick über den Branch-Privilege-Injection-Angriff
- Branch Privilege Injection ist eine Sicherheitslücke, die Branch-Target-Injection-Angriffe der Spectre-BTI-Familie auf neue Weise wieder aufleben lässt
- Hardwarebasierte Spectre-Abwehrmaßnahmen auf Intel-CPUs waren 6 Jahre lang wirksam, doch diese Forschung zeigt, dass sie durch eine Race Condition umgangen werden können
- Der Branch Predictor arbeitet asynchron zum Instruktionsstrom, wodurch in bestimmten Situationen Updates mit Verzögerungen von einigen Dutzend bis Hunderten von Zyklen auftreten
- Wenn während eines laufenden Branch-Predictor-Updates ein Privilegienwechsel (z. B. User-Kernel, Gast-Hypervisor) oder IBPB ausgeführt wird, kann dieses Update fälschlich dem neuen Berechtigungsmodus zugeordnet werden
- Dies wird als Branch Predictor Race Condition bezeichnet und kann zum Abfluss sensibler Speicherinformationen führen
Angriffsdemonstration und Auswirkungen
- Mit dieser Angriffsmethode wurde unter Ubuntu 24.04 (mit aktuellen Patches und standardmäßig aktivierten Gegenmaßnahmen) eine beliebige Speicherleckrate von 5.6KiB/s erreicht
- Es gibt eine Videodemonstration des erfolgreichen Angriffs auf einer Intel-Raptor-Lake-CPU (13. Generation)
Betroffene Gegenmaßnahmen
- eIBRS: Ein Sicherheitsmechanismus, der ab der 9. Generation (Coffee Lake Refresh) in Intel-CPUs eingeführt wurde und die Vorhersage indirekter Sprünge nach Sicherheitsdomänen trennt.
- IBPB: Da eIBRS nur Angriffe zwischen Hardware-Sicherheitsdomänen verhindert, dient IBPB dazu, für zusätzliche Sicherheitsgrenzen wie nicht vertrauenswürdige virtuelle Maschinen die gesamte indirekte Branch-Vorhersage zu invalidieren
- Beide sind Gegenmaßnahmen, die in den vorgesehenen Umgebungen als sichere Standardeinstellung empfohlen werden
Detaillierte Analyse der Branch Predictor Race Condition
- Wenn im Branch Predictor eine Race Condition auftritt, werden die Sicherheitsgarantien von eIBRS und IBPB aufgehoben
- Erfolgt während der Instruktionsausführung ein Privilegienwechsel, wird ein laufendes Branch-Prediction-Update fälschlich der neuen Sicherheitsdomäne zugerechnet
- Selbst wenn IBPB ausgeführt wird, werden laufende Predictior-Updates nicht geleert, verbleiben im Predictor und verursachen dadurch das Sicherheitsproblem
Gegenmaßnahmen zur Branch Predictor Race Condition
- Intel hat für betroffene Prozessoren ein Microcode-Update entwickelt; auf Alder Lake wurde experimentell bestätigt, dass der Angriff damit blockiert wird
- Bei Anwendung dieser Gegenmaßnahme wurde auf Alder Lake ein Leistungsverlust von bis zu 2.7 % festgestellt
- Auch softwarebasierte alternative Gegenmaßnahmen wurden untersucht; dabei wurden Performance-Overheads von 1.6 % (Coffee Lake Refresh) bis 8.3 % (Rocket Lake) gemessen
- Weitere Details finden sich in der Forschungsarbeit
Weiteres Material
- Die zentrale Forschungsarbeit zu Branch Privilege Injection soll auf der USENIX Security 2025 vorgestellt werden
- Auf der Black Hat USA 2025 ist ein Vortrag mit Fokus auf Erkennung und Exploit der Schwachstelle geplant
- Der Quellcode für Angriff und Experimente ist auf github veröffentlicht
FAQ
1. Ist mein Computer betroffen?
- Alle Intel-Prozessoren ab der 9. Generation (Coffee Lake Refresh) sind von Branch Privilege Injection betroffen
- Das Außerkraftsetzen von IBPB wurde auch bei Produkten bis zurück zur 7. Generation (Kaby Lake) bestätigt
2. Sind auch Nicht-Intel-CPUs betroffen?
- Die Analyse ergab, dass dieses Problem auf AMD- und ARM-Systemen nicht festgestellt wurde
3. Betrifft das nur Linux?
- Die PoC ist zwar für Linux, das zugrunde liegende Problem liegt jedoch in der Hardware
- Alle Betriebssysteme, die auf der betreffenden Hardware laufen, sind verwundbar
4. Was ist zu tun?
- Es wird empfohlen, die neuesten Updates für Betriebssystem und BIOS zu installieren
1 Kommentare
Hacker-News-Kommentare
In einem an der Harvard veröffentlichten Text wird mit einer witzigen Metapher beschrieben, dass Johns Pech darin bestand, dass Branches einen Pakt mit Satan und der Quantenmechanik geschlossen und damit zukünftige Prozessorgenerationen mit schädlicher Magie belegt hätten; diese Magie sei unter Namen wie „spannungsbedingte Leckströme durch Skalierung“ oder „zunehmende verschwendete Wärme“ geblieben
Der Eindruck, dass die Texte von James Mickens immer unterhaltsam seien, zusammen mit einem Scherz, dass der für Sicherheit zuständige Mossad sich um Dinge wie HTTPS nicht kümmere; wenn sie Daten bräuchten, würden sie lieber per Drohne dein Handy gegen eine Uran-Attrappe austauschen und schließlich deine Sachen bei einem Nachlassverkauf kaufen, um sich die Fotos direkt anzusehen
Die Bemerkung, dass die Passage über die vielen Matrizen einen kleinen Hoffnungsschimmer zeige, sowie die Erzählung, Johns Bruder habe herausgefunden, wie man diesen Matrizen beibringt, wie Menschen zu sprechen
Teilen des Links zum Forscher-Blog und zum Paper
Feedback, dass der obige Link von der Pressemitteilung der Universität auf den Blogpost der Forschenden geändert wurde
Zur Auswirkung der neuen Schwachstelle erklärt ein Forscher, dass sich der gesamte Speicherinhalt der CPU wiederholt auslesen lasse und sogar 5.000 Byte pro Sekunde möglich seien; wenn der Angriff erfolgreich sei, könnten letztlich alle Informationen der CPU offengelegt werden
Der Wunsch, die Titel-URL auf den Blog-Link zu ändern
Zusammenfassung zur Funktionsweise des Branch Predictors
Freude darüber, dass Professor Kaveh Razavi an seiner Universität einmal einen Kurs zu Hardware-Sicherheit unterrichtet hat und dass dieser Kurs wirklich großartig gewesen sei
Vor einigen Jahren habe man versucht, Informationen zu diesem Kurs und einer weiteren Vorlesung über Malware zu finden, aber es habe kaum öffentliche Informationen gegeben; die Frage, ob es offizielle Aufzeichnungen oder Notizen online gebe
Die Frage, ob jemand den Zusammenhang zwischen dem Training-Solo-Angriff und dieser Schwachstelle kenne
Verwunderung darüber, dass in der Erklärung zu Microcode-Patches für den Chipsatz nur Windows erwähnt wird, mit der Frage, was mit Linux-Nutzern sei
Der Linux-Kernel unterstütze das Laden von Microcode schon seit Langem, aber Intel müsse die Microcode-Dateien bereitstellen, damit die einzelnen Distributionen sie aktualisieren könnten; die Erklärung, dass sie in System-Updates enthalten sein müssten
Intel veröffentliche Microcode-Updates für Linux auf GitHub, daher würden die einzelnen Distributionen sie dort automatisch beziehen und ausliefern; ob diese Schwachstelle tatsächlich gepatcht sei, wisse man als Nicht-Experte allerdings nicht sicher
Teilen des offiziellen Intel-Sicherheitsadvisory-Links
Die Frage, ob AMD-CPUs eine ähnliche Schwachstelle hätten, sowie der Hinweis, dass technische Mechanismen wie Branch Prediction die eigentliche Ursache von CPU-Sicherheitslücken seien, verbunden mit der Frage, wie AMD solche Schwachstellen vermeide
Als Antwort mit Verweis auf die Zusammenfassung im Forscher-Blog: Diese Branch Privilege Injection betrifft AMD- und ARM-Systeme nicht
Der Hinweis, dass AMD solchen Problemen nicht vollständig entgangen sei; wie bei Spectre und Meltdown variiere der Umfang je nach Schwachstelle, dieser Fall betreffe zwar nur Intel, aber AMD sei bei derselben Klasse von Schwachstellen, etwa Spectre, ebenfalls schon verwundbar gewesen
Eine etwas gründlichere Erklärung, dass speculative execution an sich keine Schwachstelle, sondern ein in modernen CPUs notwendiger Mechanismus sei; die interne Komplexität mache Fehler so schwer auffindbar, dass es auch bei AMD und ARM ähnliche Bugs geben könne; die einzige vollständige Lösung würde erfordern anzuerkennen, dass Code-Isolation in modernen Systemen nicht möglich ist, was für die Geschäftsmodelle einiger Großunternehmen verheerend wäre
Als Gegenmaßnahme gegen diese Schwachstelle der Vorschlag, beim Aktualisieren der Branch Prediction die Privilegienstufe wie einen Snapshot zu speichern und diesen Wert mitzuführen; damit ließe sich das Problem vermutlich ähnlich lösen wie vergleichbare Probleme in Software
Der scherzhafte Hinweis, dass es leicht vermeidbar gewesen wäre, wenn der CPU-Branch-Predictor Puffergrenzen und die Privilegieninformationen des Codes direkt prüfen könnte; dafür müsste man allerdings wichtige Informationen an Zeiger anhängen
Die Meinung, man müsse den Umfang des Problems klarer verstehen; Angriffe über speculative execution erforderten tatsächlich enorme Vorbereitung und seien ohne direkte Berechtigung zur Codeausführung von geringem Nutzen; aus einem Browser heraus lasse sich mit beliebigem JS-Code kein beliebiger Informationsabfluss erzielen; man selbst deaktiviere alle Mitigations für mehr Leistung
Empfehlung der CHERI-Architektur
Der Hinweis, dass es nicht damit getan sei, nur die Zeigerstruktur zu ändern; stattdessen der Verweis auf das frühere x86-Segmentmodell (80286), bei dem die Hardware jedem Speicherzugriff Adressgrenzen mitgab; auch solche Systeme hätten jedoch dieselbe Grenze gehabt, weil Software die Grenzinformationen korrekt behandeln musste
Die Frage, ob zum jetzigen Zeitpunkt Patches für diese Schwachstelle (oder entsprechender Microcode) für alle wichtigen Betriebssysteme vorliegen
Antwort: ja, heute am 13. Mai ist das Disclosure-Datum