nccgroup/triforcelinuxsyscallfuzzerUn fuzzer de llamadas al sistema para linux que utiliza TriforceAFL.
Nuevo: Para aquellos que quieran jugar con TriforceAFL y TLSF, Richard Johnson creó un Dockerfile que instala ambos (e incluso compila un kernel de Linux por ti). Está disponible aquí https://hub.docker.com/r/moflow/afl-triforce/tags/.
Esta es una colección de archivos utilizados para realizar fuzzing de llamadas al sistema en kernels de Linux x86_64 usando AFL y QEMU. Para usarlo necesitarás TriforceAFL desde https://github.com/nccgroup/TriforceAFL y una imagen de kernel para fuzzear. Los scripts asumen que TriforceAFL se encuentra en $TAFL o ../TriforceAFL/ (N.B. compilar testAfl requiere que exista ../TriforceAFL/config.h).
Para compilar:
make
Para ejecutarlo, primero instala un kernel en ./kern/bzImage y extrae /proc/kallsyms en ./kern/kallsyms. Establece la variable de entorno K=kern para que apunte a tu kernel. Ahora ejecuta:
make inputs
./runFuzz -M M0
Ten en cuenta que el script runFuzz espera un nombre de maestro o esclavo, ya que siempre se ejecuta en modo maestro/esclavo. Consulta el script runFuzz para obtener más información sobre su uso.
Ten en cuenta también que esto solo crea un pequeño conjunto de entradas de ejemplo. Para probar un gran número de llamadas al sistema importantes, probablemente querrás generar un ejemplo de cada llamada al sistema, o al menos un ejemplo para cada "forma" de llamada al sistema. Estos deben colocarse en inputs/. Consulta gen2.py para ver un ejemplo.
Para reproducir casos de prueba (como fallos) ejecuta:
./runTest inputs/ex1
./runTest outputs/crashes/id*
También puedes ejecutar el driver fuera del entorno emulado con la opción -t, con registro verboso mediante -vv y sin realizar realmente las llamadas al sistema con -x:
./driver -tvvx < inputs/ex1
strace ./driver -t < inputs/ex1
A veces es útil poder arrancar el kernel y ejecutar pruebas de forma interactiva. Para ello, edita los archivos rootTemplate como consideres conveniente (por ejemplo, para añadir más herramientas de prueba al sistema de archivos raíz) y luego ejecuta:
./runCmd
Se pueden invocar otros comandos además del shell especificándolos como argumentos de línea de comandos para runCmd.
Nota: cuando termines con el shell, usa ^A-c para obtener el prompt de QEMU y escribe quit.
La depuración es más fácil con un kernel compilado con los símbolos de depuración habilitados.
Usa runTest para iniciar el kernel y ejecutar una prueba a través del driver, o usa runCmd para ejecutar manualmente un caso de prueba desde el shell.
Edita tu script de ejecución para incluir la opción -s al iniciar afl-qemu-system-trace.
Esto habilitará el soporte de gdb en el puerto TCP 1234. Usa getvmlinux para extraer la imagen del kernel vmlinux de tu kernel bzImage y ejecuta gdb después de que el sistema haya arrancado:
cp kern/bzImage .
./getvmlinux
gdb ./vmlinux
target remote :1234
break somefunction
continue
Puedes adjuntar el depurador después de que runTest haya provocado un fallo o antes de que desencadenes manualmente el error en runCmd.
Ten en cuenta que las fuentes de Linux se compilan con la optimización activada por defecto. Esto puede hacer que la depuración sea confusa y difícil.
Puedes desactivar la optimización archivo por archivo editando el archivo make de Linux del subdirectorio en el que se encuentra un archivo y añadiendo CFLAGS_name.o = -O0 al Makefile. Por ejemplo, editar kernel/Makefile y añadir CFLAGS_sys_ni.o = -O0 desactivará la optimización al compilar kernel/sys_ni.o.
El script de shell getSyms utiliza runCmd para ejecutar cat /proc/kallsyms y extraerlo a un archivo local llamado kallsyms. Esto se usa típicamente para preparar tu kernel para el fuzzing:
K=yourKernDir ./getSyms para obtener kallsymsmv kallsyms yourKernDir para instalarloNota: Al hacer fuzzing a un kernel de Linux 2.* necesitarás habilitar el temporizador de la CPU. Cuando el temporizador no está habilitado, la detección de pánico y de registro no parecen funcionar correctamente y los pánicos resultan en cuelgues. Para habilitar el temporizador, llama a startForkserver(1) en driver.c en lugar de startForkserver(0). Este problema no parece ocurrir en los kernels de Linux 3.* y Linux 4.*.