Lahmer x86-Befehl hebelt triviale Schutzfunktion aus<\/p>\n
Der besondere CPU-Betriebsmodus System Management Mode (SMM) von x86-Prozessoren besch\u00e4ftigt Sicherheitsforscher seit Jahrzehnten. Sie f\u00f6rdern immer wieder neue SMM-Schwachstellen zutage. Der SMM ist ein beliebtes Ziel von Angreifern, weil Code, der in diesem Betriebsmodus l\u00e4uft, maximale Zugriffsrechte hat.<\/p>\n
Weiterlesen nach der Anzeige<\/p>\n
Auf der Def Con 34 f\u00fchrte der Sicherheitsforscher Christopher Domas alias xoreaxeaxeax vor, wie sich eine von mehreren Schutzfunktionen des SMM aushebeln l\u00e4sst. Dieser Schutz besteht darin, dass stets s\u00e4mtliche Kerne eines Prozessors gemeinsam in den SMM wechseln m\u00fcssen. Die Idee dahinter: Wenn entweder alle Kerne oder kein einziger im SMM laufen, dann bleibt kein Kern \u00fcbrig, auf dem Malware laufen kann, um SMM-Funktionen anzugreifen.<\/p>\n
Doch mit einem Proof-of-Concept (PoC) weist Domas die Schwachstelle \u201esmiiiiiiiiiiiiiiii\u201c nach. Allerdings muss der Angriffscode dabei f\u00fcr unterschiedliche CPU-Typen ma\u00dfgeschneidert sein.<\/p>\n
Offene SMM-L\u00fccken<\/p>\n
Die Schwachstelle \u201esmiiiiiiiiiiiiiiii\u201c<\/a> ist f\u00fcr sich genommen kein Angriff und hat auch keine CVE-Nummer. Christopher Domas weist jedoch darauf hin, dass mehr als 100 SMM-Schwachstellen bekannt sind, von denen sich manche nun m\u00f6glicherweise per smiiiiiiiiiiiiiiii f\u00fcr Angriffe missbrauchen lassen. Daf\u00fcr eignen sich im Prinzip Angriffe nach dem Konzept TOCTOU: Time-of-Check to Time-of-Use<\/a>.<\/p>\n Der SMM ist unverzichtbar, beispielsweise um Energiesparfunktionen (Power Management) der Hardware zu steuern.<\/p>\n Weil die Risiken des SMM seit Jahren bekannt sind, schr\u00e4nken aktuelle Betriebssysteme und UEFI-BIOS-Versionen den Zugriff darauf ein. Beispielsweise verlangt Microsoft in den Richtlinien f\u00fcr Computer mit Windows-Logo, dass das UEFI-BIOS eine Tabelle mit zul\u00e4ssigen Adressbereichen f\u00fcr SMM-Zugriffe enth\u00e4lt. Andere Zugriffe blockiert das System.<\/p>\n Weiterlesen nach der Anzeige<\/p>\n Lesen Sie auchMehr anzeigenWeniger anzeigen<\/p>\n Timeout ausgesessen<\/p>\n Der Code, mit dem das Betriebssystem die CPU in den SMM umschaltet, l\u00e4uft auf irgendeinem CPU-Kern, beispielsweise Core 1. Damit nun auch alle anderen Kerne in den SMM wechseln, schickt dieser Core 1 eine entsprechende Aufforderung an alle anderen Kerne, beispielsweise auch Core 0. Doch diese SMM-Aufforderung l\u00e4uft nach 1 Sekunde ab. Diese Wartefrist (Timeout) dient dazu, dass die anderen Kerne aktuelle Aufgaben noch erledigen k\u00f6nnen.<\/p>\n Die anderen CPU-Kerne d\u00fcrfen dabei keine neuen Maschinenbefehle annehmen, sondern nur den gerade laufenden zu Ende bringen. Das dauert normalerweise weniger als eine Millisekunde, selbst wenn ein Befehl mehrere Tausend Taktzyklen lang l\u00e4uft. Denn drei bis vier Gigahertz Taktfrequenz entsprechen drei bis vier Milliarden Taktzyklen pro Sekunde beziehungsweise drei bis vier Millionen pro Millisekunde.<\/p>\n Chris Domas missbraucht diesen Timeout: Er suchte einen Assembler-Befehl, der extrem lange l\u00e4uft. Dazu rief er den nicht ganz ernstgemeinten Wettbewerb \u201eHall of Shame der (x86-)Assemblerbefehle\u201c<\/a> ins Leben. Spitzenreiter ist der unter bestimmten Randbedingungen aufgerufene Befehl fxrstor64, der auf einem AMD Ryzen 7 5800H mehr als 74 Milliarden CPU-Zyklen fra\u00df, was mehr als 23 Sekunden dauerte.<\/p>\n SMM angreifbar<\/p>\n Der PoC von Domas besteht also grob gesagt darin, dass er zuerst einen beliebigen CPU-Kern mit einem Assemblerbefehl besch\u00e4ftigt, der mehr als eine Sekunde lang l\u00e4uft. Sofort danach wird ein anderer CPU-Kern angewiesen, in den SMM zu wechseln, wodurch dieser den erstgenannten Kern auffordert, das ebenfalls zu tun. Der zweite Kern wartet nun auf den ersten.<\/p>\n Nach einer Sekunde beendet der zweite Kern seine Wartezeit, erledigt seine Aufgabe im SMM und wechselt in den normalen Betriebsmodus zur\u00fcck. Der erste Kern jedoch schaltet in den SMM um, sobald seine \u201eBesch\u00e4ftigungsaufgabe\u201c beendet ist. Damit tritt die fatale Situation ein, dass ein Kern im SMM l\u00e4uft, mindestens ein weiterer jedoch nicht. Auf letzterem k\u00f6nnte nun Malware laufen.<\/p>\n Christopher Domas ver\u00f6ffentlichte 2017 das Fuzzing-Tool Sandsifter<\/a> zur Untersuchung undokumentierter Befehle von x86-Prozessoren. Damit entdeckte er 2018 in alten VIA-Prozessoren die Sicherheitsl\u00fccke Rosenbridge<\/a>. Gemeinsam mit seiner Frau Stephanie Domas betreibt er das Unternehmen Dazzle Cat Duo<\/a>.<\/p>\n