Wir vertrauen Software seit langem nicht mehr und führen daher ihre Prüfung durch, führen Reverse Engineering durch, führen sie Schritt für Schritt aus und führen sie in der Sandbox aus. Was ist mit dem Prozessor, auf dem unsere Software läuft? - Wir vertrauen blind und von ganzem Herzen diesem kleinen Stück Silikon. Moderne Hardware hat jedoch dieselben Probleme wie Software: geheime undokumentierte Funktionen, Fehler, Schwachstellen, Malware, Trojaner, Rootkits und Hintertüren.
ISA (Instruction Set Architecture) x86 ist eine der am längsten sich ständig ändernden „Befehlssatzarchitekturen“ in der Geschichte. Beginnend mit dem 1976 entwickelten 8086-Design wird ISA ständig geändert und aktualisiert. unter Beibehaltung der Abwärtskompatibilität und Unterstützung für die ursprüngliche Spezifikation. In über 40 Jahren ist die ISA-Architektur gewachsen und wächst mit vielen neuen Modi und Anweisungssätzen weiter, von denen jeder dem bereits überlasteten vorherigen Design eine neue Ebene hinzufügt. Aufgrund der vollständigen Abwärtskompatibilität enthalten moderne x86-Prozessoren sogar Anweisungen und Modi, die bereits vollständig vergessen wurden. Als Ergebnis haben wir eine Prozessorarchitektur, die ein komplexes Labyrinth aus neuen und antiken Technologien darstellt. Eine solch äußerst komplexe Umgebung verursacht viele Probleme mit der Cybersicherheit des Prozessors. Daher können x86-Prozessoren nicht behaupten, die vertrauenswürdige Wurzel einer kritischen Cyberinfrastruktur zu sein.
Vertrauen Sie Ihrem Prozessor immer noch?
Sicherheit von Programmen und Betriebssystemen - basiert auf der Sicherheit der Hardware, auf der sie bereitgestellt werden. Softwareentwickler berücksichtigen in der Regel nicht, dass die Hardware, auf der ihre Software bereitgestellt wird, nicht vertrauenswürdig und böswillig sein kann. Wenn sich Hardware (absichtlich oder nicht) fehlerhaft verhält, werden Software-Sicherheitsmechanismen völlig wertlos. Seit vielen Jahren werden verschiedene Modelle sicherer Prozessoren angeboten: Intel SGX, AMD Pacifica usw. Dennoch führt die beneidenswerte Regelmäßigkeit, mit der Informationen über kritische Fehler (von neueren, z. B. Meltdown und Spectre) veröffentlicht und undokumentierte "Debugging" -Funktionen erkannt werden, dazu Der Gedanke, dass unser volles Vertrauen in Prozessoren unbegründet ist.
Moderne x86-Prozessoren sind eine sehr umständliche und komplizierte Verflechtung der neuesten und antiken Technologien. 8086 hatte 29.000 Transistoren, Pentium 3 Millionen, Broadwell 3,2 Milliarden, Cannonlake mehr als 10 Milliarden.
Bei so vielen Transistoren ist es nicht verwunderlich, dass moderne x86-Prozessoren mit undokumentierten Anweisungen und Hardware-Schwachstellen übersät sind. Unter den undokumentierten, die fast zufällig entdeckt wurden, befinden sich Anweisungen: ICEBP (0xF1), LOADALL (0x0F07), apicall (0x0FFFF0) [1], mit denen der Prozessor für den unbefugten Zugriff auf geschützte Speicherbereiche entsperrt werden kann.
Die zahlreichen Hardware-Schwachstellen von Prozessoren (siehe zwei Abbildungen unten) ermöglichen es einem Cyber-Angreifer, Berechtigungen zu eskalieren [3], kryptografische Schlüssel zu extrahieren [4], neue Assembler-Anweisungen zu erstellen [2] und die Funktionalität bereits vorhandener Assembler-Anweisungen zu ändern [2]. , installieren Sie Hooks in Assembler-Anweisungen [2], übernehmen Sie die Kontrolle über die „hardwarebeschleunigte Virtualisierung“ [7], greifen Sie in „atomare kryptografische Berechnungen“ ein [7] und wechseln Sie schließlich in den „Gott-Modus“: ive selbst ein legitimes Hardware Intel ME-Backdoor. [8] (die Sie Remote-Zugriff auch der Computer ausgeschaltet empfangen können) Und das alles - ohne digitale Spuren zu hinterlassen.
Moderne Prozessoren sind mehr Software als Hardware
Genau genommen können moderne Prozessoren nicht einmal als "Hardware" im wahrsten Sinne des Wortes bezeichnet werden. Weil ihre wichtigste Funktionalität (einschließlich ISA) durch das Flashen des Mikrocodes bereitgestellt wird. Anfänglich war der Mikrocode hauptsächlich für die Steuerung der Decodierung und Ausführung komplexer Assembler-Anweisungen verantwortlich: Gleitkommaoperationen, MMX-Grundelemente, Zeilenhandler mit dem REP-Präfix usw. Mit der Zeit wird dem Mikrocode jedoch immer mehr Verantwortung für Verarbeitungsvorgänge innerhalb des Prozessors zugewiesen. Beispielsweise werden moderne Erweiterungen von Intel-Prozessoren wie AVX (Advanced Vector Extensions) und VT-d (Hardware-Virtualisierung) auf Mikrocode implementiert.
Darüber hinaus ist der Mikrocode heute unter anderem dafür verantwortlich, den Status des Prozessors aufrechtzuerhalten, den Cache zu verwalten und auch Energie zu sparen. Um Energie zu sparen, implementiert der Mikrocode einen Interrupt-Mechanismus, der Leistungszustände verarbeitet: C-Zustand (Grad des Energiesparschlafes: vom aktiven Zustand zum Tiefschlaf) und P-Zustand (verschiedene Kombinationen von Spannung und Frequenz). So ist beispielsweise der Mikrocode dafür verantwortlich, den L2-Cache beim Eintritt in den Zustand C4 sowie beim Verlassen zurückzusetzen.
Warum verwenden Prozessorhersteller Mikrocode?
Hersteller von x86-Prozessoren verwenden Mikrocode, um komplexe Montageanweisungen (die bis zu 15 Byte lang sein können) in eine Kette einfacher Mikroanweisungen zu zerlegen, um die Hardwarearchitektur zu vereinfachen und die Diagnose zu erleichtern. Tatsächlich ist der Mikrocode ein Interpreter zwischen der externen (für den Benutzer sichtbaren) CISC-Architektur und der internen (Hardware-) RISC-Architektur.
Wenn in der CISC-Architektur (hauptsächlich in ISA) Fehler festgestellt werden, veröffentlichen die Hersteller ein Mikrocode-Update, das über das BIOS / UEFI des Motherboards oder über das Betriebssystem (während des Startvorgangs) auf den Prozessor heruntergeladen werden kann. Dank eines solchen auf Mikrocodes basierenden Update-Systems bieten sich Prozessorhersteller Flexibilität und Kostenreduzierung - und beheben gleichzeitig Fehler in ihren Geräten. Der sensationelle Fehler bei fdiv, der 1994 Intel Pentium-Prozessoren schwer zum Erliegen brachte, machte die Tatsache, dass High-Tech-Hardwarefehler genau wie Software anfällig sind, noch deutlicher. Dieser Vorfall hat die Hersteller noch mehr an der Architektur von Mikrocode-basierten Prozessoren interessiert. Daher begannen Intel und AMD, ihre Prozessoren mithilfe der Mikrocode-Technologie zu bauen. Intel - beginnend mit dem Pentium Pro (P6), der 1995 veröffentlicht wurde. AMD - beginnend mit dem K7, der 1999 veröffentlicht wurde.
Alles Geheimnis wird klar
Trotz der Tatsache, dass Prozessorhersteller versuchen, die Architektur von Mikrocodes und den Mechanismus für deren Aktualisierung streng vertraulich zu behandeln, schläft der Feind nicht. Fragmentierte Informationen (hauptsächlich aus Patenten wie AMD RISC86 [5]) und die sorgfältige Umkehrung offizieller BIOS-Updates (wie bei K8 [6]) werfen nach und nach Licht in das Geheimnis des Mikrocodes (siehe z. B. in der folgenden Abbildung). AMD-Prozessor-Mikrocode-Aktualisierungsmechanismus “). Und dank der ständigen Weiterentwicklung der Reverse Engineering-Tools (sowohl Software als auch Hardware) [2], vielversprechender Fuzzing-Techniken [1] und der Einführung von OpenSource-Tools wie Microparse [9] und Sandsifter [10] kann ein Cyber-Angreifer alles über einen Mikrocode lernen, der für erforderlich ist Mikrocode-Malware darauf schreiben müssen.
So zum Beispiel in [2] als "Hallo Welt!" (der erste Schritt zum Trojanisieren des Mikrocodes) Es wurde ein „Mikrohaken“ (Mikrocode-Programm, das den Assembler-Befehl abfängt) entwickelt, der zählt, wie oft der Prozessor auf den Befehl div zugegriffen hat. Dieser Mikrohaken ist eine Injektion in den Handler des Assembler-Befehls div.
Ebenda [2] stellt einen fortgeschritteneren Mikrohook vor, der leise in der Assembler-Anweisung des div ebx sitzt, keine Präsenz ausgibt und nur aktiviert wird, wenn beim Zugriff auf das ebx div bestimmte Bedingungen erfüllt sind: Das ebx-Register enthält den Wert B und das Register eax enthält den Wert A. Bei Aktivierung erhöht dieser Mikrohook den Wert des eip-Registers (aktueller Befehlszeiger) um eins. Infolgedessen wird die Ausführung des Programms (das den Mut hatte, auf die Anweisung div ebx zu verweisen) mit einem Offset fortgesetzt: nicht ab dem ersten Byte des Befehls nach div ebx, sondern ab seinem zweiten Byte. Wenn in den Registern eax und ebx andere Werte angegeben sind, funktioniert das ebx div wie gewohnt. Was ist der praktische Wert dabei? Zum Beispiel, um eine verborgene Kette von Assembler-Anweisungen leise zu aktivieren, wenn Verschleierungstechniken mit „überlappenden Anweisungen“ verwendet werden [11].
Diese beiden Beispiele zeigen, wie legitime Assembler-Anweisungen verwendet werden können, um beliebigen Trojaner-Code darin zu verbergen.
Gleichzeitig kann ein Cyber-Angreifer seine böswillige Nutzlast aktivieren - auch aus der Ferne. Zum Beispiel, wenn die für die Aktivierung erforderliche Bedingung auf einer von einem Angreifer kontrollierten Webseite erfüllt ist. Dies ist dank der in modernen Webbrowsern integrierten Just-in-Time-Compiler (JIT) und Ahead-of-Time-Compiler (AOT) möglich. Mit diesen Compilern können Sie einen vordefinierten Strom von Assembler-Anweisungen für Maschinencode ausgeben - auch wenn Sie das Programm ausschließlich in JavaScript auf hoher Ebene schreiben (siehe die letzte Auflistung oben).