0xricksanchez/fisy-fuzzEste es el framework completo de fuzzing del sistema de archivos que presenté en la conferencia Hack in the Box 2020 Lockdown Edition en abril.
Este es el framework completo de fuzzing de sistemas de archivos que presenté en la conferencia Hack in the Box 2020 Lockdown Edition en abril.
El objetivo de este framework es descubrir bugs de seguridad del kernel en sistemas UNIX con un fuerte enfoque en sistemas BSD. Fue desarrollado y probado intensamente contra FreeBSD, OpenBSD y NetBSD, pero también tiene soporte menor para sistemas basados en Linux. Pudimos descubrir con éxito más de 100 bugs únicos del kernel para sistemas de archivos basados en UFS y EXT, obteniendo también mucho conocimiento sobre la reciente adición de ZFS.
El makeFS2.py se puede utilizar como una utilidad independiente para generar diferentes sistemas de archivos válidos.
El uso se explica en detalle en el repositorio de material de la conferencia
El framework se probó únicamente en Ubuntu 18.04.
Depende de KVM, QEMU y libvirt.
El Requirements.sh configura todas las dependencias necesarias.
El framework puede ser completamente funcional en la última versión de Ubuntu 20.04.
Otros sistemas anfitrión no basados en apt deberían ser fácilmente soportados y solo requieren cambios menores en el Requirements.sh.
Una vez que hayas completado los requisitos, ¡puedes continuar con los pasos de configuración!
Consulta el SETUP.md. Si algunos pasos no están claros, ¡por favor contacta!
Iniciar el fuzzer solo requiere ejecutar: python3 run.py.
Dependiendo de tu configuración, puedes requerir privilegios de sudo.
Cuando todo se haya iniciado correctamente, puedes conectarte a la sesión de tmux del fuzzing mediante:
(sudo) tmux attach-session -t fsfuzzer
El framework se puede configurar con el script src/config/fuzzing_config.py:
# [fuzzing task specs]
# List of dictionaries specifying each fuzzing instance
fuzzer = [
{
"name": "fuzz1", # Some name for internal bookkeeping
"fs_creator_vm": "genBox", # Name as specified in libvirt for the VM handling the file system generation, can be the same across all instances
"fuzzing_vm": "fuzzBox_0", # Name as specified in libvirt for the VM handling the file system generation
"mutation_engine": "radamsa, 0", # Mutation Engine that is to be used, and size of mutation (radamsa takes no size argument)
"target_fs": "ufs2", # Target file system
"target_size": 15, # Max file system size in Megabyte
"populate_with_files": 10, # Amount of file that will be generated
"max_file_size": 1024, # Maximum file size in bytes for each generated file
"enable_dyn_scaling": False, # Dynamic scaling will increase the filesystem size periodically
},
]
# [credentials]
# Credentials for the root user for the VMs
# It is expected that these are the same across all instances, but not necessarily root
user = "root"
pw = "root"
Los motores de mutación disponibles son:
El escalado dinámico se implementó inicialmente para probar si el tamaño de un sistema de archivos afecta los posibles fallos. No pude identificar un valor de activación para el tamaño del sistema de archivos donde los fallos cambien, por lo que esta bandera puede permanecer deshabilitada. Esto también evita sufrir una caída de rendimiento en ejecuciones más largas, ya que los sistemas de archivos más grandes tardan más en mutarse.
Los parámetros de configuración restantes deberían ser autoexplicativos.
El video a continuación muestra una demostración rápida donde dos instancias de fuzzing, ambas apuntando a FreeBSD, con un sistema de archivos UFS2 mutado con radamsa y un sistema de archivos EXT con bytes aleatorios volteados. El sistema de archivos UFS mutado conduce directamente a un fallo, mostrando qué tan rápido se puede hacer fallar un kernel.
Con esta configuración, pude encontrar más de 100 bugs únicos del kernel en FreeBSD, NetBSD y OpenBSD para sistemas de archivos basados en UFS y EXT. Entre estos fallos, tuve un montón de muy interesantes:
La mayoría de los fallos fueron DoS del kernel. Además, la mayoría de los fallos encontrados aún no están solucionados a día de hoy (mayo de 2020). ¡Así que anímate a encontrar bugs del kernel en implementaciones de sistemas de archivos :)!
Todo esto fue construido con 'desarrollo impulsado por la confianza', lo que significa que creció demasiado grande y demasiado rápido a partir de una simple idea de PoC. Por lo tanto, tampoco hay pruebas y probablemente algunos bugs. Lamento si te encuentras con fallos (que no estén relacionados con pánico del kernel), pero siéntete libre de hacer un PR o contactarme y arreglaré las cosas lo antes posible.
Twitter: @0xricksanchez