¿La mejor forma de clasificar los bloqueos encontrados a través de fuzzing, en Linux?

Las herramientas de clasificación de Linux de código abierto de CERT se pueden utilizar para la clasificación de los errores encontrados a través de fuzzing. Las herramientas incluyen una extensión GDB que es similar a la de MSEC! Explotable, pero para Linux.

enlace

Aquí está la mejor heurística que conozco. Ejecute el programa en Valgrind memcheck y luego observe las advertencias que produce Valgrind. Podemos clasificarlos en un par de categorías:

• Escritura no válida: mira la dirección. Si la dirección es pequeña (por ejemplo, entre 0x0 y 0xFFF), entonces esta es una diferencia de puntero NULL: probablemente no sea explotable, de baja prioridad. De lo contrario, se trata de una escritura fuera de los límites: potencialmente explotable, un error grave de alta prioridad.

• Lectura no válida: mire la dirección. Si la dirección es pequeña (por ejemplo, entre 0x0 a 0xFFF, por ejemplo), esta es una diferencia de puntero NULO: probablemente no sea explotable, de baja prioridad. De lo contrario, esta es una lectura fuera de los límites: podría ser explotable si tienes mala suerte, pero a menudo estos errores no son explotables; llámalo de prioridad media.

• Invalid free (): Esto podría ser un error doble libre, y existe una gran posibilidad de que sea explotable. Alta prioridad.

• No coinciden con free () / delete / delete []: Potencialmente explotable , dependiendo de las circunstancias. Prioridad media.

• El salto o movimiento condicional depende de los valores no inicializados: Si bien estos errores a veces se pueden explotar, la explotación de ninguna manera está garantizada y no es probable que sea fácil. A menudo, estos son positivos falsos benignos. Prioridad media a baja.

• Syscall param ... apunta a byte (s) no inicializados o Syscall param ... contiene byte (s) sin inicializar: Igual que arriba. Prioridad media a baja.

• La fuente y el destino se superponen en ...: es muy poco probable que sea explotable. Baja prioridad.

• Fugas de memoria: (por ejemplo, Todavía accesible, Definitivamente Perdido, Indirectamente Perdido, Posiblemente Perdido): Es muy poco probable que sea explotable. Baja prioridad.

Esta es la mejor heurística que conozco. No conozco ninguna herramienta que lo implemente por usted, pero no es tan difícil escribirlo usted mismo. ¿Alguien sabe de una mejor heurística de triaje o herramienta para sistemas Linux / Unix?

Me gusta usar la plataforma de búsqueda de melocotones . Este contiene un arnés de prueba que registrará volcados de memoria de bloqueos y los vinculará al caso de prueba de fuzz. Cuando el proceso falla, el arnés de prueba lo reiniciará y continuará hasta que se complete la prueba.

Por lo que sé, ! explotable es bastante único. Valgrind es útil para determinar fallas como punteros colgantes. La forma pasada de moda de determinar si una falla es explotable es mirar el EIP , 0x41414141 es siempre una visión bienvenida. Sin embargo, es posible que la aplicación se bloquee antes de que la función regrese porque se ha sobrescrito un puntero en la pila. Por lo tanto, incluso un fallo en la lectura / escritura en un registro de propósito general como ebx 0x41414141 puede ser potencialmente explotable y el proceso simplemente se bloquea antes de su devolución. Asegúrate de mirar la pila de llamadas para ver si está dañada.

Algunos de los proyectos hermanos de American Fuzzy Lop tienen algunas herramientas que podrían ser útiles. En particular:

• afl-crash-analyzer tiene cierta automatización para ayudar a analizar un caso de prueba que falla , incluida la ejecución del script exploitable GDB para comprobar si el bloqueo parece explotable.

• crashwalk tiene cierta automatización para probar qué bloqueos son reproducibles y para clasificarlos usando el exploitable secuencia de comandos GDB para Linux; también tiene un script similar para Mac OS X.