Resumo Técnico: Geração de Harnesses de Fuzz com Garantia de Qualidade via o Framework dos Quatro Princípios

1. Declaração do Problema

O teste de fuzzing é a técnica dominante para descobrir vulnerabilidades de segurança de memória em software C/C++. No entanto, para código de bibliotecas, a eficácia do fuzzing depende inteiramente da qualidade do harness de fuzz—o programa que faz a ponte entre o motor do fuzzer e a API da biblioteca. Embora ferramentas automatizadas de geração de harnesses (por exemplo, FuzzGen, OSS-Fuzz-Gen, PromptFuzz) tenham escalado a criação desses harnesses, elas carecem de mecanismos sistemáticos para garantir a correção.

As ferramentas atuais dependem de sinais proxy, como sucesso na compilação, contagem de falhas (crashes) e cobertura de código. Esses são insuficientes: um harness pode compilar e executar enquanto viola contratos de API, usa incorretamente ciclos de vida de objetos ou contorna limites de segurança. Tais defeitos produzem relatórios de falhas falsos-positivos em taxas tão altas quanto 94% em trabalhos anteriores. À medida que Modelos de Linguagem Grandes (LLMs) tornam a geração de harnesses escalável, a qualidade descontrolada transforma essa escala em uma responsabilidade, deslocando o ônus de triagem para os mantenedores, que devem filtrar falhas induzidas por harnesses que imitam bugs reais de bibliotecas.

2. Metodologia: O Framework dos Quatro Princípios

Os autores introduzem o QuartetFuzz, um sistema autônomo de agente LLM projetado para impor a correção do harness antes que qualquer campanha de fuzzing comece. A inovação central é o framework dos Quatro Princípios, uma definição em nível de fonte da correção do harness com especificações matemáticas e verificações implementáveis:

1. P1: Correção Lógica: O próprio harness deve estar livre de bugs (por exemplo, estado obsoleto, vazamentos de recursos, manipulação incorreta de dados) que causam falhas independentes do comportamento da biblioteca.
2. P2: Conformidade com o Protocolo da API: O harness deve invocar a biblioteca alvo em uma ordem válida, respeitando ciclos de vida de objetos, restrições de parâmetros e sequências de inicialização.
3. P3: Respeito aos Limites de Segurança: O harness deve exercitar interfaces públicas em vez de contornar validações chamando código interno exclusivo.
4. P4: Adequação do Ponto de Entrada: O harness deve mirar pontos de entrada significativos e relevantes para a superfície de ataque, em vez de lógica auxiliar incidental.

Arquitetura do Sistema

O QuartetFuzz operacionaliza esses princípios através de um pipeline de quatro estágios:

• Estágio 1: Descoberta de Grupos Lógicos: Um agente explora o grafo de chamadas do projeto para identificar "Grupos Lógicos" candidatos (unidades funcionais como "analisar uma imagem PNG"). Ele classifica esses grupos por uma pontuação de perigo estática (baseada em operações inseguras alcançáveis) e seleciona entradas que satisfazem P3 (alcançabilidade de API pública) e P4 (adequação).
• Estágio 2: Pesquisa de Protocolo da API: Um agente dedicado coleta informações de protocolo (ordem de chamada, ciclo de vida, restrições) para os alvos selecionados analisando cabeçalhos, código-fonte e chamadores existentes. Isso produz um relatório de protocolo P2 estruturado, fundamentado em evidências de fonte verificáveis.
• Estágio 3: Build Orientado por Estática: O agente Gerador de Harnesses rascunha o código-fonte do fuzzer, incorporando o Grupo Lógico e o relatório P2. Ele executa um loop de compilação delimitado, usando análise estática e raciocínio semântico para verificar sub-verificações P1/P2 antes de produzir um binário compilável.
• Estágio 4: Validação Adversarial: Antes da submissão, o sistema emprega Sondagem Adversarial (AP). O agente gera "blobs de ataque" específicos projetados para disparar violações suspeitas de sub-verificações P1/P2. Estes são executados via duas sondas:
  • Verificação de Alcance: Verifica se a entrada direciona a execução para a API alvo (usando GDB).
  • Verificação de Execução: Verifica se o harness falha sob sanitizadores (ASan/LSan).
    Apenas harnesses que passam em todas as sondas selecionadas (ou seja, sem falhas induzidas pelo harness) prosseguem para o fuzzing.

3. Contribuições Principais

