Google presentou o sistema de proba de fuzzing ClusterFuzzLite

Google presentou o proxecto ClusterFuzzLite, que permite organizar probas fuzzing de código para a detección precoz de posibles vulnerabilidades durante o funcionamento dos sistemas de integración continua. Actualmente, ClusterFuzz pódese usar para automatizar as probas fuzz de solicitudes de extracción en GitHub Actions, Google Cloud Build e Prow, pero espérase compatibilidade con outros sistemas CI no futuro. O proxecto baséase na plataforma ClusterFuzz, creada para coordinar o traballo dos clusters de probas fuzzing, e distribúese baixo a licenza Apache 2.0.

Nótase que despois de que Google presentase o servizo OSS-Fuzz en 2016, máis de 500 proxectos importantes de código aberto foron aceptados no programa de probas continuas de fuzzing. En base ás probas realizadas, elimináronse máis de 6500 vulnerabilidades confirmadas e corrixíronse máis de 21 mil erros. ClusterFuzzLite continúa desenvolvendo mecanismos de proba de fuzzing coa capacidade de identificar problemas antes na fase de revisión dos cambios propostos. ClusterFuzzLite xa se implementou nos procesos de revisión de cambios nos proxectos systemd e curl, e permitiu identificar os erros que non perderon os analizadores estáticos e os linters utilizados na fase inicial de verificación do novo código.

ClusterFuzzLite admite a revisión de proxectos en C, C++, Java (e outras linguaxes baseadas en JVM), Go, Python, Rust e Swift. As probas de fuzzing realízanse mediante o motor LibFuzzer. Tamén se poden chamar ás ferramentas AddressSanitizer, MemorySanitizer e UBSan (UndefinedBehaviorSanitizer) para identificar erros e anomalías na memoria.

Características principais de ClusterFuzzLite: comprobación rápida dos cambios propostos para atopar erros antes da aceptación do código; descarga de informes sobre as condicións de accidente; a capacidade de pasar a probas de fuzzing máis avanzadas para identificar erros máis profundos que non apareceron despois de comprobar os cambios de código; xeración de informes de cobertura para avaliar a cobertura do código durante as probas; arquitectura modular que permite seleccionar a funcionalidade requirida.

Lembremos que as probas de fuzzing implican xerar un fluxo de todo tipo de combinacións aleatorias de datos de entrada que se aproximan aos datos reais (por exemplo, páxinas html con parámetros de etiquetas aleatorias, arquivos ou imaxes con títulos anómalos, etc.) e a posible gravación. fallos no proceso a súa tramitación. Se unha secuencia falla ou non coincide coa resposta esperada, é moi probable que este comportamento indique un erro ou unha vulnerabilidade.

Fonte: opennet.ru

Engadir un comentario