Ich hatte immer Freude an der Forschung zu Kernel-Sicherheitslücken, insbesondere am Windows-Kernel. Der Prozess umfasst immer eine Mischung aus statischer und dynamischer Analyse. Dynamische Analyse kann schnell mühsam werden. Der Zyklus Debuggen / Absturz / Neustart / Zurücksetzen aller Breakpoints ist langsam und schmerzhaft. Wenn man fuzzen möchte, muss man oft eine oder mehrere virtuelle Maschinen plus einen Kernel-Debugger einrichten und ein paar improvisierte Skripte für die Absturzerkennung basteln ...

Snapshots mit virtuellen Maschinen zu erstellen hilft, aber es ist langsam.

Im Jahr 2018 führte Microsoft eine neue API-Gruppe namens Windows Hypervisor Platform (WHVP) ein. Diese APIs ermöglichen es, eine Partition (VM in der Hyper-V-Sprache) mit einigen virtuellen Prozessoren einzurichten und die in der virtuellen Maschine auftretenden VM-Exits zu kontrollieren. Es ist fast so, als hätte man seinen eigenen VM-Exit-Handler im Userland. Ziemlich praktisch, um nützliche Dinge zu tun, zum Beispiel Simpleator oder applepie.

Also begann ich, mit WHVP zu spielen, und erstellte einen ersten PoC, der es mir ermöglichte, Shellcode in einer Hyper-V-Partition auszuführen. Er war in Python geschrieben und ziemlich langsam. Dieser erste PoC entwickelte sich ziemlich schnell zu einer Art Snapshot-basiertem Tracer. Ich wollte etwas, das die virtuelle CPU bootstrapt und ziemlich einfach einzurichten ist. Da ich bereits einen Kernel-Debugger für mein Ziel verwendete, beschloss ich, mit WinDbg erstellte Kernel-Dumps als meinen Snapshot zu verwenden. Damit musste ich nur eine Partition mit einer virtuellen CPU einrichten. Der Kontext der virtuellen CPU wird mit dem Kontext aus dem Dump gesetzt. Wann immer die virtuelle CPU eine physische Seite benötigt, verwende ich die aus dem Dump.

Damit konnte ich den Zustand des Dumps in eine Partition forken und dann die Ausführung fortsetzen. Es ermöglichte mir, die Ausführung meiner Zielfunktion einfach zu verfolgen. Durch das Ändern der Argumente und das Zurücksetzen des Speicherzustands der Partition war es auch wirklich einfach, das Ziel zu fuzzen.

Diese Arbeit wurde auf der SSTIC-Konferenz im Jahr 2020 vorgestellt und auf github veröffentlicht.

Das Tool implementiert 2 Möglichkeiten, um die Coverage zu erhalten. Die erste nutzt das klassische TF (Trap Flag), um bei jeder Anweisung INT1-Unterbrechungen zu erhalten. Es erfordert, das Ziel zu modifizieren, und es ist langsam. Ich hätte das MONITOR-Trap-Flag bevorzugt. Aber WHVP bietet diese Möglichkeit nicht.

Um eine angemessene Leistung zu erzielen (die für das Fuzzing erforderlich ist), habe ich beschlossen, die Präzision der Coverage zu reduzieren und einen Modus hinzuzufügen, bei dem man nur weiß, wann eine Anweisung zum ersten Mal ausgeführt wird.

Dazu patche ich die aus dem Snapshot geholten Seiten mit 0xcc-Bytes (nur für ausführbare Seiten). Wenn die CPU diese gepatchten Anweisungen ausführt, fängt der Hypervisor die Ausnahme ab und schreibt die Anweisungen mit dem ursprünglichen Code zurück.

Es ist, als ob auf jeder Anweisung ein einzelner Software-Breakpoint gesetzt wäre. Es funktioniert 95 % der Zeit, aber bei bestimmten Codestücken (z. B. solchen mit Sprungtabellen) schlägt es fehl, weil Daten ersetzt werden.

Um dies zu überwinden, wäre eine Option, den Code zu disassemblieren, bevor man ihn mappt, und nur das zu patchen, was benötigt wird (vielleicht beim nächsten Mal).

Während meines Experiments bin ich bei der Verwendung von WHVP auf mehrere Einschränkungen gestoßen. Es ist langsam, wirklich langsam. Der Quellcode von VirtualBox enthält einige interessante Kommentare :)

Um also eine angemessene Leistung zu erzielen, muss man VM-Exits wirklich begrenzen, und das ist inkompatibel, wenn man Hyper-V als Tracing-Hypervisor verwenden möchte (da dies viele VM-Exits erfordert).

Zur gleichen Zeit begann ich, bochs (insbesondere den Instrumentierungsteil) zu verwenden, um zu überprüfen, ob die vom Tool erhaltenen Traces korrekt waren. Bochs war eine Art Orakel, um zu sehen, ob ich divergierende Traces hatte.

Bochs ist schneller als WHVP, wenn man einen vollständigen Trace durchführt, und man hat außerdem den Vorteil, Speicherzugriffe und andere nützliche Dinge zu erhalten.

Ich habe beschlossen, Bochs als weiteres Backend hinzuzufügen. whvp war kein passender Name mehr, und ich entschied mich für rewind.

Typische Verwendung

rewind wurde um meinen eigenen Arbeitsablauf herum entwickelt, wenn ich Sicherheitsbewertungen für Kernel-Treiber auf der Windows-Plattform durchführe.