1. O Framework dos Quatro Princípios: A primeira definição em nível de fonte da correção do harness com especificações matemáticas, operacionalizada via verificações estáticas e sondagem adversarial em tempo de execução.
2. Pipeline de Garantia de Qualidade de Ponta a Ponta: Um sistema de agente LLM de quatro estágios que produz harnesses entregáveis prontos para mesclagem a montante, verificando P1–P4 antes que o fuzzing comece.
3. Conjunto de Dados de Avaliação Curado: Um conjunto de dados padrão-ouro de 100 harnesses rotulados e limpos em P1–P4 de 39 projetos, derivados de uma auditoria manual de 586 harnesses de produção, permitindo avaliação reproduzível contra fuzzers escritos por humanos.
4. Validação do Mundo Real: Implantação em 23 projetos de código aberto (C/C++, Java, JavaScript) demonstrando a capacidade do sistema de descobrir vulnerabilidades com uma baixa taxa de falsos positivos.

4. Resultados

O sistema foi avaliado em cinco perguntas de pesquisa (RQs):

• RQ1 (Auditoria): Aplicado como auditor post-hoc a 586 harnesses de produção do OSS-Fuzz em 70 projetos, o QuartetFuzz identificou 53 violações (9,0%). Desses, 45 foram confirmados pelos mantenedores e 35 foram corrigidos ou mesclados a montante. Crucialmente, reparar esses defeitos expôs 2 bugs latentes de biblioteca (incluindo uma leitura excessiva de buffer de pilha de 25 anos na implementação DES do OpenSSL) que os harnesses originais haviam mascarado. A auditoria também interceptou 14 falhas induzidas por harnesses que teriam sido relatórios falsos-positivos.
• RQ2 (Qualidade do Grupo Lógico): A seleção de entradas do agente correspondeu às escolhas de especialistas humanos em 91% dos casos (91/100) em um conjunto de dados padrão-ouro, mesmo quando os prompts careciam de nomes de função específicos.
• RQ3 (Geração vs. Baselines): No conjunto de dados de 100 casos, os harnesses gerados pelo QuartetFuzz alcançaram cobertura de código estatisticamente equivalente aos padrões-ouro escritos por humanos (equivalência TOST, $p < 10^{-10}$). Ele superou o OSS-Fuzz-Gen em 6,9–8,3 pontos percentuais e o PromeFuzz em 4,1–5,2 pontos percentuais em cobertura de linha/ramo. A taxa produtiva (compilação bem-sucedida e cobertura não nula) foi de 96%, comparada a 64% para o OSS-Fuzz-Gen e 74% para o PromeFuzz.
• RQ4 (Ablação): Remover a Sondagem Adversarial reduziu a taxa produtiva em 12pp; remover o relatório de protocolo P2 reduziu em 13pp, confirmando que esses componentes são críticos para a qualidade.
• RQ5 (Implantação): Implantado em 23 projetos, o sistema submeteu 42 relatórios de bugs. 29 foram corrigidos ou confirmados (incluindo 3 CVEs), com apenas 2 rejeitados como falsos positivos, resultando em uma taxa de FP de 4,8%—a menor entre os geradores baseados em LLM comparados. O sistema também identificou bugs em projetos Java (PDFBox) e JavaScript (GraalJS) usando apenas classificação por LLM.

5. Significado e Alegações

O artigo argumenta que a qualidade do harness é a restrição vinculativa na eficácia do fuzzing. Os autores afirmam que a abordagem tradicional de inferir correção a partir de logs de falhas após o fuzzing é insuficiente na era da geração escalável por LLMs. Em vez disso, a qualidade deve ser imposta via verificações em nível de fonte antes que o fuzzing comece.

O significado deste trabalho reside em:

• Mudança de Paradigma: Passar de "compila e executa?" para "o harness está correto?" como a métrica principal para geração automatizada.
• Redução do Ônus de Triagem: Ao interceptar falhas induzidas por harnesses (58 no total interceptadas na auditoria e geração) antes que cheguem aos mantenedores, o sistema aborda a principal preocupação dos mantenedores de OSS sobre ferramentas automatizadas.
• Desmascarando Bugs Latentes: Demonstrar que corrigir violações de protocolo de harness pode revelar bugs profundos e de longa latência de bibliotecas que estavam anteriormente ocultos por padrões de uso incorreto.
• Reprodutibilidade: Fornecer o primeiro conjunto de dados rotulado para qualidade de harness e tornar o sistema e as baselines de código aberto para permitir comparação rigorosa.

Os autores mantêm um tom modesto, reconhecendo que suas definições matemáticas são aproximadas por verificações sintáticas e raciocínio de LLM devido à indecidibilidade na análise de código-fonte. Eles posicionam o framework dos Quatro Princípios como uma "definição inicial" em vez de uma prova final, destinado a estabelecer uma fundação para trabalhos futuros em fuzzing automatizado e confiável.