- Branch Privilege Injection ist eine Schwachstelle, die die seit etwa sechs Jahren bestehenden Hardware-Abwehrmaßnahmen der Spectre-BTI-Familie erneut umgeht, indem sie Race Conditions im Branch Predictor von Intel-CPUs ausnutzt
- Der Kern des Angriffs ist, dass Aktualisierungen des Branch Predictors asynchron zum Befehlsfluss verarbeitet werden und unter bestimmten Bedingungen erst Dutzende bis Hunderte Taktzyklen später wirksam werden können
- Wenn verzögerte Updates während eines Privilegienwechsels oder der Ausführung von IBPB bestehen bleiben, können sie anschließend mit der falschen Sicherheitsdomäne verknüpft werden, wodurch die Sicherheitsgarantien von eIBRS und IBPB gebrochen werden können
- Die Forschenden demonstrierten auf Ubuntu 24.04 mit allen standardmäßig aktivierten Mitigations auf einem Intel Raptor Lake der 13. Generation einen End-to-End-Angriff, der beliebigen Speicher mit 5.6KiB/s exfiltriert
- Das Microcode-Update von Intel blockierte in der Bewertung auf Alder Lake die Primitive zur Erkennung der Schwachstelle und zeigte einen Overhead von bis zu 2.7%
Bedingungen, unter denen Branch Privilege Injection funktioniert
- Branch Privilege Injection ist ein Angriff der Art Branch Target Injection, also ein Angriff, der die Wirksamkeit von Spectre-BTI in Intel-Umgebungen wiederherstellt
- Intels Hardware-Mitigationen haben diesen Angriffstyp etwa sechs Jahre lang verhindert, doch diese Forschung zeigt, dass Race Conditions in Intel-CPUs diese Abwehr untergraben können
- Der Angriff beruht auf zwei Beobachtungen
- Der Branch Predictor in Intel-Prozessoren wird asynchron zum Befehlsfluss aktualisiert
- Unter bestimmten Bedingungen verzögert sich ein Update um Dutzende oder Hunderte Taktzyklen
- Das asynchrone Update selbst ist keine Schwachstelle, sondern ein Feature
- Während sicherheitskritischer Vorgänge ist die Synchronisation zwischen Branch Predictor und Befehlsfluss nicht ausreichend
- Beim Wechsel vom User Mode in den Kernel oder vom Gast zum Hypervisor können Updates noch in Bearbeitung sein
- Auch während der Ausführung von IBPB können noch ausstehende Updates verbleiben
- Treffen solche Updates nach dem Privilegienwechsel ein, werden sie nicht mit dem vorherigen, sondern mit dem neuen Privilegienmodus verknüpft
- Der Branch Predictor in Intel-Prozessoren wird asynchron zum Befehlsfluss aktualisiert
- Diese Klasse von Schwachstellen heißt Branch Predictor Race Conditions
Betroffene Mitigationen und Wirkungsbereich
- eIBRS ist Intels Spectre-BTI-Mitigation, die seit Coffee Lake Refresh der 9. Generation in alle Prozessoren integriert wurde
- Ziel ist die Trennung indirekter Branch-Predictions nach unterschiedlichen Sicherheitsdomänen
- Jede Prediction wird mit der Domäne verknüpft, in der sie erzeugt wurde, und anschließend sollen nur Predictions der aktuellen Domäne verwendet werden
- Wenn ausstehende Updates während eines Privilegienwechsels der neuen Sicherheitsdomäne zugeordnet werden, lässt sich diese Zuordnung manipulieren
- IBPB ist ein Mechanismus zur Trennung von Sandboxes oder voneinander nicht vertrauenden virtuellen Maschinen innerhalb derselben Hardware-Sicherheitsdomäne
- Er stellt eine Funktion bereit, die alle indirekten Branch-Predictions invalidiert
- Noch laufende Updates werden durch IBPB nicht geleert und können daher auch nach der Invalidierung im Branch Predictor gespeichert werden
- Der Wirkungsbereich unterscheidet sich je nach Generation und Architektur
- Alle Intel-Prozessoren seit Coffee Lake Refresh der 9. Generation sind von Branch Privilege Injection betroffen
- Predictions, die IBPB umgehen, wurden bis zurück zur 7. Generation Kaby Lake beobachtet
- Auf den evaluierten AMD- und ARM-Systemen wurde kein Problem gefunden
- Der Proof-of-Concept-Angriff wurde für Linux erstellt, doch da das Grundproblem in der Hardware liegt, sind Betriebssysteme betroffen, die auf der betroffenen Hardware laufen
Mitigationen, Performance-Kosten und veröffentlichte Materialien
- Es wird empfohlen, die neuesten Betriebssystem- und BIOS-Updates zu installieren
- Intel hat Microcode-Updates für betroffene Prozessoren entwickelt, und die Forschenden haben diese auf Alder Lake evaluiert
- Die Microcode-Mitigation blockierte die Primitive zur Erkennung der Schwachstelle
- Auf Alder Lake zeigte sie einen Overhead von bis zu 2.7%
- Auch Software-Alternativen für Mitigationen wurden evaluiert
- Auf Coffee Lake Refresh lag der Overhead bei 1.6%
- Auf Rocket Lake lag der Overhead bei 8.3%
- Detaillierte technische Inhalte finden sich im Paper
- Das Paper zu Branch Privilege Injection soll auf der USENIX Security 2025 vorgestellt werden; außerdem ist ein Vortrag auf der Black Hat USA 2025 geplant
- Der Quellcode für Angriff und Experimente ist auf github veröffentlicht
1 Kommentare
Meinungen auf Hacker News
Blogbeitrag der Forschenden: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Paper: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
In einem Angriffsszenario ist es am Ende nur eine Frage der Zeit, bis Informationen aus dem gesamten CPU-Speicher in die falschen Hände geraten
Guter Artikel. Kurz gesagt können Updates des Branch Predictors auf deutlich später verschoben werden, nachdem die Branch-Instruktion retired wurde
Das ergibt Sinn, denn sonst würde das Retire der Branch-Instruktion länger dauern. Auch Dispatch-serialisierende Instruktionen scheinen die Pipeline wegen ausstehender Updates des Predictor-Zustands nicht anzuhalten, was natürlich ist, da „Commit des Ergebnisses der Branch-Instruktion“ und „Commit des Vorhersageergebnisses“ bereits getrennt wurden
Instruktionen zum Wechsel der Privilegien halten die Pipeline wegen ausstehender Updates ebenfalls nicht an, was nur dann vertretbar ist, wenn garantiert werden kann, dass das Privilegienniveau beim Erstellen und beim Commit der Vorhersage konsistent ist. Andernfalls können Vorhersagen, die Code auf einem Privilegienniveau erzeugt hat, in einen Zustand committet werden, der auf einem anderen Privilegienniveau verwendet wird
Vielleicht ist das ein schwieriges Problem, weil das aktuelle Privilegienniveau innerhalb der Pipeline kein einzelner, eindeutig bestimmter Wert ist
Schön, Kaveh Razavi zu sehen. Er hat früher an der Vrije Universiteit Amsterdam gelehrt, und der Kurs Hardware Security ging tief auf solche Themen ein und war wirklich großartig
Ich frage mich, ob offizielle Aufzeichnungen oder Mitschriften online verfügbar sind
Weiß jemand, wie das mit dem gerade veröffentlichten Angriff Training Solo zusammenhängt? https://www.vusec.net/projects/training-solo/
Training Solo tritt in den Kernel ein, wechselt das Privilegienniveau und bringt dann durch „Selbsttraining“ einen Branch dazu, fälschlich auf ein Disclosure Gadget vorhergesagt zu werden, wodurch Speicher offengelegt wird
Branch-predictor race conditions treten in den Kernel ein, während ein trainiertes Update des Branch Predictors noch verarbeitet wird, sodass dieses Update dem falschen Privilegienniveau zugeordnet wird. Das wird wiederum genutzt, um einen Kernel-Branch zu einem Disclosure Gadget umzulenken und Speicher offenzulegen
Wenn der CPU-Branch Predictor die Informationen zur Prüfung von Puffergrenzen und Code-Privilegienniveau direkt nutzen könnte, ließen sich solche Probleme viel leichter verhindern
Aber solange man den C-Programmierern
void*nicht aus ihren kalten Händen entreißt und Pointer nicht um wichtige Informationen ergänzt, wird das wohl nicht passierenUm das Gewünschte zu erreichen, bräuchte man eine Hardwarearchitektur, bei der alle Loads/Stores über eine Art „erweiterte Adresse“ laufen, die Grenzinformationen speichert
Im Grunde verlangt man damit 80286-Segmentierung; die gab es bereits und sie hat nicht das Gewünschte geleistet. Der Grund ist, dass auch diese Segmentdeskriptoren von Software korrekt geladen werden müssen. Aus Sicht der Software ist es am Ende wieder „nur ein Pointer“ und damit anfällig für dieselben Fehler
Bei spekulativer Ausführung braucht man absurde Vorarbeit, um diese Schwachstelle tatsächlich für irgendetwas zu nutzen. Der praktisch einzige nutzbare Weg ist, direkten Zugriff auf den betreffenden Rechner zu haben und Low-Level-Code auszuführen. Es ist nicht so, dass allein im Browser laufender JS-Code beliebige Geheimnisse offenlegen könnte
Wenn ein System wertvoll genug ist, dass eine spezialisierte private Organisation oder eine staatlich unterstützte Organisation den nötigen Forschungs- und Targeting-Aufwand betreiben würde, sollte es ohnehin Mechanismen geben, die die Ausführung nicht autorisierten beliebigen Codes verhindern
Persönlich merke ich die Leistungssteigerung tatsächlich und habe deshalb alle Mitigations ausgeschaltet
Intel-Sicherheitshinweis: https://www.intel.com/content/www/us/en/security-center/advi...
Ich frage mich, ob es auf AMD-Hardware ähnliche Lücken gibt. Speculative Execution wirkt wie eine Schwachstelle, die sich in gemeinsam genutzten Prozessorumgebungen nur sehr schwer patchen lässt; daher frage ich mich, wie AMD dem entgangen ist.
Auf den untersuchten AMD- und ARM-Systemen wurde demnach kein Problem gefunden.
Quelle: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Diese konkrete Schwachstelle scheint, ähnlich wie Meltdown, Intel-spezifisch zu sein; AMD war aber ursprünglich ebenfalls für Spectre anfällig.
Allerdings sind Speculative-Execution-Engines komplex, sodass Bugs und Schwachstellen darin sehr weit verbreitet sind.
Es ist sehr wahrscheinlich, dass es auch bei AMD und ARM ähnliche Bugs gibt. Man muss nur daran denken, wie lange solche Bugs bei Intel unentdeckt geblieben sind.
Leider bestünde die wirkliche Lösung darin, anzuerkennen, dass sich Code auf modernen Systemen nicht isolieren lässt; das könnte für die Geschäftsmodelle einiger sehr wohlhabender Unternehmen fatal sein.
Ist das nicht dasselbe Problem und dieselbe Lösung, wie man sie aus Software erwarten würde?
Es heißt: „Um solche Lücken zu schließen, ist ein spezielles Update des Prozessor-Microcodes nötig. Das ist über ein BIOS- oder Betriebssystem-Update möglich und sollte daher über eines der neuesten kumulativen Updates von Windows auf dem PC installiert werden.“ Warum wird nur Windows erwähnt? Was ist mit Linux-Nutzern?
Distributionen sind so eingerichtet, dass sie diese von dort beziehen und automatisch ausliefern.
Ich weiß allerdings nicht genau, worauf man achten muss, um zu prüfen, ob diese konkrete Mitigation schon enthalten ist.
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL).Allerdings muss Intel die nötigen Microcode-Dateien veröffentlichen, damit Distributionsbetreuer ihre Pakete aktualisieren können; danach werden sie in Systemupdates enthalten sein.
Ich frage mich, ob Intel einen Weg zur Erholung hat. Es gibt kein überzeugendes Produkt am Markt, Forschung und Entwicklung dauern lange, und die Foundry hängt hinter der Konkurrenz zurück und bleibt eine Verlustquelle.
Außerdem wird x86 zunehmend von ARM-Hardware verdrängt, und nun wächst auch RISC-V aus China. Natürlich gibt es auch die US-Halbleiterperspektive. Würden die USA, besonders nach den Problemen während Corona, zulassen, dass ein zentraler Hersteller wie Intel untergeht?
Die Lage ist nicht gut, aber der Sensationalismus ist lächerlich.
Gamer machen nur ein paar Prozent der Intel-Produktnutzer aus, aber über diese Zielgruppe hört man am meisten. Ein oder zwei Rechenzentrumsaufträge sind größer als alle Gaming-CPUs, die Intel in einem Jahr verkauft. Intel hält sich im Rechenzentrumsmarkt weiterhin gut.
Außerdem dominiert Intel weiterhin den Markt für Business-Notebooks, und auch dieser Markt ist deutlich größer als der Gamer-Markt.
Arm hatte im vergangenen Jahr im Rechenzentrumsmarkt nur 15 % Marktanteil und hat auch im Windows-Markt noch keine großen Fortschritte erzielt.
Unabhängig von den Produkten versuche ich aus Aktionärs-/Geschäftsperspektive getrennt darauf zu schauen, weil die Finanzperformance heute meiner Ansicht nach immer weniger die Endprodukte widerspiegelt; Intel halte ich für ziemlich too big to fail.
Ich möchte prüfen, ob ich es richtig verstanden habe: Gibt es zum jetzigen Zeitpunkt für alle großen Betriebssysteme Patches, die dieses Problem mitigieren oder den entsprechenden Microcode anwenden?