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 pruebas difusas de solicitudes de extracción en GitHub Actions, Google Cloud Build y Prow, pero se espera compatibilidad con otros sistemas de CI en el futuro. El proyecto se basa en la plataforma ClusterFuzz, creada para coordinar el trabajo de los clústeres de prueba de fuzzing, y se distribuye bajo la licencia Apache 2.0.
Cabe señalar que después de que Google introdujo el servicio OSS-Fuzz en 2016, más de 500 proyectos importantes de código abierto fueron aceptados en el programa de pruebas continuas de fuzzing. A partir de las pruebas realizadas se eliminaron más de 6500 vulnerabilidades confirmadas y se corrigieron más de 21 mil errores. ClusterFuzzLite continúa desarrollando mecanismos de prueba de confusión con la capacidad de identificar problemas antes en la etapa de revisión de los cambios propuestos. ClusterFuzzLite ya se implementó en los procesos de revisión de cambios en los proyectos systemd y curl, y permitió identificar errores omitidos por los analizadores estáticos y los linters utilizados en la etapa inicial de verificación del nuevo código.
ClusterFuzzLite admite la revisión de proyectos en C, C++, Java (y otros lenguajes basados en JVM), Go, Python, Rust y Swift. Las pruebas de fuzzing se llevan a cabo utilizando el motor LibFuzzer. También se pueden llamar a las herramientas AddressSanitizer, MemorySanitizer y UBSan (UndefinedBehaviorSanitizer) para identificar errores y anomalías de la memoria.
Características clave de ClusterFuzzLite: verificación rápida de los cambios propuestos para encontrar errores antes de la aceptación del código; descargar informes sobre las condiciones de los accidentes; la capacidad de pasar a pruebas de fuzzing más avanzadas para identificar errores más profundos que no surgieron después de verificar los cambios de código; generación de informes de cobertura para evaluar la cobertura del código durante las pruebas; Arquitectura modular que permite seleccionar la funcionalidad requerida.
Recordemos que las pruebas de fuzzing implican generar un flujo de todo tipo de combinaciones aleatorias de datos de entrada que se aproximan a los datos reales (por ejemplo, páginas html con parámetros de etiquetas aleatorios, archivos o imágenes con títulos anómalos, etc.), y es posible grabar fallas en el proceso de su procesamiento. Si una secuencia falla o no coincide con la respuesta esperada, es muy probable que este comportamiento indique un error o vulnerabilidad.
Fuente: opennet.ru