Fundamentos de fuzz testing: entradas guiadas por cobertura, corpus e triagem de crashes

O que é

Fuzzing consiste em alimentar um programa com entradas geradas para encontrar crashes, travamentos e asserções violadas. Os fuzzers modernos são guiados por cobertura: a documentação do Go descreve um motor que modifica entradas, guarda as que alcançam código novo como adições "interessantes" a um corpus e reporta as entradas com falha depois de minimizá-las. Um fuzz target é uma função pequena que recebe bytes ou argumentos tipados e chama o código sob teste. A documentação do libFuzzer afirma que o corpus deveria, idealmente, ser alimentado com uma coleção variada de entradas válidas e inválidas, e que o fuzzer funciona sem sementes, mas com menos eficiência. O OSS-Fuzz executa fuzzers continuamente para projetos open source, usando os motores libFuzzer, AFL++, Honggfuzz e Centipede em combinação com sanitizers.

Por que importa

Parsers, decodificadores, handlers de protocolo e qualquer outro código que lide com bytes não confiáveis têm casos-limite que ninguém enumera: campos de tamanho que estouram, estruturas aninhadas mais fundo do que a pilha suporta, codificações que mudam no meio do fluxo. Um fuzzer explora esses casos de forma mecânica e, com sanitizers, detecta erros de memória que de outra forma passariam despercebidos. Em linguagens com segurança de memória, o ganho está em encontrar panics, loops infinitos, esgotamento de recursos e invariantes quebradas.

Como aplicar

• Escolha targets em que a entrada não seja confiável e o código seja rápido e determinístico; a documentação do Go pede targets que não dependam de estado global, porque eles rodam em workers paralelos.
• Escreva o target como uma verificação de propriedade, e não apenas como "não dá crash": ida e volta (decode(encode(x)) == x), comparação com uma implementação de referência ou verificação de invariantes após a chamada.
• Alimente o corpus com amostras reais e faça commit dele; faça commit também de cada entrada de crash minimizada como teste de regressão (o Go grava as entradas com falha em testdata/fuzz/ e as executa com um go test comum).
• Dê ao CI um orçamento curto (limite de tempo ou de iterações) e rode sessões longas de forma agendada ou por meio de um serviço como o OSS-Fuzz; minimize o corpus periodicamente (-merge=1 no libFuzzer) para que ele continue pequeno sem perder cobertura.
• Compile targets em C e C++ com os sanitizers de endereço e de comportamento indefinido.

Armadilhas

Um target que lê arquivos ou acessa a rede, ou que é lento, deixa o motor sem fôlego. O fuzzing encontra crashes, não respostas erradas, a menos que o target verifique alguma coisa. Targets não determinísticos geram relatórios que ninguém consegue reproduzir. A documentação do Go menciona um timeout de 1 segundo por execução, de modo que um caminho lento, mas legítimo, é reportado como travamento. Um fuzzer nunca prova a ausência de bugs; ele reduz a probabilidade dos tipos de bug que consegue provocar.