Tipicamente i fuzzer vengono utilizzati per testare programmi che accettano input strutturati. Questa struttura è specificata, ad esempio, in un formato di file o in un protocollo e distingue gli input validi da quelli non validi. Un fuzzer efficace genera input semi-validi che sono "abbastanza validi" in quanto non vengono rifiutati direttamente dal parser, ma creano comportamenti imprevisti più in profondità nel programma e sono quindi definiti "abbastanza non validi", ovvero fanno saltare fuori i cosiddetti "corner case" (ovvero casi limite non preventivati) che non sono stati adeguatamente trattati.
Storia
Il termine "fuzz" trae origine da un progetto didattico dell'autunno 1988 tenuto da Barton Miller presso l'Università del Wisconsin,[1][3] i cui risultati vennero successivamente pubblicati nel 1990.[4] Il progetto serviva per testare l'affidabilità dei programmi a riga di comando UNIX, eseguendo un gran numero di input casuali in rapida successione fino al loro arresto anomalo. Il team di Miller riuscì a mandare in crash dal 25 al 33% delle utility UNIX testate, eseguendo poi il debug di ciascuno degli arresti anomali per determinarne la causa e classificando ogni errore rilevato. Per consentire ad altri ricercatori di condurre esperimenti simili con altri software, il codice sorgente dei tool sviluppati, le procedure di test e i dati grezzi dei risultati vennero resi pubblicamente disponibili.
Tipi
Un fuzzer può essere classificato nei seguenti modi:[5][6]
"generation-based" o "mutation-based" a seconda che gli input siano generati da zero oppure modificando gli input esistenti;
strutturato o non strutturato a seconda che si abbia conoscenza o meno della struttura di input;
"white box", "black box" o "grey box" a seconda che si abbia conoscenza o meno della struttura del programma.
Usi
Il fuzzing viene utilizzato principalmente come tecnica automatizzata per esporre le vulnerabilità nei programmi critici per la sicurezza che potrebbero essere sfruttati con intenzioni dannose. Più in generale, il fuzzing viene utilizzato per dimostrare la presenza di bug piuttosto che la loro assenza. L'esecuzione di un collaudo di tipo fuzz per diverse settimane senza trovare un bug non dimostra che il programma è corretto.[7] Dopotutto, il programma potrebbe ancora fallire per un input che non è stato ancora eseguito, ma di contro eseguire un programma per tutti i potenziali input sarebbe proibitivo. Se l'obiettivo è quello di dimostrare che un programma è corretto per tutti gli input, deve esistere una specifica formale e devono essere utilizzate le tecniche dei metodi formali.
^(EN) Barton P. Miller, Fall 1988 CS736 Project List (PDF), su pages.cs.wisc.edu, Computer Sciences Department, University of Wisconsin-Madison, settembre 1988. URL consultato il 27 settembre 2022.
^(EN) Barton P. Miller, Lars Fredriksen e Bryan So, An Empirical Study of the Reliability of UNIX Utilities (PDF), in Communications of the ACM, dicembre 1990. URL consultato il 26 settembre 2022 (archiviato dall'url originale il 7 febbraio 2018).
