Se você acredita que colocar o seu projeto open source nas mãos do OSS-Fuzz significa “segurança garantida”, é melhor repensar essa ideia. Uma nova análise conduzida pelo GitHub Security Lab mostra que, mesmo após anos de fuzzing contínuo, vulnerabilidades graves ainda conseguem sobreviver em softwares amplamente utilizados no desktop Linux – e, por tabela, no dia a dia de quem joga, programa ou simplesmente consome mídia no PC.
O que é OSS-Fuzz e por que ele virou sinônimo de tranquilidade (talvez falsa)
Lançado pelo Google e hoje mantido em parceria com a OpenSSF Foundation, o OSS-Fuzz roda testes automatizados em mais de 1.300 projetos sem custo para os mantenedores. A plataforma já localizou milhares de bugs, mas confiar apenas nela equivale a colocar o alarme na casa sem trancar a porta: você reduz riscos, mas não zera o problema.
Estudo de caso #1 – GStreamer: dois fuzzers, 19 % de cobertura e 29 falhas novas
Responsável por todo o processamento de áudio e vídeo no ambiente GNOME (incluindo Ubuntu), o GStreamer foi intensamente testado desde 2017. Ainda assim, só contava com duas instâncias de fuzzer ativas e uma cobertura de código de apenas 19 %. Resultado? Em dezembro de 2024, 29 vulnerabilidades inéditas (várias de alto risco) vieram à tona – prova de que quantidade e qualidade de fuzzers importam tanto quanto o tempo de exposição.
Estudo de caso #2 – Poppler & DjVuLibre: quando a dependência vira elo fraco
Poppler, biblioteca padrão para renderizar PDFs no Ubuntu, ostenta 16 fuzzers e aproximadamente 60 % de cobertura – números bem mais robustos. Mas uma falha de 1-click RCE em 2025 mostrou que isso não basta:
- Muitas de suas dependências externas (cairo, libpng, freetype) não eram instrumentadas pelo libFuzzer, deixando caminhos críticos sem feedback.
- Ainda pior, o leitor padrão de DjVu (DjVuLibre) nem sequer fazia parte da pipeline de fuzzing, embora fosse instalado por padrão nos visualizadores de documentos.
Moral da história: o software é tão seguro quanto o seu pacote mais frágil.
Estudo de caso #3 – Exiv2: o lado esquecido do encode
A biblioteca Exiv2, usada em GIMP e LibreOffice, já colheu frutos significativos do OSS-Fuzz desde 2021. Porém, pesquisas recentes desenterraram vulnerabilidades nas rotinas de codificação – uma superfície que a maioria dos caçadores de bugs ignora em favor do “lado decodificador”. Para workflows automatizados (geração de miniaturas, uploads em nuvem, backups de fotos), isso pode ser tão ou mais perigoso.
Por que o fuzzing contínuo falha – e o que fazer a respeito
O GitHub Security Lab propõe um workflow em cinco passos para elevar o jogo:
Imagem: Internet
- Preparação: remova checksums e aleatoriedade supérflua para facilitar a descoberta de casos extremos.
- Cobertura de código > 90 %: inclua encode, decode, sockets de entrada e saída.
- Cobertura de contexto: use context-sensitive coverage (1-gram, 2-gram, etc.) para rastrear a ordem de execução e não apenas o caminho.
- Cobertura de valores: guie o fuzzer a explorar faixas críticas de variáveis (por exemplo, tamanhos máximos, divisores, contadores de referência).
- Triagem manual: mesmo com relatórios automáticos, um especialista precisa interpretar falsos positivos e priorizar correções.
E as falhas “gigantes” ou “lentas”?
Alguns bugs exigem arquivos enormes (acima de 2 GB) ou horas de execução para se manifestarem – cenário em que a maioria dos fuzzers, otimizados para milhares de execuções por segundo, simplesmente desiste. Nesses casos, o caminho costuma passar por static analysis, concolic testing ou a boa e velha revisão manual de código.
Impacto prático para quem desenvolve (ou joga) no PC
Caso você utilize qualquer distro Linux para jogar, editar vídeos, programar microcontroladores ou minerar criptomoedas, bibliotecas como GStreamer, Poppler e Exiv2 estão rodando em segundo plano. Falhas nelas podem resultar em RCEs silenciosos, travamentos de serviços de mídia e queda de desempenho — tudo o que você não quer no meio de uma live ou enquanto compila aquele kernel personalizado.
Para empresas e times de desenvolvimento, investir em hardware parrudo (mais núcleos de CPU, NVMe rápidos) pode acelerar execuções de fuzzing locais – mas só terá efeito real se vier acompanhado de processo e supervisão humana.
Conclusão
Fuzzing contínuo segue sendo uma das ferramentas mais poderosas contra falhas de segurança em software complexo. Entretanto, como mostram GStreamer, Poppler e Exiv2, ele não é bala de prata. A combinação de cobertura ampla, visão contextual, análise de valores e intervenção humana é o que faz a diferença entre um produto “testado” e um produto robusto. Se você mantém um projeto open source – ou simplesmente depende dele para trabalhar e se divertir – vale a pena revisar suas métricas de fuzzing hoje mesmo.
Com informações de GitHub Security Lab
