Fuzzing di librerie condivise

No, o almeno non in un modo che fornisca informazioni utili.

Il problema si trova nel passaggio 2, "determinare la firma della funzione". La maggior parte delle librerie condivise sono scritte in C o sono scritte in altre lingue, ma usano ancora la convenzione di chiamata cdecl . In tal caso, la firma della funzione non contiene informazioni sui tipi o sul numero pari di parametri - il tipo e il numero non sono nemmeno fissi (si consideri printf() ). Potresti provare a dedurlo con l'analisi statica, ma i conteggi di argomenti variabili, i punzoni di tipo e i programmatori di linguaggio assembly eccessivamente intelligenti tenderanno a ostacolare l'analisi.

Potresti sicuramente bloccare una funzione di libreria inserendo dati casuali nello stack e poi chiamando la funzione, ma questo di solito non ti fornisce alcuna informazione utile sulle vulnerabilità: i dati casuali non corrispondono quasi mai a una situazione che potrebbe essere istituito nell'uso del mondo reale. Si finirà per dedurre cose come "se passo due puntatori casuali a strcpy() , si blocca" o "Se non passo abbastanza parametri a printf() , si blocca".

Il LibFuzzer di LLVM potrebbe essere utile. È un toolkit per aiutare con la fuzzing in-process delle librerie.

Non risolve il problema di identificare automaticamente le firme di funzione di ogni funzione esportata e di iniettare a caso dati casuali del tipo appropriato. Invece, si aspetta che tu scriva una piccola imbracatura di test che invochi la funzione esportata con i dati del tipo appropriato, in modo che quella parte debba essere eseguita manualmente. Tuttavia, se si fa quella parte manualmente, si automatizza il resto del lavoro di fuzzing, usando tecniche simili a Fuzzy Lop americano (il AFL fuzzer ).