Der erste Schritt ist, die Zielsoftware in einer virtuellen Maschine zu installieren. Da ich eine Mischung aus statischer und dynamischer Analyse verwende, werde ich auch einen Kernel-Debugger einrichten.

Nachdem ich einige zufällige Treiber in IDA geöffnet habe, beginne ich schnell, einige Funktionen ins Visier zu nehmen. Dazu setze ich normalerweise einige Breakpoints mit windbg und kann, kombiniert mit ret-sync, loslegen.

Genau hier kommt rewind ins Spiel. Statt zufällige Puffer im Speicher zu bearbeiten, einzelne Schritte auszuführen und die IDB zu annotieren, um eine grobe Vorstellung davon zu bekommen, was vor sich geht, mache ich einen Snapshot mit windbg und verwende stattdessen rewind.

Das wird den Prozess erheblich erleichtern. Ein Snapshot bietet viele Vorteile. Alles ist deterministisch. Man kann einen Funktionsaufruf beliebig oft wiederholen. Man kann einen Fuzzer starten, wenn die Zielfunktion interessant aussieht. Man kann sogar die VM schließen, da sie nicht mehr benötigt wird.

Voraussetzungen

Offensichtlich benötigst du Rust (die Installation wurde unter Windows und Linux mit Rust 1.50 getestet). CMake wird ebenfalls von einigen Abhängigkeiten benötigt.

Git

Klone zuerst das Repository:

Fahre mit der Installation des Bochs-Backends fort

Bochs

Klone das Repository bochscpu (https://github.com/yrp604/bochscpu) in das vendor-Verzeichnis:

Lade die vorgebauten Bochs-Artefakte von bochscpu-build (https://github.com/yrp604/bochscpu-build) herunter

Entpacke die Ordner lib und bochs in das Bochscpu-Checkout.

WHVP

Unter Windows wird WHVP ebenfalls als Backend gebaut.

Führe in einer PowerShell-Sitzung mit Administratorrechten den folgenden Befehl aus, um zu prüfen, ob WHVP aktiviert ist:

Falls es nicht aktiviert ist, kannst du das Cmdlet Set-WindowsOptionalFeature verwenden, um es zu aktivieren. Du musst außerdem Hyper-V aktivieren.

Du benötigst außerdem ein installiertes Windows SDK (10.0.19041.0). Du kannst es von https://developer.microsoft.com/fr-fr/windows/downloads/windows-10-sdk/ herunterladen.

Aus dem Master-Branch bauen

Du musst LLVM installieren und die Umgebungsvariable LIBCLANG_PATH setzen (von bindgen benötigt). Eine detaillierte Erklärung findest du unter https://rust-lang.github.io/rust-bindgen/requirements.html.

Von dort aus solltest du rewind bauen können (nightly erforderlich wegen unwind_attributes in der bochscpu-Crate):

Die rewind-Binärdatei wird im Verzeichnis target/release verfügbar sein.

Du kannst cargo auch verwenden, um lokal zu installieren:

Häufige Build-Probleme

• wenn cmake nicht im Pfad ist, erhältst du einen Fehler beim Bauen von zydis

• wenn das Windows SDK nicht zu den unterstützten gehört, schlägt der Build von whvp-sys fehl

Beispiele

Ein grundlegendes Tutorial, das CVE-2020-17087 nutzt, findest du im Verzeichnis examples

Roadmap

Siehe TODO.md

Bekannte Fehler/Einschränkungen

• Diese Software befindet sich in einem sehr frühen Entwicklungsstadium und ist ein laufendes Experiment.
• Manchmal ist der Tracer nicht in der Lage, die Zielfunktion zu verfolgen (das häufigste Problem ist ein ungültiger Zustand der virtuellen CPU).
• Bei Verwendung des Coverage-Modus hit verhält sich der Tracer bei einigen Funktionen fehlerhaft (das ist bei einigen Switch-Tabellen der Fall). Der Grund ist, dass jedes Byte durch Software-Breakpoints ersetzt wird (einschließlich Daten, wenn sie in einer ausführbaren Seite vorhanden sind). Ein besserer Weg wäre, die Liste aller Basisblöcke beispielsweise von einem Disassembler zu erhalten.
• Die Zielfunktion wird mit einem einzigen virtuellen Prozessor ausgeführt; es gibt keine Unterstützung für Hardware, daher wird wahrscheinlich etwas schiefgehen, wenn du hardwarebezogene Funktionen verfolgst.
• Dieses Tool eignet sich am besten für die gezielte Untersuchung bestimmter Funktionen.
• Um die beste Leistung zu erzielen, minimiere VM-Exits und modifizierte Seiten, da diese wirklich kostspielig sein können und die für die Ausführung der Funktion benötigte Zeit erhöhen.
• Verwende Hyper-V nicht für Snapshots. Windows Hyper-V sind "enlightened", das heißt, sie verwenden Paravirtualisierung; dies wird derzeit nicht unterstützt.
• Einige Symbole werden nicht korrekt aufgelöst.

Lizenz

Dieses Tool wird derzeit von Quarkslab unter der Apache-2.0-Lizenz entwickelt und gesponsert.

Grüße

Ein Gruß an @yrp604, @0verclk0, Alexandre Gazet für ihre Hilfe, ihr Feedback und ihre Gedanken. Danke auch an alle meine Kollegen bei Quarkslab!