nccgroup/triforceaflAFL/QEMU fuzzing con emulación de sistema completo.
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/.
También nuevo: ¡afl-tmin ahora funciona con el forkserver!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Esta es una versión parcheada de AFL que soporta fuzzing de sistema completo usando QEMU. El QEMU incluido ha sido actualizado para permitir el trazado de ramas cuando se ejecuta un emulador de sistema para x86_64. Se han añadido instrucciones adicionales para iniciar el forkserver de AFL, configurar los ajustes de fuzzing, y marcar el inicio y el fin de los casos de prueba.
Nota: no todas las herramientas de AFL han sido probadas con los nuevos cambios. Estas herramientas han recibido algunas pruebas:
Para compilar:
make
Para obtener un mapa de cobertura:
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Para hacer fuzzing:
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Nota: a diferencia de cuando se usa la opción "-Q", debes especificar la línea de comandos completa para afl-qemu-system-trace cuando uses la opción "-QQ").
Para más detalles sobre cómo usar esta versión modificada de AFL, consulta nuestro fuzzer de syscalls de Linux en https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Nuevas opciones de AFL: -QQ - usa qemu en emulación de sistema completo en lugar de modo usuario (-Q)
Nuevas opciones de QEMU: -aflFile - El nombre del archivo que contiene las entradas del fuzzer -aflPanicAddr - Una dirección de kernel panic para la detección de pánicos -aflDmesgAddr - Dirección en el kernel de Linux de la función de registro dmesg para detectar el registro e interceptar los mensajes de log
Nuevas instrucciones de QEMU: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Inicia el fork server de AFL. Después de este punto, cada prueba se ejecutará en un proceso hijo fork separado. Si enableTicks es distinto de cero, QEMU volverá a habilitar el temporizador de la CPU después de hacer fork de un hijo; de lo contrario, no se habilitará. edi=2 getWork(esi=ptr, edx=sz) Llena ptr[0..sz] con el siguiente caso de prueba de entrada. Devuelve el tamaño real llenado (<= sz). edi=3 startWork(esi=ptr) Indica a AFL que comience el trazado. El argumento apunta a un buffer con dos quadwords que indican las direcciones de inicio y fin del código a trazar. Las instrucciones fuera de este rango no se trazan. edi=4 doneWork(esi=exitCode) Indica a AFL que el caso de prueba ha terminado. Si se detecta un pánico, AFL detendrá el caso de prueba inmediatamente. De lo contrario, se ejecutará hasta que se llame a doneWork. El exitCode especificado se devuelve a AFL. (El código puede, pero actualmente no lo hace, aplicar un OR con el valor 64 a todos los códigos de salida si se detectaron logs de dmesg durante el caso de prueba).
Nuevo controlador de bloque de QEMU: -drive filename=privmem: Este controlador de bloque mantiene la imagen de la unidad en memoria copy-on-write para que los cambios nunca se persistan en disco. Los cambios realizados por un caso de prueba están aislados de otros casos de prueba.
Escrito y mantenido por Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Todos los derechos reservados. Publicado bajo los términos y condiciones de la Licencia Apache, Versión 2.0.
Para nuevas versiones e información adicional, consulta: http://lcamtuf.coredump.cx/afl/
Para comparar notas con otros usuarios o recibir notificaciones sobre nuevas funciones importantes, envía un correo a [email protected].
** Consulta QuickStartGuide.txt si no tienes tiempo de leer este archivo. **
El fuzzing es una de las estrategias más potentes y probadas para identificar problemas de seguridad en software del mundo real; es responsable de la gran mayoría de los bugs de ejecución remota de código y escalada de privilegios encontrados hasta la fecha en software crítico para la seguridad.
Desafortunadamente, el fuzzing también es relativamente superficial; las mutaciones ciegas y aleatorias hacen muy poco probable alcanzar ciertas rutas de código en el software probado, dejando algunas vulnerabilidades firmemente fuera del alcance de esta técnica.
Ha habido numerosos intentos de resolver este problema. Uno de los primeros enfoques - pionero de Tavis Ormandy - es la destilación de corpus. El método se basa en señales de cobertura para seleccionar un subconjunto de semillas interesantes de un corpus masivo y de alta calidad de archivos candidatos, y luego fuzzearlos por medios tradicionales. El enfoque funciona excepcionalmente bien, pero requiere que dicho corpus esté fácilmente disponible. Además, las mediciones de cobertura de bloques proporcionan solo una comprensión muy simplista del estado del programa, y son menos útiles para guiar el esfuerzo de fuzzing a largo plazo.
Otras investigaciones más sofisticadas se han centrado en técnicas como el análisis de flujo de programa ("ejecución concolic"), ejecución simbólica o análisis estático. Todos estos métodos son extremadamente prometedores en entornos experimentales, pero tienden a sufrir problemas de fiabilidad y rendimiento en usos prácticos - y actualmente no ofrecen una alternativa viable a las técnicas de fuzzing "tonto".
American Fuzzy Lop es un fuzzer de fuerza bruta combinado con un algoritmo genético extremadamente simple pero sólido como una roca, guiado por instrumentación. Utiliza una forma modificada de cobertura de aristas para detectar sin esfuerzo cambios sutiles a escala local en el flujo de control del programa.
Simplificando un poco, el algoritmo general se puede resumir como:
Cargar los casos de prueba iniciales proporcionados por el usuario en la cola,
Tomar el siguiente archivo de entrada de la cola,
Intentar recortar el caso de prueba al tamaño más pequeño que no altere el comportamiento medido del programa,
Mutar el archivo repetidamente usando una variedad equilibrada y bien investigada de estrategias tradicionales de fuzzing,
Si alguna de las mutaciones generadas resultó en una nueva transición de estado registrada por la instrumentación, añadir la salida mutada como una nueva entrada en la cola.
Ir al paso 2.
Los casos de prueba descubiertos también se eliminan periódicamente para descartar aquellos que han quedado obsoletos por hallazgos más nuevos y de mayor cobertura; y pasan por varios otros pasos de minimización de esfuerzo impulsados por la instrumentación.
Como resultado secundario del proceso de fuzzing, la herramienta crea un pequeño corpus autocontenido de casos de prueba interesantes. Estos son extremadamente útiles para sembrar otros regímenes de prueba que requieren mucho trabajo o recursos - por ejemplo, para pruebas de estrés de navegadores, aplicaciones ofimáticas, suites gráficas o herramientas de código cerrado.
El fuzzer está exhaustivamente probado para ofrecer un rendimiento inmediato muy superior al fuzzing ciego o a las herramientas basadas solo en cobertura.
Cuando el código fuente está disponible, la instrumentación puede inyectarse mediante una herramienta acompañante que funciona como un reemplazo directo de gcc o clang en cualquier proceso de compilación estándar para código de terceros.
La instrumentación tiene un impacto de rendimiento bastante modesto; en conjunción con otras optimizaciones implementadas por afl-fuzz, la mayoría de los programas pueden ser fuzzeados tan rápido o incluso más rápido de lo posible con herramientas tradicionales.
La forma correcta de recompilar el programa objetivo puede variar dependiendo de las particularidades del proceso de compilación, pero un enfoque casi universal sería:
$ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Para programas en C++, también querrás establecer CXX=/path/to/afl/afl-g++.
Los wrappers de clang (afl-clang y afl-clang++) se pueden usar de la misma manera; los usuarios de clang también pueden optar por aprovechar un modo de instrumentación de mayor rendimiento, como se describe en llvm_mode/README.llvm.
Al probar librerías, necesitas encontrar o escribir un programa simple que lea datos de stdin o de un archivo y los pase a la librería probada. En tal caso, es esencial enlazar este ejecutable contra una versión estática de la librería instrumentada, o asegurarse de que el archivo .so correcto se cargue en tiempo de ejecución (generalmente estableciendo LD_LIBRARY_PATH). La opción más simple es una compilación estática, generalmente posible mediante:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Establecer AFL_HARDEN=1 al llamar a 'make' hará que el wrapper de CC habilite automáticamente opciones de endurecimiento de código que facilitan la detección de bugs de memoria simples.
PD. Se recomienda a los usuarios de ASAN revisar el archivo notes_for_asan.txt para advertencias importantes.
Cuando el código fuente NO está disponible, el fuzzer ofrece soporte experimental para instrumentación rápida y sobre la marcha de binarios de caja negra. Esto se logra con una versión de QEMU que se ejecuta en el modo menos conocido de "emulación de espacio de usuario".
QEMU es un proyecto separado de AFL, pero puedes compilar convenientemente la funcionalidad haciendo:
$ cd qemu_mode $ ./build_qemu_support.sh
Para instrucciones adicionales y advertencias, consulta qemu_mode/README.qemu.
El modo es aproximadamente 2-5 veces más lento que la instrumentación en tiempo de compilación, es menos propicio para la paralelización, y puede tener otras peculiaridades.
Para funcionar correctamente, el fuzzer requiere uno o más archivos iniciales que contengan un buen ejemplo de los datos de entrada que normalmente espera la aplicación objetivo. Hay dos reglas básicas:
Mantén los archivos pequeños. Menos de 1 kB es ideal, aunque no estrictamente necesario. Para una discusión sobre por qué el tamaño importa, consulta perf_tips.txt.
Usa múltiples casos de prueba solo si son funcionalmente diferentes entre sí. No tiene sentido usar cincuenta fotos de vacaciones diferentes para fuzzear una librería de imágenes.
Puedes encontrar muchos buenos ejemplos de archivos iniciales en el subdirectorio testcases/ que viene con esta herramienta.
PD. Si hay un gran corpus de datos disponible para su revisión, puede que quieras usar la utilidad afl-cmin para identificar un subconjunto de archivos funcionalmente distintos que ejerciten diferentes rutas de código en el binario objetivo.
El proceso de fuzzing en sí lo lleva a cabo la utilidad afl-fuzz. Este programa requiere un directorio de solo lectura con los casos de prueba iniciales, un lugar separado para almacenar sus hallazgos, y una ruta al binario a probar.
Para binarios objetivo que aceptan entrada directamente desde stdin, la sintaxis habitual es:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
Para programas que toman entrada de un archivo, usa '@@' para marcar la ubicación en la línea de comandos del objetivo donde se debe colocar el nombre del archivo de entrada. El fuzzer lo sustituirá por ti:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
También puedes usar la opción -f para que los datos mutados se escriban en un archivo específico. Esto es útil si el programa espera una extensión de archivo particular o algo similar.
Los binarios no instrumentados pueden ser fuzzeados en modo QEMU (añade -Q en la línea de comandos) o en un modo tradicional de fuzzing ciego (especifica -n).
Puedes usar -t y -m para anular el tiempo de espera y el límite de memoria predeterminados del proceso ejecutado; ejemplos raros de objetivos que pueden necesitar estos ajustes incluyen compiladores y decodificadores de video.
Los consejos para optimizar el rendimiento del fuzzing se discuten en perf_tips.txt.
Ten en cuenta que afl-fuzz comienza realizando una serie de pasos de fuzzing deterministas, que pueden llevar varios días. Si quieres resultados rápidos y sucios de inmediato, similares a zzuf o honggfuzz, añade la opción -d a la línea de comandos.
Consulta el archivo status_screen.txt para obtener información sobre cómo interpretar las estadísticas mostradas y monitorear la salud del proceso. Asegúrate de consultar este archivo especialmente si algún elemento de la interfaz está resaltado en rojo.
El proceso de fuzzing continuará hasta que presiones Ctrl-C. Como mínimo, querrás permitir que el fuzzer complete un ciclo de cola, lo que puede llevar desde un par de horas hasta una semana o más.
Se crean tres subdirectorios dentro del directorio de salida y se actualizan en tiempo real:
queue/ - casos de prueba para cada ruta de ejecución distintiva, más todos los archivos iniciales proporcionados por el usuario. Este es el corpus sintetizado mencionado en la sección 2.
Antes de usar este corpus para cualquier otro propósito, puedes reducirlo
a un tamaño más pequeño usando la herramienta afl-cmin. La herramienta encontrará
un subconjunto más pequeño de archivos que ofrezca una cobertura de aristas equivalente.
crashes/ - casos de prueba únicos que hacen que el programa probado reciba una señal fatal (por ejemplo, SIGSEGV, SIGILL, SIGABRT). Las entradas están agrupadas por la señal recibida.
hangs/ - casos de prueba únicos que hacen que el programa probado agote el tiempo de espera. Nota que cuando los ajustes de tiempo de espera predeterminados (agresivos) están en efecto, esto puede ser un poco ruidoso debido a picos de latencia y otros fenómenos naturales.
Los crashes y hangs se consideran "únicos" si las rutas de ejecución asociadas implican transiciones de estado no vistas en fallos registrados anteriormente. Si un solo bug puede alcanzarse de múltiples maneras, habrá cierta inflación en el conteo al principio del proceso, pero esto debería disminuir rápidamente.
Los nombres de archivo de los crashes y hangs están correlacionados con las entradas padre de la cola que no fallan. Esto debería ayudar con la depuración.
Cuando no puedes reproducir un crash encontrado por afl-fuzz, la causa más probable es que no estás estableciendo el mismo límite de memoria que usa la herramienta. Prueba:
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Cambia LIMIT_MB para que coincida con el parámetro -m pasado a afl-fuzz. En OpenBSD, cambia también -Sv a -Sd.
Cualquier directorio de salida existente también se puede usar para reanudar trabajos abortados; prueba:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]
Si tienes gnuplot instalado, también puedes generar algunas gráficas bonitas para cualquier tarea de fuzzing activa usando afl-plot. Para un ejemplo de cómo se ve, consulta http://lcamtuf.coredump.cx/afl/plot/.
Cada instancia de afl-fuzz ocupa aproximadamente un núcleo. Esto significa que en sistemas multinúcleo, la paralelización es necesaria para utilizar completamente el hardware. Para consejos sobre cómo fuzzear un objetivo común en múltiples núcleos o múltiples máquinas en red, consulta parallel_fuzzing.txt.
Por defecto, el motor de mutación de afl-fuzz está optimizado para formatos de datos compactos - por ejemplo, imágenes, multimedia, datos comprimidos, sintaxis de expresiones regulares o scripts de shell. Es algo menos adecuado para lenguajes con verborrea particularmente extensa y redundante - notablemente incluyendo HTML, SQL o JavaScript.
Para evitar la molestia de construir herramientas conscientes de la sintaxis, afl-fuzz proporciona una forma de sembrar el proceso de fuzzing con un diccionario opcional de palabras clave del lenguaje, cabeceras mágicas u otros tokens especiales asociados con el tipo de datos objetivo
y usarlo para reconstruir la gramática subyacente sobre la marcha:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Para usar esta función, primero necesitas crear un diccionario en uno de los dos formatos discutidos en testcases/README.testcases; y luego apuntar el fuzzer a él mediante la opción -x en la línea de comandos.
No hay forma de proporcionar descripciones más estructuradas de la sintaxis subyacente, pero el fuzzer probablemente deducirá algo de esto basándose solo en la retroalimentación de la instrumentación. Esto realmente funciona en la práctica, por ejemplo:
PD. Incluso cuando no se proporciona un diccionario explícito, afl-fuzz intentará extraer tokens de sintaxis existentes en el corpus de entrada observando la instrumentación muy de cerca durante los volteos de bytes deterministas. Esto funciona para algunos tipos de analizadores y gramáticas, pero no es ni de lejos tan bueno como el modo -x.
La agrupación de crashes basada en cobertura generalmente produce un conjunto de datos pequeño que puede ser triageado rápidamente de forma manual o con un script muy simple de GDB o Valgrind. Cada crash también se puede rastrear hasta su caso de prueba padre que no falla en la cola, lo que facilita el diagnóstico de fallos.
Dicho esto, es importante reconocer que algunos crashes de fuzzing pueden ser difíciles de evaluar rápidamente para determinar su explotabilidad sin mucho trabajo de depuración y análisis de código. Para ayudar con esta tarea, afl-fuzz soporta un modo muy único de "exploración de crashes" habilitado con la bandera -C.
En este modo, el fuzzer toma uno o más casos de prueba que fallan como entrada, y usa sus estrategias de fuzzing guiadas por retroalimentación para enumerar muy rápidamente todas las rutas de código que se pueden alcanzar en el programa mientras lo mantiene en el estado de fallo.
Las mutaciones que no resultan en un crash son rechazadas; también lo son cualquier cambio que no afecte la ruta de ejecución.
La salida es un pequeño corpus de archivos que se puede examinar muy rápidamente para ver qué grado de control tiene el atacante sobre la dirección que falla, o si es posible pasar una lectura fuera de límites inicial - y ver qué hay debajo.
Ah, una cosa más: para la minimización de casos de prueba, prueba afl-tmin. La herramienta se puede operar de una manera muy simple:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
La herramienta funciona tanto con casos de prueba que fallan como con los que no. En el modo de crash, aceptará felizmente binarios instrumentados y no instrumentados. En el modo sin crash, el minimizador se basa en la instrumentación estándar de AFL para hacer el archivo más simple sin alterar la ruta de ejecución.
El minimizador acepta la sintaxis -m, -t, -f y @@ de una manera compatible con afl-fuzz.
Otra adición reciente a AFL es la herramienta afl-analyze. Toma un archivo de entrada, intenta voltear bytes secuencialmente y observa el comportamiento del programa probado. Luego codifica por colores la entrada basándose en qué secciones parecen ser críticas y cuáles no; aunque no es infalible, a menudo puede ofrecer perspectivas rápidas sobre formatos de archivo complejos. Más información sobre su funcionamiento se puede encontrar cerca del final de technical_details.txt.
Ten en cuenta que, de manera similar a muchas otras tareas computacionalmente intensivas, el fuzzing puede ejercer presión sobre tu hardware y sobre el sistema operativo. En particular:
Tu CPU se calentará y necesitará refrigeración adecuada. En la mayoría de los casos, si la refrigeración es insuficiente o deja de funcionar correctamente, las velocidades de la CPU se reducirán automáticamente. Dicho esto, especialmente al hacer fuzzing en hardware menos adecuado (portátiles, smartphones, etc.), no es del todo imposible que algo explote.
Los programas objetivo pueden terminar consumiendo erráticamente gigabytes de memoria o llenando el espacio del disco con archivos basura. AFL intenta hacer cumplir límites básicos de memoria, pero no puede prevenir todos y cada uno de los posibles contratiempos. En resumen, no deberías hacer fuzzing en sistemas donde la perspectiva de pérdida de datos no sea un riesgo aceptable.La fuzzing implica miles de millones de lecturas y escrituras en el sistema de archivos. En los sistemas modernos, esto suele estar fuertemente cacheado, lo que resulta en una E/S «física» bastante moderada, pero hay muchos factores que pueden alterar esta ecuación. Es tu responsabilidad vigilar posibles problemas; con una E/S muy intensa, la vida útil de muchos HDDs y SSDs puede reducirse.
Una buena forma de monitorear la E/S de disco en Linux es el comando 'iostat':
$ iostat -d 3 -x -k [...optional disk ID...]
Estas son algunas de las advertencias más importantes para AFL:
AFL detecta fallos comprobando si el primer proceso generado muere debido a una señal (SIGSEGV, SIGABRT, etc.). Los programas que instalan manejadores personalizados para estas señales pueden necesitar que se comente el código relevante. Del mismo modo, los fallos en procesos hijos generados por el objetivo fuzzeado pueden evadir la detección a menos que agregues manualmente algo de código para capturarlos.
Como con cualquier otra herramienta de fuerza bruta, el fuzzer ofrece una cobertura limitada si se usan cifrado, sumas de comprobación, firmas criptográficas o compresión para envolver por completo el formato de datos real que se va a probar.
Para solucionar esto, puedes comentar las comprobaciones relevantes (consulta experimental/libpng_no_checksum/ para inspirarte); si esto no es posible, también puedes escribir un postprocesador, como se explica en experimental/post_library/.
Hay algunas desventajas inevitables con ASAN y los binarios de 64 bits. Esto no se debe a ningún fallo específico de afl-fuzz; consulta notes_for_asan.txt para obtener consejos.
No hay soporte directo para fuzzear servicios de red, demonios en segundo plano o aplicaciones interactivas que requieran interacción con la interfaz de usuario para funcionar. Puede que necesites hacer cambios simples en el código para que se comporten de una manera más tradicional. Preeny también puede ofrecer una opción relativamente simple; consulta: https://github.com/zardus/preeny
También puedes encontrar algunos consejos útiles para modificar servicios basados en red en: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL no genera datos de cobertura legibles por humanos. Si quieres monitorear la cobertura, usa afl-cov de Michael Rash: https://github.com/mrash/afl-cov
Más allá de esto, consulta INSTALL para consejos específicos de cada plataforma.
Muchas de las mejoras a afl-fuzz no habrían sido posibles sin comentarios, informes de errores o parches de:
Jann Horn Hanno Boeck Felix Groebert Jakub Wilk Richard W. M. Jones Alexander Cherepanov Tom Ritter Hovik Manucharyan Sebastian Roschke Eberhard Mattes Padraig Brady Ben Laurie @dronesec Luca Barbato Tobias Ospelt Thomas Jarosch Martin Carpenter Mudge Zatko Joe Zbiciak Ryan Govostes Michael Rash William Robinet Jonathan Gray Filipe Cabecinhas Nico Weber Jodie Cunningham Andrew Griffiths Parker Thompson Jonathan Neuschfer Tyler Nighswander Ben Nagy Samir Aguiar Aidan Thornton Aleksandar Nikolich Sam Hakim Laszlo Szekeres David A. Wheeler Turo Lamminen Andreas Stieger Richard Godbee Louis Dassy teor2345 Alex Moneger Dmitry Vyukov Keegan McAllister Kostya Serebryany Richo Healey Martijn Bogaard rc0r Jonathan Foote Christian Holler Dominique Pelle Jacek Wielemborek Leo Barnes Jeremy Barnes Jeff Trull Guillaume Endignoux ilovezfs Daniel Godas-Lopez Franjo Ivancic
¡Gracias!
¿Preguntas? ¿Inquietudes? ¿Informes de errores? Generalmente se puede contactar al autor en [email protected].
También hay una lista de correo para el proyecto; para unirte, envía un correo a [email protected]. O, si prefieres revisar los archivos primero, prueba:
PD. Si deseas enviar código crudo para incorporarlo al proyecto, ten en cuenta que los derechos de autor de la mayor parte de AFL son reclamados por Google. Si bien conservas los derechos de autor de tus contribuciones, piden que la gente acepte una CLA simple primero:
Disculpa las molestias. Por supuesto, no se requiere ninguna CLA para solicitudes de funciones o informes de errores.