0xricksanchez/fisy-fuzzDies ist das vollständige Dateisystem-Fuzzing-Framework, das ich auf der Hack in the Box 2020 Lockdown Edition Konferenz im April vorgestellt habe.
Dies ist das vollständige Dateisystem-Fuzzing-Framework, das ich auf der Hack in the Box 2020 Lockdown Edition Konferenz im April vorgestellt habe.
Das Ziel dieses Frameworks ist es, Kernel-Sicherheitslücken auf UNIX-Systemen aufzudecken, mit einem starken Fokus auf BSD-Systeme. Es wurde entwickelt und intensiv gegen FreeBSD, OpenBSD und NetBSD getestet, bietet aber auch bereits eine geringe Unterstützung für Linux-basierte Hosts. Wir konnten erfolgreich über 100 einzigartige Kernel-Fehler für UFS- und EXT-basierte Dateisysteme aufdecken und dabei auch viele Einblicke in die kürzlich hinzugekommene Unterstützung von ZFS gewinnen.
Das makeFS2.py kann als eigenständiges Hilfsprogramm verwendet werden, um verschiedene gültige Dateisysteme zu erzeugen.
Die Verwendung wird im Konferenz-Material-Repo detailliert erklärt.
Das Framework wurde ausschließlich unter Ubuntu 18.04 getestet.
Es basiert auf KVM, QEMU und libvirt.
Die Requirements.sh richtet alle notwendigen Abhängigkeiten ein.
Das Framework könnte unter der aktuellen Ubuntu 20.04 Version voll funktionsfähig sein.
Andere nicht apt-basierte Host-Systeme sollten leicht unterstützt werden können und erfordern nur geringfügige Änderungen in der Requirements.sh.
Sobald die Anforderungen erfüllt sind, können Sie mit den Einrichtungsschritten fortfahren!
Siehe SETUP.md. Falls einige Schritte unklar sind, wenden Sie sich bitte an uns!
Das Starten des Fuzzers erfordert nur die Ausführung von: python3 run.py.
Abhängig von Ihrer Einrichtung benötigen Sie möglicherweise sudo-Berechtigungen.
Wenn alles erfolgreich gestartet wurde, können Sie sich mit folgendem Befehl mit der tmux-Fuzzing-Sitzung verbinden:
(sudo) tmux attach-session -t fsfuzzer
Das Framework kann mit dem Skript src/config/fuzzing_config.py konfiguriert werden:
# [fuzzing task specs]
# Liste von Wörterbüchern, die jede Fuzzing-Instanz spezifizieren
fuzzer = [
{
"name": "fuzz1", # Ein Name für die interne Buchhaltung
"fs_creator_vm": "genBox", # Name, wie in libvirt für die VM angegeben, die die Dateisystemerzeugung übernimmt, kann über alle Instanzen hinweg gleich sein
"fuzzing_vm": "fuzzBox_0", # Name, wie in libvirt für die VM angegeben, die die Dateisystemerzeugung übernimmt
"mutation_engine": "radamsa, 0", # Mutations-Engine, die verwendet werden soll, und Größe der Mutation (radamsa benötigt kein Größenargument)
"target_fs": "ufs2", # Ziel-Dateisystem
"target_size": 15, # Maximale Dateisystemgröße in Megabyte
"populate_with_files": 10, # Anzahl der Dateien, die erzeugt werden
"max_file_size": 1024, # Maximale Dateigröße in Bytes für jede erzeugte Datei
"enable_dyn_scaling": False, # Dynamische Skalierung erhöht periodisch die Dateisystemgröße
},
]
# [credentials]
# Anmeldeinformationen für den Root-Benutzer der VMs
# Es wird erwartet, dass diese über alle Instanzen hinweg gleich sind, aber nicht unbedingt root
user = "root"
pw = "root"
Die verfügbaren Mutations-Engines sind:
Dynamische Skalierung wurde ursprünglich implementiert, um zu testen, ob die Größe eines Dateisystems die möglichen Abstürze beeinflusst. Ich konnte keinen Auslöserwert für die Dateisystemgröße identifizieren, bei dem sich Abstürze ändern, daher kann dieses Flag deaktiviert bleiben. Dies verhindert auch eine Leistungseinbuße bei längeren Läufen, da größere Dateisysteme länger zum Mutieren benötigen.
Die restlichen Konfigurationsparameter sollten selbsterklärend sein.
Das folgende Video zeigt eine schnelle Demo, bei der zwei Fuzzing-Instanzen beide auf FreeBSD mit einem radamsa-mutierten UFS2 und einem zufällig byte-gefippten EXT-Dateisystem abzielen. Das mutierte UFS-Dateisystem führt direkt zu einem Absturz und zeigt, wie schnell man einen Kernel zum Absturz bringen kann.
Mit diesem Setup konnte ich über 100 einzigartige Kernel-Fehler in FreeBSD, NetBSD und OpenBSD für UFS- und EXT-basierte Dateisysteme finden. Unter diesen Abstürzen gab es eine Reihe sehr interessanter:
Die Mehrheit der Abstürze waren Kernel-DoS. Darüber hinaus sind die meisten der aufgetretenen Abstürze bis heute (Mai 2020) noch nicht behoben. Also ran an die Kernel-Fehler in Dateisystem-Implementierungen! :)
Dieses ganze Ding wurde mit 'Trust Driven Development' gebaut, was bedeutet, dass es aus einer reinen PoC-Idee viel zu schnell viel zu groß geworden ist. Daher gibt es auch keine Tests und höchstwahrscheinlich ein paar Fehler. Es tut mir leid, falls Sie auf Abstürze stoßen (die nicht mit Kernel Panic zusammenhängen), aber fühlen Sie sich frei, einen PR zu machen oder mich zu kontaktieren, und ich werde die Dinge so schnell wie möglich beheben!
Twitter: @0xricksanchez