nccgroup/triforceaflFuzzing AFL/QEMU con emulazione completa del sistema.
Novità: per chi vuole giocare con TriforceAFL e TLSF, Richard Johnson ha creato un Dockerfile che installa entrambi (e crea persino un kernel Linux per te). È disponibile qui https://hub.docker.com/r/moflow/afl-triforce/tags/.
Altra novità: afl-tmin ora funziona con il forkserver!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Questa è una versione modificata di AFL che supporta il fuzzing a livello di intero sistema tramite QEMU. Il QEMU incluso è stato aggiornato per consentire il tracing dei branch quando si esegue un emulatore di sistema per x86_64. Sono state aggiunte istruzioni extra per avviare il forkserver di AFL, impostare le configurazioni di fuzz e marcare l'inizio e la fine dei test case.
Nota: non tutti gli strumenti di AFL sono stati testati con le nuove modifiche. Questi strumenti hanno ricevuto alcuni test:
Per compilare:
make
Per ottenere una mappa di copertura:
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Per fare fuzzing:
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Nota: a differenza dell'opzione "-Q", quando usi l'opzione "-QQ" devi specificare la riga di comando completa per afl-qemu-system-trace).
Per maggiori dettagli su come usare questa versione modificata di AFL, consulta il nostro fuzzer per syscall Linux su https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Nuovi flag di AFL: -QQ - usa qemu in emulazione a livello di intero sistema invece della modalità utente (-Q)
Nuovi flag di QEMU: -aflFile - Il nome del file contenente gli input del fuzzer -aflPanicAddr - Un indirizzo di kernel panic per il rilevamento dei panic -aflDmesgAddr - Indirizzo nel kernel Linux della funzione di logging dmesg per rilevare il logging e intercettare i messaggi di log
Nuove istruzioni QEMU: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Start AFL's fork server. After this point each test will run in a separate forked child. If enableTicks is non-zero, QEMU will re-enable the CPUs timer after forking a child, otherwise it will not be enabled. edi=2 getWork(esi=ptr, edx=sz) Fill ptr[0..sz] with the next input test case. Returns the actual size filled (<= sz). edi=3 startWork(esi=ptr) Tell AFL to start tracing. The argument points to a buffer with two quadwords giving the start and end address of the code to trace. Instructions outside of this range are not traced. edi=4 doneWork(esi=exitCode) Tell AFL that the test case has completed. If a panic is detected, AFL will stop the test case immediately. Otherwise it will run until doneWork is called. The exitCode specified is returned to AFL. (The code can, but currently does not, OR in the value 64 to all exit codes if any dmesg logs were detected during the test case.)
Nuovo block driver di QEMU: -drive filename=privmem: Questo block driver mantiene l'immagine del drive in memoria copy-on-write così che le modifiche non vengano mai persistite su disco. Le modifiche apportate da un test case sono isolate dagli altri test case.
Scritto e mantenuto da Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Tutti i diritti riservati. Rilasciato secondo i termini e le condizioni della Apache License, Versione 2.0.
Per nuove versioni e informazioni aggiuntive, consulta: http://lcamtuf.coredump.cx/afl/
Per confrontarti con altri utenti o ricevere notifiche sulle principali nuove funzionalità, invia una mail a [email protected].
** Vedi QuickStartGuide.txt se non hai tempo di leggere questo file. **
Il fuzzing è una delle strategie più potenti e collaudate per identificare problemi di sicurezza nel software reale; è responsabile della stragrande maggioranza dei bug di esecuzione di codice remoto e di escalation dei privilegi trovati finora nel software critico per la sicurezza.
Sfortunatamente, il fuzzing è anche relativamente superficiale; mutazioni casuali e cieche rendono molto improbabile raggiungere determinati percorsi di codice nel programma testato, lasciando alcune vulnerabilità completamente fuori dalla portata di questa tecnica.
Ci sono stati numerosi tentativi di risolvere questo problema. Uno dei primi approcci - ideato da Tavis Ormandy - è la distillazione del corpus. Il metodo si basa sui segnali di copertura per selezionare un sottoinsieme di seed interessanti da un corpus massiccio e di alta qualità di file candidati, per poi sottoporli a fuzzing con mezzi tradizionali. L'approccio funziona eccezionalmente bene, ma richiede che un tale corpus sia prontamente disponibile. Inoltre, le misurazioni di copertura dei blocchi forniscono una comprensione solo molto semplicistica dello stato del programma e sono meno utili per guidare lo sforzo di fuzzing nel lungo periodo.
Altre ricerche più sofisticate si sono concentrate su tecniche come l'analisi del flusso del programma ("esecuzione concolica"), l'esecuzione simbolica o l'analisi statica. Tutti questi metodi sono estremamente promettenti in contesti sperimentali, ma tendono a soffrire di problemi di affidabilità e prestazioni negli usi pratici - e attualmente non offrono un'alternativa praticabile alle tecniche di fuzzing "stupido".
American Fuzzy Lop è un fuzzer brute-force accoppiato a un algoritmo genetico estremamente semplice ma solidissimo, guidato dall'instrumentazione. Usa una forma modificata di copertura dei bordi per rilevare senza sforzo sottili cambiamenti su scala locale nel flusso di controllo del programma.
Semplificando un po', l'algoritmo complessivo può essere riassunto così:
Caricare i test case iniziali forniti dall'utente nella coda,
Prendere il file di input successivo dalla coda,
Tentare di ridurre il test case alla dimensione più piccola che non altera il comportamento misurato del programma,
Mutare ripetutamente il file usando una varietà equilibrata e ben studiata di strategie di fuzzing tradizionali,
Se una qualsiasi delle mutazioni generate ha prodotto una nuova transizione di stato registrata dall'instrumentazione, aggiungere l'output mutato come nuova voce nella coda.
Tornare al punto 2.
I test case scoperti vengono inoltre periodicamente eliminati per rimuovere quelli resi obsoleti da scoperte più recenti e con copertura maggiore; e subiscono diverse altre fasi di minimizzazione dello sforzo guidate dall'instrumentazione.
