TriforceLinuxSyscallFuzzer

• 20160613
• https://github.com/nccgroup/TriforceLinuxSyscallFuzzer
• Jesse Hertz [email protected]
• Tim Newsham [email protected]

Novità: per chi vuole giocare con TriforceAFL e TLSF, Richard Johnson ha creato un Dockerfile che installa entrambi (e compila persino un kernel Linux per voi). È disponibile qui https://hub.docker.com/r/moflow/afl-triforce/tags/.

Questa è una raccolta di file usati per eseguire il fuzzing delle system call dei kernel Linux x86_64 usando AFL e QEMU. Per usarla avrete bisogno di TriforceAFL da https://github.com/nccgroup/TriforceAFL e di un'immagine del kernel da sottoporre a fuzzing. Gli script assumono che TriforceAFL si trovi in $TAFL o ../TriforceAFL/ (N.B. la compilazione di testAfl richiede che ../TriforceAFL/config.h esista).

Compilazione

Per compilare:

  make

Fuzzing

Per eseguire, installate prima un kernel in ./kern/bzImage ed estrarre /proc/kallsyms in ./kern/kallsyms. Impostate la variabile d'ambiente K=kern per puntare al vostro kernel. Poi eseguite:

  make inputs
  ./runFuzz -M M0

Nota: lo script runFuzz si aspetta un nome master o slave, poiché viene eseguito sempre in modalità master/slave. Consultate lo script runFuzz per maggiori informazioni sull'uso.

Notare anche che questo crea solo un piccolo insieme di input di esempio. Per testare un gran numero di system call importanti, probabilmente vorrete generare un esempio per ogni system call, o almeno un esempio per ogni "forma" di system call. Questi dovrebbero essere inseriti in inputs/. Vedere gen2.py per un esempio.

Riproduzione

Per riprodurre i casi di test (come i crash) eseguite:

  ./runTest inputs/ex1
  ./runTest outputs/crashes/id*

Potete anche eseguire il driver fuori dall'ambiente emulato con l'opzione -t, con logging verbose con -vv e senza eseguire effettivamente le system call con -x:

  ./driver -tvvx < inputs/ex1
  strace ./driver -t < inputs/ex1

A volte è utile poter avviare il kernel ed eseguire test in modo interattivo. Per farlo, modificate i file rootTemplate come preferite (per esempio, per aggiungere più strumenti di test al filesystem di root), quindi eseguite:

  ./runCmd

Altri comandi oltre alla shell possono essere invocati specificandoli come argomenti della riga di comando di runCmd. Nota: quando avete finito con la shell, usate ^A-c per ottenere il prompt di QEMU e digitate quit.

Debug

Il debug è più semplice con un kernel compilato con i simboli di debug abilitati. Usate runTest per avviare il kernel ed eseguire un test tramite il driver, oppure usate runCmd per eseguire manualmente un caso di test dalla shell. Modificate il vostro script di esecuzione per includere l'opzione -s quando avviate afl-qemu-system-trace. Questo abiliterà il supporto gdb sulla porta TCP 1234. Usate getvmlinux per estrarre l'immagine del kernel vmlinux dal vostro kernel bzImage ed eseguite gdb dopo che il sistema è stato avviato:

   cp kern/bzImage .
   ./getvmlinux
   gdb ./vmlinux
   target remote :1234
   break somefunction
   continue

Potete collegare il debugger dopo che runTest ha causato un crash o prima di attivare manualmente il bug in runCmd.

Nota che i sorgenti Linux sono compilati con l'ottimizzazione attivata per impostazione predefinita. Questo può rendere il debug confuso e difficile. Potete disabilitare l'ottimizzazione file per file modificando il make file di Linux per la sottodirectory in cui si trova un file e aggiungendo CFLAGS_name.o = -O0 al Makefile. Per esempio, modificando kernel/Makefile e aggiungendo CFLAGS_sys_ni.o = -O0 disabiliterete l'ottimizzazione quando compilate kernel/sys_ni.o.

Utility

Lo script shell getSyms usa runCmd per eseguire cat /proc/kallsyms ed estrarlo in un file locale chiamato kallsyms. Questo viene tipicamente usato per preparare il vostro kernel per il fuzzing:

• eseguite K=yourKernDir ./getSyms per ottenere kallsyms
• eseguite mv kallsyms yourKernDir per installarlo

Bug

Nota: quando si esegue il fuzzing di un kernel Linux 2.* dovrete abilitare il timer della CPU. Quando il timer non è abilitato, il rilevamento di panic e logging non sembra funzionare correttamente e i panic causano hang. Per abilitare il timer, chiamate startForkserver(1) in driver.c invece di startForkserver(0). Questo problema non sembra verificarsi nei kernel Linux 3.* e Linux 4.*.