Il Fuzzer Scrive L'Exploit

// Il Gap

C'e' un mito nella security che resiste da trent'anni: trovare un bug e' scienza, scrivere un exploit e' arte. Il ricercatore trova il crash, poi si siede davanti a GDB, guarda i registri, conta i byte, calcola l'offset, costruisce il payload a mano, un byte alla volta. E' un lavoro artigianale. Bello da vedere, lento da fare.

Ho guardato un collega farlo per due giorni su un heap overflow in una libreria di parsing. Due giorni. GDB, Python, tentativi, bestemmie, caffe'. Alla fine ha scritto l'exploit. Funzionava. Era elegante. Era anche inutile.

Inutile perche' la stessa pipeline, automatizzata, ci mette minuti. Non due giorni. Minuti.

Il gap tra "ho trovato un crash" e "ho il controllo del flusso" si e' chiuso. Non perche' scrivere exploit sia diventato facile. Perche' il toolchain non scrive exploit: riduce lo spazio di ricerca finche' l'exploit diventa inevitabile.

La pipeline e' questa:

Oggi la costruiamo da zero. Su un target realistico, con codice che somiglia a quello che gira in produzione ovunque. Un parser binario in C con un bug che il 90% dei code reviewer non vedrebbe.

// Il Target

Il target e' un parser di un formato binario custom: header con magic number, versione, numero di tag. Ogni tag ha un tipo (1 byte), una lunghezza (2 byte) e i dati. Tag-Length-Value. Lo stesso pattern che trovi in TIFF, PNG, TLS, PDF, ELF, DICOM, e in qualsiasi protocollo binario mai scritto.

Il codice e' pulito. Fa i controlli giusti. Verifica il magic. Limita il numero di tag. Controlla che ogni tag stia dentro il file. E poi fa una cosa che il 99% dei parser C fanno: copia i dati in un buffer locale senza verificare che la lunghezza stia dentro il buffer.

Riga 9. memcpy(buf, tag_data, tag_len). Il buffer e' 128 byte. tag_len e' un uint16_t, puo' arrivare a 65535. Il chiamante ha gia' verificato che tag_len byte esistano nel file. Ma nessuno ha verificato che stiano nel buffer.

Questo e' il bug piu' comune nella storia del software C. Non e' inventato. E' lo stesso pattern di CVE-2015-8668 (libtiff), CVE-2017-9233 (libexpat), CVE-2019-13118 (libxslt). Cambia la libreria, il bug e' identico.

Il formato completo:

// Il Corpus e il Fuzzer

AFL++ non genera input a caso. E' un fuzzer coverage-guided: muta l'input, esegue il programma, e tiene traccia di quali branch del codice sono stati raggiunti. Se una mutazione esplora un path nuovo, quell'input viene salvato nel corpus. Se no, viene scartato. E' evoluzione darwiniana applicata ai byte.

