A empresa Google apresentou o projeto ClusterFuzzLite, que permite organizar testes de fuzzing no código para a identificação precoce de potenciais vulnerabilidades durante o funcionamento de sistemas de integração contínua. Atualmente, o ClusterFuzz pode ser utilizado para automatizar testes de fuzzing em pull requests no GitHub Actions, no Google Cloud Build e no Prow, mas espera-se que no futuro haja suporte para outros sistemas de CI. O projeto é baseado na plataforma ClusterFuzz, criada para coordenar o trabalho de clusters de testes de fuzzing, e é distribuído sob a licença Apache 2.0.
Observa-se que após a implementação, em 2016, do serviço OSS-Fuzz pela Google, mais de 500 projetos abertos importantes foram incorporados ao programa de testes de fuzzing contínuo. Com base nas verificações realizadas, mais de 6500 vulnerabilidades confirmadas foram eliminadas e mais de 21 mil erros corrigidos. O ClusterFuzzLite continua a desenvolver mecanismos de testes de fuzzing com a possibilidade de identificar problemas mais cedo na fase de revisão das alterações propostas. O ClusterFuzzLite já foi integrado nos processos de revisão de mudanças nos projetos systemd e curl, permitindo a identificação de erros que foram ignorados pelos analisadores estáticos e linters usados na fase inicial de verificação do novo código.
O ClusterFuzzLite suporta a verificação de projetos nas linguagens C, C++, Java (e outras linguagens baseadas em JVM), Go, Python, Rust e Swift. Os testes de fuzzing são realizados utilizando o mecanismo LibFuzzer. Para a identificação de erros relacionados à memória e anomalias, também podem ser invocados ferramentas como AddressSanitizer, MemorySanitizer e UBSan (UndefinedBehaviorSanitizer).
As principais funcionalidades do ClusterFuzzLite incluem: verificação rápida das alterações propostas para identificar erros antes da aceitação do código; envio de relatórios sobre as condições que causam falhas; possibilidade de transição para testes de fuzzing mais avançados para identificar erros mais profundos, que não afloraram após a verificação da alteração do código; geração de relatórios de cobertura para avaliar a cobertura do código durante a testagem; arquitetura modular, permitindo a escolha da funcionalidade necessária.
Lembramos que, durante os testes de fuzzing, é gerado um fluxo de várias combinações aleatórias de dados de entrada, aproximando-se dos dados reais (por exemplo, páginas html com parâmetros de tags aleatórias, arquivos compactados ou imagens com cabeçalhos anômalos, etc.), e registra-se possíveis falhas durante o processamento deles. Se alguma sequência levar a uma falha ou não corresponder à reação esperada, tal comportamento, com alta probabilidade, indica um erro ou vulnerabilidade.
Fonte: opennet.ru
