Snapchange

Leichtgewichtiges Fuzzing eines Speicher-Snapshots mit KVM

Snapchange bietet die Möglichkeit, einen rohen Speicherdump und den Registerzustand in eine KVM-Virtual Machine (VM) zur Ausführung zu laden. An einem bestimmten Punkt der Ausführung kann diese VM in ihren Ausgangszustand zurückversetzt werden, indem die von KVM gefundenen Dirty Pages oder die von einem Fuzzer manuell als dirty markierten Seiten zurückgesetzt werden.

Schnellzugriff:

• Kochbuch bietet Beispiele für die Befehlszeilenprogramme fuzz, trace, coverage, minimize und project
• Erstellen eines Snapshots mit QEMU
• Architektur
• Lebenszyklus des Fuzzers

Tutorials

• Tutorial 1 – Grundlegende Verwendung
• Tutorial 2 – LibTIFF mit ASAN
• Tutorial 3 – FFmpeg mit benutzerdefiniertem Mutator
• Tutorial 4 – Syscall-Fuzzer
• Tutorial 5 – Redqueen

Ziele

• Wiedergabe (Replay) eines Snapshots des physischen Speichers und des Registerzustands mittels KVM
• Parallele Ausführung über mehrere Kerne
• Bereitstellung einer Reihe von Introspectionsfunktionen für die Gast-VM
• Echtzeit-Coverage-Status durch Breakpoint-Coverage
• Echtzeit-Leistungsmetriken der Fuzzer-Komponenten
• Bereitstellung von Fuzzing-Dienstprogrammen wie Single-Step-Debug-Tracing, Testfall-Minimierung und Testfall-Coverage
• Eingabeabstraktion zur Ermöglichung benutzerdefinierter Mutations- und Generierungsstrategien

Beispiel:

Erstellen eines Ziel-Fuzzers aus der Fuzzer-Vorlage

$ cp -r -L fuzzer_template your_new_fuzzer

Ändern Sie your_new_fuzzer/create_snapshot.sh, um einen Snapshot Ihres Ziels zu erstellen

Aktualisieren Sie src/fuzzer.rs, um mutierte Daten in die Gast-VM einzuspeisen

#[derive(Default)]
pub struct TemplateFuzzer;

impl Fuzzer for TemplateFuzzer {
    // The type of Input being fuzzed. Used to know how to generate and mutate useful inputs.
    type Input = Vec<u8>;
    // The starting address of the snapshot
    const START_ADDRESS: u64 = 0x402363;
    // The maximum length of mutated input to generate
    const MAX_INPUT_LENGTH: usize = 100;

    fn set_input(&mut self, input: &Self::Input, fuzzvm: &mut FuzzVm<Self>) -> Result<()> {
        // Write the mutated input into the data buffer in the guest VM
        fuzzvm.write_bytes_dirty(VirtAddr(0x402004), CR3, &input)?;
        Ok(())
    }

    fn reset_breakpoints(&self) -> Option<&[BreakpointLookup]> {
        Some(&[
            // Reset when the VM hits example1!main+0x123
            BreakpointLookup::SymbolOffset("example1!main", 0x123)
        ])
    }
}

Fuzzing mit 16 Kernen starten

$ cargo run -r -- fuzz -c 16

Implementierung

Kurzüberblick über die in diesem README verwendeten Begriffe:

• Hypervisor: Der zielunabhängige Code, der den Snapshot in KVM ausführt
• Fuzzer: Der zielspezifische Code, der verwendet wird, um den Gast für einen zielspezifischen Fuzz-Fall zu modifizieren und zu überwachen

