Lahmer x86-Befehl hebelt triviale Schutzfunktion aus

Ein Einfallstor in den System Management Mode

Der System Management Mode (SMM) stellt einen der sensibelsten Bereiche moderner x86-Prozessoren dar. Da dieser Betriebsmodus über weitreichende Privilegien verfügt und beispielsweise für die Steuerung von Hardware-Energiesparfunktionen unverzichtbar ist, steht er seit Jahren im Fokus der Sicherheitsforschung. Ein erfolgreicher Zugriff auf den SMM ermöglicht Angreifern theoretisch eine vollständige Kontrolle über das System, weshalb Betriebssysteme und UEFI-Firmware den Zugriff darauf streng reglementieren.

Auf der Sicherheitskonferenz Def Con 34 präsentierte der Forscher Christopher Domas nun einen neuartigen Ansatz, um bestehende Schutzmaßnahmen des SMM gezielt auszuhebeln. Die Schwachstelle, die unter dem Namen „smiiiiiiiiiiiiiiii“ bekannt wurde, nutzt eine Schwäche im Synchronisationsprozess zwischen den CPU-Kernen aus.

Die Logik der SMM-Absicherung

Um den SMM gegen unbefugte Zugriffe zu härten, existiert ein grundlegendes Sicherheitskonzept: Wenn das System in den SMM wechselt, müssen sämtliche Prozessorkerne diesen Zustand gleichzeitig einnehmen. Die theoretische Annahme dahinter ist simpel: Befinden sich alle Kerne im SMM oder keiner, gibt es keinen „freien“ Kern, auf dem Schadsoftware laufen könnte, um den SMM während seiner aktiven Phase anzugreifen.

Dieser Synchronisationsmechanismus sieht vor, dass ein Kern, der den Wechsel in den SMM einleitet, eine entsprechende Aufforderung an alle anderen Kerne sendet. Damit das System nicht bei der Bearbeitung kritischer Aufgaben blockiert wird, ist für diesen Prozess ein Timeout von einer Sekunde definiert. Innerhalb dieses Zeitfensters sollen die anderen Kerne ihre aktuell laufenden Befehle abschließen, bevor sie in den SMM übergehen.

Ausnutzung durch extreme Latenz

Das Problem liegt in der zeitlichen Auslegung dieses Timeouts. In der Regel benötigen CPU-Kerne nur einen Bruchteil einer Millisekunde, um einen laufenden Befehl zu beenden. Christopher Domas fand jedoch einen Weg, diesen Prozess zu manipulieren, indem er gezielt Assembler-Befehle einsetzt, die eine ungewöhnlich hohe Anzahl an Taktzyklen beanspruchen.

Der Befehl `fxrstor64` dient hierbei als prominentes Beispiel: Unter spezifischen Bedingungen kann dieser auf bestimmten Prozessoren, wie dem AMD Ryzen 7 5800H, über 74 Milliarden Zyklen benötigen, was einer Laufzeit von mehr als 23 Sekunden entspricht. Durch die gezielte Ausführung eines solchen Befehls auf einem Kern lässt sich der Timeout-Mechanismus des SMM-Wechsels gezielt provozieren.

Der Ablauf des Angriffs

Der Proof-of-Concept (PoC) von Domas läuft in einer präzisen Abfolge ab:

1. Ein CPU-Kern wird mit einem extrem langwierigen Assembler-Befehl belegt, der die Ein-Sekunden-Marke überschreitet.

2. Ein zweiter Kern initiiert den Wechsel in den SMM und fordert den ersten Kern zur Teilnahme auf.

3. Da der erste Kern durch den langwierigen Befehl blockiert ist, verstreicht das einsekündige Zeitfenster.

4. Der zweite Kern schließt seine SMM-Aufgabe ab und kehrt in den normalen Modus zurück, während der erste Kern erst nach Abschluss seines Befehls in den SMM wechselt.

Das Resultat ist ein asynchroner Zustand: Ein Kern befindet sich im SMM, während mindestens ein weiterer Kern im normalen Betriebsmodus verbleibt. Auf diesem verbleibenden Kern könnte nun Schadcode ausgeführt werden, um den SMM-Prozess anzugreifen.

Einordnung und Sicherheitskontext

Obwohl die Schwachstelle „smiiiiiiiiiiiiiiii“ selbst keine CVE-Nummer trägt und für sich genommen noch keinen vollständigen Angriff darstellt, unterstreicht sie die Komplexität der SMM-Sicherheit. Laut Domas sind über 100 SMM-Schwachstellen bekannt, die durch diese Methode möglicherweise erst ausnutzbar werden. Das Angriffskonzept ist dabei an das bekannte TOCTOU-Prinzip (Time-of-Check to Time-of-Use) angelehnt.

Für die IT-Sicherheit bedeutet dies, dass die Absicherung des SMM eine ständige Herausforderung bleibt. Hersteller versuchen bereits, durch Richtlinien – etwa für Windows-zertifizierte PCs, die eine Tabelle zulässiger Adressbereiche im UEFI-BIOS vorschreiben – den Missbrauch einzuschränken. Da der Angriff jedoch stark von der Architektur und dem spezifischen CPU-Typ abhängt, bleibt die Entwicklung maßgeschneiderter Exploits eine notwendige Voraussetzung für Angreifer.