La empresa Google ha presentado el proyecto ClusterFuzzLite, que permite organizar pruebas de fuzzing de código para la detección temprana de posibles vulnerabilidades durante el funcionamiento de sistemas de integración continua. Actualmente, ClusterFuzz se puede utilizar para automatizar las pruebas de fuzzing en solicitudes de extracción en GitHub Actions, en Google Cloud Build y en Prow, pero se espera que en el futuro se añada soporte para otros sistemas de CI. El proyecto se basa en la plataforma ClusterFuzz, diseñada para coordinar el funcionamiento de clústeres de pruebas de fuzzing, y se distribuye bajo la licencia Apache 2.0.
Se destaca que después de la implementación en 2016 por parte de Google del servicio OSS-Fuzz, se han incorporado más de 500 importantes proyectos de código abierto al programa de pruebas de fuzzing continua. A partir de las verificaciones realizadas, se han corregido más de 6500 vulnerabilidades confirmadas y solucionado más de 21 mil errores. ClusterFuzzLite continúa desarrollando mecanismos de pruebas de fuzzing con la capacidad de identificar problemas más tempranamente en la etapa de revisión de cambios propuestos. ClusterFuzzLite ya se ha integrado en los procesos de revisión de cambios en los proyectos systemd y curl, permitiendo detectar errores que habían sido pasados por alto por los analizadores estáticos y linters utilizados en la etapa inicial de revisión de código nuevo.
ClusterFuzzLite admite la verificación de proyectos en lenguajes como C, C++, Java (y otros lenguajes basados en JVM), Go, Python, Rust y Swift. Las pruebas de fuzzing se realizan utilizando el motor LibFuzzer. Para detectar errores en la gestión de memoria y anomalías, también se pueden invocar herramientas como AddressSanitizer, MemorySanitizer y UBSan (UndefinedBehaviorSanitizer).
Las principales características de ClusterFuzzLite son: verificación rápida de los cambios propuestos para encontrar errores antes de la aceptación del código; carga de informes sobre las condiciones que provocan fallos; capacidad para pasar a pruebas de fuzzing más avanzadas para identificar errores más profundos no detectados tras la revisión de cambios en el código; generación de informes de cobertura para evaluar la cobertura del código durante las pruebas; y una arquitectura modular que permite seleccionar la funcionalidad necesaria.
Recordemos que durante las pruebas de fuzzing se genera un flujo de diversas combinaciones aleatorias de datos de entrada, similares a datos reales (por ejemplo, páginas html con parámetros de etiquetas aleatorios, archivos comprimidos o imágenes con encabezados anómalos, etc.), y se registran posibles fallos en el proceso de su manejo. Si alguna secuencia provoca un fallo o no coincide con la respuesta esperada, tal comportamiento indica con alta probabilidad la existencia de un error o vulnerabilidad.
Fuente: opennet.ru