Per funzionare bene, AFL++ ha bisogno di due cose: un seed corpus (input validi da cui partire) e un harness (come dare l'input al programma). Il nostro programma legge da file, quindi il harness e' il programma stesso. Per il corpus, generiamo seed validi con un generatore Python.

I seed coprono i casi base: un tag, due tag, tag con dati lunghi (ma dentro il buffer), tag con dati vuoti. AFL++ partira' da questi e mutera': flippera' bit, inserira' byte, cambiera' i campi length. Prima o poi, uno di questi mutanti avra' un tag_len > 128. E il programma crashera'.

Compilazione e lancio:

// Il Primo Crash

AFL++ parte. La dashboard si aggiorna. total paths, exec speed, stability. I primi secondi sono la fase deterministica: bit flip, byte flip, arithmetic, interest values. Poi passa alla fase havoc: mutazioni casuali aggressive.

Il contatore saved crashes e' a zero. Per ora.

Non ci vuole molto. Il fuzzer deve solo fare una cosa: generare un file dove il campo length di un tag e' maggiore di 128. Con mutazioni aritmetiche su un campo a 2 byte, ci arriva in pochi minuti. A volte in secondi.

saved crashes: 1

Il crash e' in findings/default/crashes/. E' un file binario di pochi byte. Guardiamolo:

Eccolo. Il campo length del tag dice 256 byte. Il buffer ne tiene 128. Il memcpy scrive 128 byte oltre la fine del buffer. Il programma crasha con SIGSEGV.

Ma un crash non e' un exploit. Un crash e' solo rumore. Dobbiamo capire cosa e' successo.

Prima di procedere, minimizziamo l'input:

afl-tmin rimuove ogni byte che non contribuisce al crash. Il risultato e' l'input minimo che trigghera il bug. Piu' piccolo e' l'input, piu' facile e' analizzarlo.

// ASan Parla

AddressSanitizer e' un compilatore di diagnosi. Inserisce check a ogni accesso in memoria: heap, stack, globali. Quando qualcosa va fuori dai limiti, non crasha con un generico SIGSEGV. Ti dice esattamente cosa, dove, e quanto.

Ricompiliamo con ASan:

L'output e' una sentenza:

Senza leggere una riga di disassembly, sappiamo tutto:

ASan non ti dice se il bug e' exploitable. Ti dice cosa e' successo. Il passo dopo e' capire se quel "cosa" controlla qualcosa di interessante.

// Exploitable?

Un buffer overflow sullo stack sovrascrive tutto quello che sta dopo il buffer: variabili locali, il frame pointer salvato, e il return address. Quando la funzione fa ret, il processore legge l'indirizzo di ritorno dallo stack e ci salta. Se l'hai sovrascritto, il processore salta dove dici tu.

Compiliamo senza protezioni e verifichiamo con GDB:

rbp = 0x414141415d41ffff. Il frame pointer e' stato sovrascritto con i nostri byte (0x41 = 'A'). Il crash avviene dentro process_tag perche' la funzione prova ad accedere ai parametri attraverso il frame corrotto. Ma il punto e' un altro: se l'overflow corrompe rbp, corrompe anche il return address che sta subito dopo.

Quando process_tag fara' ret, il processore leggera' un indirizzo che abbiamo scritto noi. Se possiamo scriverci 0x41414141, possiamo scriverci qualsiasi indirizzo. E se possiamo scegliere dove salta il processore, possiamo eseguire codice arbitrario.

Ora la domanda diventa: a quale offset esatto, dentro l'input, si trova il return address? Potremmo calcolarlo a mano. Oppure possiamo lasciare che lo faccia la macchina.

// angr Trova la Via

angr e' un framework di analisi binaria. Fa molte cose, ma quella che ci interessa e' una: symbolic execution. Invece di eseguire il programma con dati concreti, lo esegue con dati simbolici, variabili matematiche. Ogni branch diventa un vincolo. Alla fine, un SAT solver trova i valori concreti che soddisfano i vincoli.

Tradotto: gli diamo il binario, gli diciamo "l'input e' simbolico", e gli chiediamo "trovami un input che rende RIP uguale a 0x41414141".

Lo script:

Cosa succede dentro:

1. angr carica il binario e crea uno stato iniziale con un file di 512 byte simbolici. Ogni byte dell'input e' una variabile con 256 valori possibili.

2. Il simulation manager esegue il programma simbolicamente. Ogni if nel codice crea un fork: uno stato dove la condizione e' vera, uno dove e' falsa. I vincoli si accumulano.

3. Quando process_tag fa ret, il valore di RIP viene letto dallo stack. Se lo stack e' stato sovrascritto con dati simbolici, RIP diventa simbolico. Lo stato finisce nella stash unconstrained.

4. Aggiungiamo un vincolo: RIP deve valere 0x41414141. Il solver Z3 risolve il sistema e produce un input concreto di 512 byte dove i byte all'offset giusto contengono esattamente \x41\x41\x41\x41. angr non e' intelligente. E' esaustivo. Non capisce il bug. Esplora tutte le strade finche' una funziona.

L'output:

163 byte dall'inizio del tag data al return address. angr l'ha calcolato da solo, senza che noi sapessimo nulla del layout dello stack. Verifichiamo:

RIP = 0x41414141. Esattamente il valore che abbiamo chiesto. La macchina ha scritto il payload che controlla il flusso.

Nota: angr funziona anche senza Unicorn Engine (il warning failed loading unicornlib.so e' normale); sara' solo piu' lento.

// La Pipeline

Ogni passo che abbiamo fatto (compilare, generare seed, fuzzare, triagare, risolvere) e' uno script. pipeline.sh li concatena:

Un comando. ./pipeline.sh. Sorgente in ingresso, payload in uscita. Zero GDB. Zero offset calcolati a mano. Zero reverse engineering manuale. La pipeline trova il bug, lo classifica, verifica che sia exploitable, e genera l'input che controlla RIP.

Il tempo? Minuti, non giorni. Il collega ci ha messo due giorni.

// Le Difese Rompono la Pipeline

La pipeline funziona perche' abbiamo compilato senza protezioni. Nel mondo reale, il compilatore e il sistema operativo mettono ostacoli a ogni passo. Vediamo dove.

Ogni difesa rompe un passo specifico della pipeline. Ma le mitigazioni non rompono la pipeline. La spezzano in piu' passi.

Stack canary? Il fuzzer puo' cercare bug che non passano dal canary: heap overflow, use-after-free, type confusion. ASan li classifica tutti.

ASLR? Se trovi un information leak (il programma rivela un indirizzo), puoi calcolare la base. angr puo' modellare anche quello.

NX? Return-Oriented Programming. Invece di eseguire shellcode, concateni frammenti di codice gia' presente (gadget). angr supporta la generazione automatica di ROP chain.

CFI? E' la difesa piu' forte. Limita severamente cosa puo' fare un attaccante anche con pieno controllo dello stack. Ma le implementazioni reali hanno gap: forward-edge CFI senza backward-edge, granularita' troppo larga, gadget conformi al grafo.

// Gli Script