0xricksanchez/fisy-fuzzQuesto è il framework completo di fuzzing del file system che ho presentato alla conferenza Hack in the Box 2020 Lockdown Edition ad aprile.
Questo è il framework completo di fuzzing del file system che ho presentato alla conferenza Hack in the Box 2020 Lockdown Edition ad aprile.
L'obiettivo di questo framework è scoprire bug di sicurezza del kernel su sistemi UNIX, con un forte focus sui sistemi BSD. È stato sviluppato e testato intensamente su FreeBSD, OpenBSD e NetBSD, ma ha già un supporto minore per host basati su Linux. Siamo riusciti a scoprire con successo oltre 100 bug unici del kernel per file system basati su UFS ed EXT, ottenendo anche molte informazioni sulla recente aggiunta di ZFS.
makeFS2.py può essere usato come utility standalone per generare diversi file system validi.
L'uso è spiegato in dettaglio nel repository del materiale della conferenza.
Il framework è stato testato solo su Ubuntu 18.04.
Si basa su KVM, QEMU e libvirt.
Requirements.sh configura tutte le dipendenze necessarie.
Il framework potrebbe essere completamente funzionante sull'ultima release di Ubuntu 20.04.
Altri sistemi host non basati su apt dovrebbero essere facilmente supportati e richiedono solo piccole modifiche in Requirements.sh.
Una volta soddisfatti i requisiti, puoi procedere con i passaggi di configurazione!
Fai riferimento al SETUP.md. Se alcuni passaggi non sono chiari, contattaci!
L'avvio del fuzzer richiede solo l'esecuzione di: python3 run.py.
A seconda della configurazione, potresti aver bisogno dei privilegi sudo.
Quando tutto è stato avviato con successo, puoi connetterti alla sessione tmux di fuzzing tramite:
(sudo) tmux attach-session -t fsfuzzer
Il framework può essere configurato con lo script src/config/fuzzing_config.py:
# [fuzzing task specs]
# List of dictionaries specifying each fuzzing instance
fuzzer = [
{
"name": "fuzz1", # Some name for internal bookkeeping
"fs_creator_vm": "genBox", # Name as specified in libvirt for the VM handling the file system generation, can be the same across all instances
"fuzzing_vm": "fuzzBox_0", # Name as specified in libvirt for the VM handling the file system generation
"mutation_engine": "radamsa, 0", # Mutation Engine that is to be used, and size of mutation (radamsa takes no size argument)
"target_fs": "ufs2", # Target file system
"target_size": 15, # Max file system size in Megabyte
"populate_with_files": 10, # Amount of file that will be generated
"max_file_size": 1024, # Maximum file size in bytes for each generated file
"enable_dyn_scaling": False, # Dynamic scaling will increase the filesystem size periodically
},
]
# [credentials]
# Credentials for the root user for the VMs
# It is expected that these are the same across all instances, but not necessarily root
user = "root"
pw = "root"
I motori di mutazione disponibili sono:
Il ridimensionamento dinamico è stato inizialmente implementato per testare se la dimensione di un file system influisce sui possibili crash. Non sono riuscito a identificare un valore trigger per la dimensione del file system in cui i crash cambiano, quindi questo flag può rimanere disabilitato. Ciò impedisce anche di subire un calo delle prestazioni su esecuzioni lunghe, poiché file system più grandi richiedono più tempo per essere mutati.
I restanti parametri di configurazione dovrebbero essere autoesplicativi.
Il video seguente mostra una breve demo in cui due istanze di fuzzing prendono di entrambe FreeBSD con un UFS2 mutato da radamsa e un file system EXT con byte casuali invertiti. Il file system UFS mutato porta direttamente a un crash, mostrando quanto velocemente si può far crashare un kernel.
Con questa configurazione sono riuscito a trovare oltre 100 bug unici del kernel in FreeBSD, NetBSD e OpenBSD per file system basati su UFS ed EXT. Tra questi crash, ce n'erano molti molto interessanti:
La maggior parte dei crash erano DoS del kernel. Inoltre, la maggior parte dei crash incontrati non sono ancora stati corretti ad oggi (maggio 2020). Quindi dai un'occhiata alla ricerca di bug del kernel nelle implementazioni dei file system :).
Tutto ciò è stato costruito con "trust driven development", nel senso che è cresciuto troppo e troppo in fretta partendo da una semplice idea di PoC. Di conseguenza, non ci sono nemmeno test e molto probabilmente alcuni bug. Mi dispiace se ti imbatti in crash (non legati a kernel panic), ma sentiti libero di fare una PR o contattarmi e sistemerò le cose il prima possibile!
Twitter: @0xricksanchez