Fuzzing di sistemi embedded utilizzando breakpoint hardware
Questo è il codice di supporto per l'articolo: 'Fuzzing di Sistemi Embedded tramite Interfacce di Debugger'. Una prestampa dell'articolo è disponibile qui https://publications.cispa.saarland/3950/. Il codice consente agli utenti di riprodurre ed estendere i risultati riportati nell'articolo. Si prega di citare il suddetto articolo quando si riportano, riproducono o estendono i risultati.
.
├── benchmark # Script per compilare la suite di test di Google e per eseguire gli esperimenti
├── dependencies # Contiene un Makefile per installare le dipendenze di GDBFuzz
├── evaluation # Dati grezzi degli esperimenti, presentati nell'articolo
├── example_firmware # Applicazioni embedded di esempio, utilizzate per la valutazione
├── example_programs # Contiene un programma di esempio compilato e le configurazioni per testare GDBFuzz
├── src # Contiene l'implementazione di GDBFuzz
├── Dockerfile # Per creare un'immagine Docker con tutte le dipendenze di GDBFuzz installate
├── LICENSE # Licenza
├── Makefile # Makefile per creare l'immagine docker o installare GDBFuzz localmente
└── README.md # Questo file README
L'idea di GDBFuzz è sfruttare i breakpoint hardware dei microcontrollori come feedback per il fuzzing guidato dalla copertura del codice. A tale scopo, GDB viene utilizzato come interfaccia generica per garantire un'ampia applicabilità. Per l'analisi binaria del firmware viene utilizzato Ghidra. Il codice contiene un setup di benchmark per valutare il metodo. Inoltre, sono inclusi file firmware di esempio.
GDBFuzz consente il fuzzing guidato dalla copertura per sistemi embedded, ma - a fini di valutazione - può anche eseguire fuzzing su applicazioni utente arbitrarie. Per il fuzzing su microcontrollori, consigliamo un'installazione locale di GDBFuzz per poter inviare dati di input al dispositivo in test senza problemi.
GDBFuzz è stato testato su Ubuntu 20.04 LTS e Raspberry Pi OS a 32 bit. I prerequisiti sono java e python3. Per prima cosa, creare un nuovo ambiente virtuale e installare tutte le dipendenze.
virtualenv .venv
source .venv/bin/activate
make
chmod a+x ./src/GDBFuzz/main.py
GDBFuzz legge le impostazioni da un file di configurazione con le seguenti chiavi.
[SUT]
# Percorso del file binario del SUT.
# Può essere, ad esempio, un file .elf o .bin.
binary_file_path = <percorso>
# Indirizzo del nodo radice del CFG.
# I breakpoint vengono posizionati sui nodi di questo CFG.
# es. 'LLVMFuzzerTestOneInput' o 'main'
entrypoint = <punto di ingresso>
# Numero di input da eseguire senza che venga trovato un breakpoint prima
# della rotazione dei breakpoint.
until_rotate_breakpoints = <numero>
# Numero massimo di breakpoint che possono essere posizionati contemporaneamente.
max_breakpoints = <numero>
# Elenco di funzioni da ignorare (blacklist).
# ignore_functions è un elenco di nomi di funzione separati da spazi, es. 'malloc free'.
ignore_functions = <elenco separato da spazi>
# Uno tra {Hardware, QEMU, SUTRunsOnHost}
# Hardware: un componente esterno avvia un server gdb e GDBFuzz può connettersi a questo server gdb.
# QEMU: GDBFuzz avvia QEMU. QEMU emula binary_file_path e avvia gdbserver.
# SUTRunsOnHost: GDBFuzz avvia il programma target all'interno di GDB.
target_mode = <modalità>
# Imposta a False se si desidera avviare ghidra, analizzare il SUT,
# e avviare il bridge ghidra manualmente.
start_ghidra = True
# Elenco separato da spazi di indirizzi dove vengono impostati breakpoint software (per
# codice di gestione degli errori). L'esecuzione di questi viene considerata un crash.
# Esempio: software_breakpoint_addresses = 0x123 0x432
software_breakpoint_addresses =
# Se tutti i breakpoint software attivati devono essere considerati come crash
consider_sw_breakpoint_as_error = False
[SUTConnection]
# La classe 'SUT_connection_class' nel file 'SUT_connection_path' implementa
# come vengono inviati gli input al SUT.
# Gli input possono essere inviati, ad esempio, tramite Wi-Fi, Serial, Bluetooth, ...
# Questa classe deve ereditare da ./connections/SUTConnection.py.
# Vedere ./connections/SUTConnection.py per maggiori informazioni.
SUT_connection_file = FIFOConnection.py
[GDB]
path_to_gdb = gdb-multiarch
#Scritto in address:port
gdb_server_address = localhost:4242
[Fuzzer]
# In byte
maximum_input_length = 100000
# In secondi
single_run_timeout = 20
# In secondi
total_runtime = 3600
# Opzionale
# Percorso di una directory in cui ogni file contiene un seed. Se non si desiderano
# utilizzare seed, lasciare il valore vuoto.
seeds_directory =
[BreakpointStrategy]
# Le strategie per scegliere i blocchi di base si trovano in
# 'src/GDBFuzz/breakpoint_strategies/'
# Nell'articolo utilizziamo le seguenti strategie
# 'RandomBasicBlockStrategy.py' - Scelta casuale di blocchi di base non raggiunti
# 'RandomBasicBlockNoDomStrategy.py' - Come il precedente, ma non utilizza le relazioni di dominanza per derivare i nodi raggiunti transitivamente.
# 'RandomBasicBlockNoCorpusStrategy.py' - Come il primo, ma impedisce la crescita del corpus di input e quindi si comporta come un fuzzing blackbox con misurazione della copertura.
# 'BlackboxStrategy.py', - Non imposta alcun breakpoint
breakpoint_strategy_file = RandomBasicBlockStrategy.py
[Dependencies]
path_to_qemu = dependencies/qemu/build/x86_64-linux-user/qemu-x86_64
path_to_ghidra = dependencies/ghidra
[LogsAndVisualizations]
# Uno tra {DEBUG, INFO, WARNING, ERROR, CRITICAL}
loglevel = INFO
# Percorso di una directory in cui vengono salvati i file di output (es. grafici, file di log).
output_directory = ./output
# Se impostato a True, un client MQTT invia elementi UI (es. grafici)
enable_UI = False
Un file di configurazione di esempio si trova in ./example_programs/ insieme a un programma di esempio compilato utilizzando il nostro harness di fuzzing in benchmark/benchSUTs/GDBFuzz_wrapper/common/.
Avviare il fuzzing per un'ora con il seguente comando.
chmod a+x ./example_programs/json-2017-02-12
./src/GDBFuzz/main.py --config ./example_programs/fuzz_json.cfg
Vedremo prima l'output di Ghidra che analizza il binario eseguibile e successivamente i messaggi quando i breakpoint vengono riposizionati o attivati.
A seconda della output_directory specificata nel file di configurazione, ora dovrebbe esserci una cartella trial-0 con la seguente struttura
.
├── corpus # Cartella che contiene il corpus di input.
├── crashes # Cartella che contiene gli input che causano crash - se presenti.
├── cfg # Il grafo di flusso di controllo come lista di adiacenza.
├── fuzzer_stats # Statistiche della campagna di fuzzing.
├── plot_data # Tabella che mostra a quale tempo relativo nella campagna di fuzzing è stato raggiunto un determinato blocco di base.
├── reverse_cfg # Il grafo di flusso di controllo inverso.
Impostando start_ghidra = False nel file di configurazione, GDBFuzz si connette a un'istanza di Ghidra in esecuzione in modalità GUI. Pertanto, il plugin ghidra_bridge deve essere avviato manualmente dal gestore script. Durante il fuzzing, i blocchi di programma raggiunti vengono evidenziati in verde.