Il modo migliore per valutare i crash trovati tramite fuzzing, su Linux?

Gli open source Linux Triage Tools di CERT possono essere utilizzati per il triage di bug trovati tramite fuzzing. Gli strumenti includono un'estensione GDB simile a quella di MSEC! Exploitable, ma per Linux.

link

Ecco la migliore euristica che conosco. Esegui il programma alla voce Valgrind memcheck , quindi osserva gli avvisi che Valgrind emette. Possiamo classificarli in un paio di categorie:

• Scrittura non valida: controlla l'indirizzo. Se l'indirizzo è piccolo (diciamo, tra 0x0 e 0xFFF), allora questo è un dereferenziamento puntatore NULL: probabilmente non sfruttabile, a bassa priorità. Altrimenti, si tratta di una scrittura fuori limite: potenzialmente sfruttabile, un bug grave ad alta priorità.

• Lettura non valida: controlla l'indirizzo. Se l'indirizzo è piccolo (diciamo, tra 0x0 e 0xFFF, per esempio), allora questo è un dereferenziamento puntatore NULL: probabilmente non sfruttabile, a bassa priorità. Altrimenti, questa è una lettura fuori limite: potrebbe essere sfruttabile se sei sfortunato, ma spesso questi bug non sono sfruttabili; chiamalo con priorità media.

• Invalid free (): potrebbe trattarsi di un bug double-free e c'è una possibilità significativa che possa essere sfruttato. Alta priorità.

• Mismatched free () / delete / delete []: Potenziale sfruttabile , a seconda delle circostanze. Priorità media.

• Il salto o lo spostamento condizionato dipende dal / i valore / i non inizializzato: Anche se a volte questi bug possono essere sfruttati, lo sfruttamento non è affatto garantito, e non è facile che sia facile. Spesso, questi sono falsi positivi positivi. Priorità da media a bassa.

• Syscall param ... punta a byte non inizializzati o Syscall param ... contiene byte non inizializzati: come sopra. Priorità da media a bassa.

• Sorgente e destinazione si sovrappongono in ...: Molto improbabile che sia sfruttabile. Bassa priorità.

• Perdite di memoria: (ad es., Ancora raggiungibili, Sicuramente persi, Indirettamente persi, Forse persi): Molto improbabile che sia sfruttabile. Bassa priorità.

Questa è la migliore euristica che io conosca. Non conosco nessuno strumento che lo implementa per te, ma non è troppo difficile da inventare te stesso. Qualcuno sa di uno strumento euristico o triaging migliore per i sistemi Linux / Unix?

Mi piace utilizzare la piattaforma di pesca fuzzing . Questo contiene un harness di test che registrerà memorydumps dagli arresti anomali e li collegherà al caso di test fuzz. Quando il processo si blocca, il cablaggio di test lo riavvierà e continuerà fino al completamento del test.

Per quanto ne so ! exploitable è piuttosto unico. Valgrind è utile per determinare difetti come puntatori penzolanti. Il vecchio stile per determinare se un crash è sfruttabile è guardando il EIP , 0x41414141 è sempre una vista gradita. Tuttavia è possibile che l'applicazione si arresti prima che la funzione ritorni perché hai sovrascritto un puntatore sullo stack. Quindi anche un crash su lettura / scrittura su un registro generale come ebx 0x41414141 potrebbe essere potenzialmente sfruttabile e il processo si blocca prima del suo ritorno. Assicurati di esaminare il callstack per vedere se è stato danneggiato.

Alcuni dei progetti gemelli di Fuzzy Lop di American hanno alcuni strumenti che potrebbero essere utili. In particolare:

• afl-crash-analyzer ha un po 'di automazione per aiutare ad analizzare un caso di crash test , incluso l'esecuzione dello script exploitable GDB per verificare se l'arresto anomalo sembra sfruttabile.

• crashwalk ha un'automazione per testare quali crash sono riproducibili e per triarli usando exploitable script GDB per Linux; ha anche uno script simile per Mac OS X.