Der Hypervisor beginnt damit, die physische Speicherdatei für jeden angeforderten Kern abzubilden. Auf diese Weise besitzt jeder Kern seine eigene, eindeutige Kopie des Speichers. Anschließend erstellt der Hypervisor den KVM-Gast und übergibt diesem Gast den zugrunde liegenden Speicher. Der Registerzustand dieses Gasts wird dann mit dem angegebenen Registerzustand initialisiert und die Ausführung des Gasts gestartet. Der Hypervisor wartet, bis der Gast ein Exit auslöst. Jeder Exit wird vom Hypervisor behandelt und einige werden an den Fuzzer zur zielspezifischen Mutation, Modifikation oder Introspection weitergegeben. Wenn der Handler des Exits anzeigt, dass der Gast zurückgesetzt werden soll, verlässt der Hypervisor die Run-Loop, setzt den Gast zurück in den ursprünglichen Snapshot-Zustand und startet die Run-Loop erneut.

Das Coverage des Gasts wird mithilfe von Coverage-Breakpoints erzeugt. Eine separate Datei mit einer Liste von Adressen, an denen Breakpoints gesetzt werden sollen, kann dem Hypervisor übergeben werden. Wenn eine dieser Adressen erreicht wird, wird die Adresse zur Coverage-Datenbank hinzugefügt und die Anweisung für diese Adresse wiederhergestellt. Auf diese Weise wird der Breakpoint nicht erneut ausgelöst.

Projektverzeichnis

Snapchange nutzt zielspezifische Projektverzeichnisse für die Konfiguration. In diesem Verzeichnis werden Eingabe- und Ausgabedateien sowie -verzeichnisse abgelegt. Die folgenden Dateierweiterungen/-verzeichnisse werden als Eingaben verwendet:

• .physmem – Die Datei, die die rohe, physische Speicherdatei enthält
• Registerdatei (eine der folgenden)
  • .regs – JSON-Registerdatei, die den Registerzustand enthält
  • .qemuregs – Ausgabe von info registers aus qemu

Die vollständige Liste der Dateien und ihrer Verwendung im Projektverzeichnis finden Sie hier

Debugging-Trace

Ein vollständiges Beispiel für das Debugging-Single-Step-Trace finden Sie hier.

ITERATION 604 0x00007ffff7ecb0d5 0x11115000 | libc-2.31.so!__GI___getpid+0x5 (0x7ffff7ecb0d5)              
    syscall 
    [0f, 05]
ITERATION 605 0xffffffff83a00000 0x11115000 | entry_SYSCALL_64+0x0 (0xffffffff83a00000)                    
    swapgs 
    [0f, 01, f8]
ITERATION 606 0xffffffff83a00003 0x11115000 | entry_SYSCALL_64+0x3 (0xffffffff83a00003)                    
    mov qword ptr gs:[0xa014], rsp 
    [None:0x0+0xa014=0xa014]] 
    RSP:0x7fffffffeb78 -> example1!main+0x19 (0x55555555514e)-> 0xff8458b48f44589
    [65, 48, 89, 24, 25, 14, a0, 00, 00]
ITERATION 607 0xffffffff83a0000c 0x11115000 | entry_SYSCALL_64+0xc (0xffffffff83a0000c)                    
    nop 
    [66, 90]
ITERATION 608 0xffffffff83a0000e 0x11115000 | entry_SYSCALL_64+0xe (0xffffffff83a0000e)                    
    mov rsp, cr3 
    RSP:0x7fffffffeb78 -> example1!main+0x19 (0x55555555514e) -> 0xff8458b48f44589
    CR3:0x11115000
    [0f, 20, dc]

Snapshots

Informationen zum Erstellen eines Snapshots über VirtualBox oder QEMU finden Sie unten:

• VirtualBox
• QEMU

Die Beispiele enthalten ein make_example.sh-Skript (wie Beispiel 1), das einen vollständigen Snapshot von Grund auf erstellt. Diese Beispiele können als Vorlage für andere Ziele verwendet werden, um reproduzierbare Snapshots zu erstellen.

Dokumentation und Clippy

make all
cargo doc --open

Wo beginne ich mit dem Lesen?

Die Datei HACKING bietet einige übergeordnete Einstiegspunkte in die Codebasis, um das System zu verstehen.

Sicherheit

Weitere Informationen finden Sie unter CONTRIBUTING.

Lizenz

Dieses Projekt ist unter der Apache-2.0-Lizenz lizenziert.