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.
Come risultato secondario del processo di fuzzing, lo strumento crea un piccolo corpus autonomo di test case interessanti. Questi sono estremamente utili per alimentare altri regimi di test che richiedono molto lavoro o risorse - ad esempio, per stress-test di browser, applicazioni da ufficio, suite grafiche o strumenti closed-source.
Il fuzzer è accuratamente testato per offrire prestazioni immediate di gran lunga superiori al fuzzing cieco o agli strumenti basati solo sulla copertura.
Quando il codice sorgente è disponibile, l'instrumentazione può essere iniettata da uno strumento compagno che funziona come sostituto diretto di gcc o clang in qualsiasi processo di build standard per codice di terze parti.
L'instrumentazione ha un impatto sulle prestazioni abbastanza modesto; in combinazione con le altre ottimizzazioni implementate da afl-fuzz, la maggior parte dei programmi può essere sottoposta a fuzzing alla stessa velocità o addirittura più velocemente rispetto agli strumenti tradizionali.
Il modo corretto per ricompilare il programma target può variare a seconda delle specifiche del processo di build, ma un approccio quasi universale sarebbe:
$ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Per i programmi C++, vorrai anche impostare CXX=/path/to/afl/afl-g++.
I wrapper clang (afl-clang e afl-clang++) possono essere usati allo stesso modo; gli utenti di clang possono anche scegliere di sfruttare una modalità di instrumentazione a prestazioni superiori, come descritto in llvm_mode/README.llvm.
Quando si testano librerie, devi trovare o scrivere un semplice programma che legga dati da stdin o da un file e li passi alla libreria testata. In tal caso, è essenziale collegare questo eseguibile a una versione statica della libreria instrumentata, oppure assicurarsi che il file .so corretto venga caricato in fase di esecuzione (di solito impostando LD_LIBRARY_PATH). L'opzione più semplice è una build statica, di solito possibile tramite:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Impostare AFL_HARDEN=1 quando si invoca 'make' farà sì che il wrapper CC abiliti automaticamente le opzioni di hardening del codice che rendono più facile rilevare semplici bug di memoria.
PS. Agli utenti di ASAN si consiglia di consultare il file notes_for_asan.txt per importanti avvertenze.
Quando il codice sorgente NON è disponibile, il fuzzer offre supporto sperimentale per l'instrumentazione rapida e al volo di binari black-box. Ciò è realizzato con una versione di QEMU che gira nella modalità meno nota di "emulazione dello spazio utente".
QEMU è un progetto separato da AFL, ma puoi comodamente compilare la funzionalità facendo:
$ cd qemu_mode $ ./build_qemu_support.sh
Per istruzioni aggiuntive e avvertenze, consulta qemu_mode/README.qemu.
Questa modalità è circa 2-5 volte più lenta dell'instrumentazione a tempo di compilazione, è meno adatta alla parallelizzazione e può presentare alcune altre stranezze.
Per funzionare correttamente, il fuzzer richiede uno o più file iniziali che contengano un buon esempio dei dati di input normalmente attesi dall'applicazione target. Ci sono due regole fondamentali:
Mantieni i file piccoli. Sotto 1 kB è l'ideale, anche se non strettamente necessario. Per una discussione sul perché la dimensione conta, vedi perf_tips.txt.
Usa più test case solo se sono funzionalmente diversi tra loro. Non ha senso usare cinquanta foto di vacanze diverse per fare fuzzing a una libreria di immagini.
Puoi trovare molti buoni esempi di file iniziali nella sottodirectory testcases/ inclusa con questo strumento.
PS. Se hai a disposizione un grande corpus di dati per lo screening, potresti voler usare l'utilità afl-cmin per identificare un sottoinsieme di file funzionalmente distinti che esercitano diversi percorsi di codice nel binario target.
Il processo di fuzzing stesso è eseguito dall'utilità afl-fuzz. Questo programma richiede una directory di sola lettura con i test case iniziali, un posto separato per archiviare i risultati e un percorso al binario da testare.
Per i binari target che accettano input direttamente da stdin, la sintassi usuale è:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
Per i programmi che ricevono input da un file, usa '@@' per indicare nella riga di comando del target la posizione in cui deve essere inserito il nome del file di input. Il fuzzer lo sostituirà per te:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
Puoi anche usare l'opzione -f per far scrivere i dati mutati in un file specifico. Questo è utile se il programma si aspetta una particolare estensione di file o simili.
I binari non instrumentati possono essere sottoposti a fuzzing in modalità QEMU (aggiungi -Q nella riga di comando) o in una modalità tradizionale da fuzzer cieco (specifica -n).
Puoi usare -t e -m per sovrascrivere il timeout e il limite di memoria predefiniti per il processo eseguito; rari esempi di target che potrebbero aver bisogno di queste impostazioni includono compilatori e decoder video.
Consigli per ottimizzare le prestazioni del fuzzing sono discussi in perf_tips.txt.
Nota che afl-fuzz inizia eseguendo una serie di passaggi di fuzzing deterministici, che possono richiedere diversi giorni. Se vuoi risultati rapidi e sporchi immediatamente, simili a zzuf o honggfuzz, aggiungi l'opzione -d alla riga di comando.
Consulta il file status_screen.txt per informazioni su come interpretare le statistiche visualizzate e monitorare lo stato di salute del processo. Assicurati di consultare questo file soprattutto se elementi dell'interfaccia sono evidenziati in rosso.
Il processo di fuzzing continuerà finché non premi Ctrl-C. Come minimo, devi permettere al fuzzer di completare un ciclo di coda, che può richiedere da un paio d'ore a una settimana circa.
All'interno della directory di output vengono create tre sottodirectory, aggiornate in tempo reale:
queue/ - test case per ogni percorso di esecuzione distintivo, più tutti i file iniziali forniti dall'utente. Questo è il corpus sintetizzato menzionato nella sezione 2.
Prima di usare questo corpus per qualsiasi altro scopo, puoi ridurlo
a una dimensione minore usando lo strumento afl-cmin. Lo strumento troverà
un sottoinsieme più piccolo di file che offrono una copertura dei bordi equivalente.
crashes/ - test case unici che causano la ricezione di un segnale fatale da parte del programma testato (ad es. SIGSEGV, SIGILL, SIGABRT). Le voci sono raggruppate per segnale ricevuto.
hangs/ - test case unici che causano il timeout del programma testato. Nota che quando sono attive le impostazioni di timeout predefinite (aggressive), questo può essere leggermente rumoroso a causa di picchi di latenza e altri fenomeni naturali.
Crash e hang sono considerati "unici" se i percorsi di esecuzione associati comportano transizioni di stato non viste in guasti registrati in precedenza. Se un singolo bug può essere raggiunto in più modi, all'inizio del processo ci sarà una certa inflazione del conteggio, ma dovrebbe attenuarsi rapidamente.
I nomi dei file per crash e hang sono correlati alle voci di coda genitrici, non faulting. Questo dovrebbe aiutare con il debug.
Quando non riesci a riprodurre un crash trovato da afl-fuzz, la causa più probabile è che non stai impostando lo stesso limite di memoria usato dallo strumento. Prova:
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Cambia LIMIT_MB per corrispondere al parametro -m passato a afl-fuzz. Su OpenBSD, cambia anche -Sv in -Sd.
Qualsiasi directory di output esistente può essere usata anche per riprendere lavori interrotti; prova:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]
Se hai gnuplot installato, puoi anche generare dei grafici carini per qualsiasi attività di fuzzing attiva usando afl-plot. Per un esempio di come appare, vedi http://lcamtuf.coredump.cx/afl/plot/.
Ogni istanza di afl-fuzz occupa all'incirca un core. Questo significa che sui sistemi multi-core la parallelizzazione è necessaria per utilizzare pienamente l'hardware. Per consigli su come fare fuzzing su un target comune su più core o più macchine in rete, consulta parallel_fuzzing.txt.
Di default, il motore di mutazione di afl-fuzz è ottimizzato per formati di dati compatti - ad esempio immagini, multimedia, dati compressi, sintassi di espressioni regolari o script di shell. È un po' meno adatto a linguaggi con una terminologia particolarmente verbosa e ridondante - in particolare HTML, SQL o JavaScript.
Per evitare la seccatura di costruire strumenti consapevoli della sintassi, afl-fuzz offre un modo per alimentare il processo di fuzzing con un dizionario opzionale di parole chiave del linguaggio, magic header o altri token speciali associati al tipo di dati target - e usarlo per ricostruire al volo la grammatica sottostante:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Per usare questa funzionalità, devi prima creare un dizionario in uno dei due formati discussi in testcases/README.testcases; poi devi indicarlo al fuzzer tramite l'opzione -x nella riga di comando.
Non c'è modo di fornire descrizioni più strutturate della sintassi sottostante, ma il fuzzer probabilmente capirà parte di questo sulla base del solo feedback dell'instrumentazione. In pratica funziona davvero, ad esempio:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS. Anche quando non viene fornito alcun dizionario esplicito, afl-fuzz proverà a estrarre i token di sintassi esistenti nel corpus di input osservando molto attentamente l'instrumentazione durante i flip di byte deterministici. Questo funziona per alcuni tipi di parser e grammatiche, ma non è neanche lontanamente buono come la modalità -x.
Il raggruppamento dei crash basato sulla copertura di solito produce un piccolo set di dati che può essere rapidamente triagato manualmente o con uno script GDB o Valgrind molto semplice. Ogni crash è anche riconducibile al suo test case genitore non crashante nella coda, rendendo più facile diagnosticare i guasti.
Detto questo, è importante riconoscere che alcuni crash del fuzzing possono essere difficili da valutare rapidamente per quanto riguarda l'exploitability senza molto lavoro di debug e analisi del codice. Per assistere in questo compito, afl-fuzz supporta una modalità molto particolare di "esplorazione dei crash" abilitata con il flag -C.
In questa modalità, il fuzzer prende uno o più test case crashanti come input e usa le sue strategie di fuzzing guidate dal feedback per enumerare molto rapidamente tutti i percorsi di codice raggiungibili nel programma mantenendolo nello stato di crash.
Le mutazioni che non risultano in un crash vengono rifiutate; così come qualsiasi modifica che non influisce sul percorso di esecuzione.
L'output è un piccolo corpus di file che può essere esaminato molto rapidamente per vedere quale grado di controllo ha l'attaccante sull'indirizzo faulting, o se è possibile superare una lettura fuori dai limiti iniziale - e vedere cosa c'è sotto.
Oh, un'altra cosa: per la minimizzazione dei test case, prova afl-tmin. Lo strumento può essere usato in modo molto semplice:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
Lo strumento funziona sia con test case crashanti che non crashanti. In modalità crash, accetta volentieri binari instrumentati e non instrumentati. In modalità non-crash, il minimizzatore si affida alla strumentazione standard di AFL per rendere il file più semplice senza alterare il percorso di esecuzione.
Il minimizzatore accetta la sintassi -m, -t, -f e @@ in modo compatibile con afl-fuzz.
Un'altra aggiunta recente ad AFL è lo strumento afl-analyze. Prende un file di input, tenta di flippare i byte in sequenza e osserva il comportamento del programma testato. Poi colora l'input in base a quali sezioni appaiono critiche e quali no; pur non essendo infallibile, può spesso offrire rapide intuizioni su formati di file complessi. Ulteriori informazioni sul suo funzionamento si trovano verso la fine di technical_details.txt.
Tieni presente che, come molte altre attività ad alta intensità di calcolo, il fuzzing può mettere a dura prova l'hardware e il sistema operativo. In particolare:
La CPU si surriscalderà e avrà bisogno di un raffreddamento adeguato. Nella maggior parte dei casi, se il raffreddamento è insufficiente o smette di funzionare correttamente, le velocità della CPU verranno automaticamente limitate. Detto questo, soprattutto quando si fa fuzzing su hardware meno adatto (laptop, smartphone, ecc.), non è del tutto impossibile che qualcosa salti in aria.
I programmi target potrebbero finire per impadronirsi in modo erratico di gigabyte di memoria o riempire lo spazio su disco con file spazzatura. AFL cerca di imporre limiti di memoria di base, ma non può prevenire ogni possibile incidente. In conclusione, non dovresti fare fuzzing su sistemi in cui la prospettiva di perdita di dati non è un rischio accettabile.- Il fuzzing comporta miliardi di letture e scritture sul filesystem. Sui sistemi moderni, questo sarà di solito ampiamente memorizzato nella cache, con un I/O "fisico" piuttosto modesto - ma ci sono molti fattori che possono alterare questa equazione. È tua responsabilità monitorare i potenziali problemi; con un I/O molto intenso, la durata di molti HDD e SSD potrebbe ridursi.
Un buon modo per monitorare l'I/O del disco su Linux è il comando 'iostat':
$ iostat -d 3 -x -k [...optional disk ID...]
Ecco alcune delle avvertenze più importanti per AFL:
AFL rileva i guasti controllando che il primo processo generato muoia a causa di un segnale (SIGSEGV, SIGABRT, ecc.). I programmi che installano handler personalizzati per questi segnali potrebbero richiedere che il codice pertinente venga commentato. Allo stesso modo, i guasti nei processi figli generati dal target sottoposto a fuzzing potrebbero sfuggire al rilevamento a meno che non si aggiunga manualmente del codice per catturarli.
Come qualsiasi altro strumento brute-force, il fuzzer offre una copertura limitata se crittografia, checksum, firme crittografiche o compressione vengono usati per avvolgere completamente il formato dati effettivo da testare.
Per aggirare il problema, puoi commentare i controlli pertinenti (vedi experimental/libpng_no_checksum/ per trarre ispirazione); se non è possibile, puoi anche scrivere un postprocessore, come spiegato in experimental/post_library/.
Ci sono alcuni compromessi sfortunati con ASAN e i binari a 64 bit. Questo non è dovuto a un difetto specifico di afl-fuzz; vedi notes_for_asan.txt per suggerimenti.
Non esiste un supporto diretto per il fuzzing di servizi di rete, demoni in background o app interattive che richiedono l'interazione con l'UI per funzionare. Potresti dover apportare semplici modifiche al codice per farli comportare in modo più tradizionale. Anche Preeny può offrire un'opzione relativamente semplice - vedi: https://github.com/zardus/preeny
Alcuni suggerimenti utili per modificare i servizi basati sulla rete si possono trovare anche su: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL non genera dati di copertura leggibili dall'uomo. Se vuoi monitorare la copertura, usa afl-cov di Michael Rash: https://github.com/mrash/afl-cov
Oltre a questo, vedi INSTALL per suggerimenti specifici per piattaforma.
Molti dei miglioramenti ad afl-fuzz non sarebbero stati possibili senza feedback, segnalazioni di bug o patch da:
Jann Horn Hanno Boeck Felix Groebert Jakub Wilk Richard W. M. Jones Alexander Cherepanov Tom Ritter Hovik Manucharyan Sebastian Roschke Eberhard Mattes Padraig Brady Ben Laurie @dronesec Luca Barbato Tobias Ospelt Thomas Jarosch Martin Carpenter Mudge Zatko Joe Zbiciak Ryan Govostes Michael Rash William Robinet Jonathan Gray Filipe Cabecinhas Nico Weber Jodie Cunningham Andrew Griffiths Parker Thompson Jonathan Neuschfer Tyler Nighswander Ben Nagy Samir Aguiar Aidan Thornton Aleksandar Nikolich Sam Hakim Laszlo Szekeres David A. Wheeler Turo Lamminen Andreas Stieger Richard Godbee Louis Dassy teor2345 Alex Moneger Dmitry Vyukov Keegan McAllister Kostya Serebryany Richo Healey Martijn Bogaard rc0r Jonathan Foote Christian Holler Dominique Pelle Jacek Wielemborek Leo Barnes Jeremy Barnes Jeff Trull Guillaume Endignoux ilovezfs Daniel Godas-Lopez Franjo Ivancic
Grazie!
Domande? Preoccupazioni? Segnalazioni di bug? L'autore è solitamente raggiungibile a [email protected].
Esiste anche una mailing list per il progetto; per iscriverti, invia un'email a [email protected]. Oppure, se preferisci prima consultare gli archivi, prova:
https://groups.google.com/group/afl-users
PS. Se desideri inviare codice sorgente da incorporare nel progetto, tieni presente che il copyright sulla maggior parte di AFL è rivendicato da Google. Sebbene tu mantenga il copyright sui tuoi contributi, chiedono comunque di accettare prima una semplice CLA:
https://cla.developers.google.com/clas
Ci scusiamo per il fastidio. Naturalmente, non è richiesta alcuna CLA per richieste di funzionalità o segnalazioni di bug.