Four Ways to Forge a Bundle My Own Verifier Calls Clean: Refusal-Site Mutation Testing of an Evidence-Bundle Verifier

No mundo digital moderno, os sistemas de software frequentemente dependem de uma ideia simples, mas poderosa: confiar, mas verificar. Quando um programa de computador afirma ter resolvido um problema difícil ou analisado um conjunto massivo de dados, ele produz um relatório. Para garantir que este relatório seja honesto, outros programas atuam como auditores. Esses auditores verificam a matemática, verificam se os arquivos de dados não foram adulterados e confirmam se os números no resumo correspondem às evidências brutas. Se tudo estiver correto, o auditor dá uma luz verde, e o resultado é publicado para o mundo ver. Este processo é a espinha dorsal de um software confiável, permitindo que estranhos confiem no trabalho uns dos outros sem precisar conhecê-los. No entanto, para que este sistema funcione, o próprio auditor deve ser perfeito. Se o auditor falhar em detectar uma mentira, ou pior, se declarar uma mentira como verdadeira sem sequer olhar para as evidências, todo o sistema entra em colapso. O perigo não é apenas que um resultado ruim passe despercebido, mas que o auditor possa estar tão quebrado que aprova um teste sem sequer ter executado o teste.

Um pesquisador chamado Erik Hill propôs-se a examinar um desses auditores, um programa projetado para verificar pacotes de evidências para um sistema offline. Ele queria saber uma questão específica e inquietante: com que frequência esse programa diz "passou" quando, na verdade, não verificou nada? Para descobrir, ele não apenas procurou por bugs; ele construiu uma ferramenta para quebrar sistematicamente seu próprio auditor. Ele pegou cada linha de código do programa que deveria rejeitar um pacote ruim e, uma a uma, desligou-as. Então, ele observou para ver se o conjunto de testes do programa notaria. Se os testes ainda passassem após a remoção de uma linha de rejeição, significava que aquela linha de rejeição era um peso morto — ela não estava realmente fazendo nenhum trabalho. Os resultados foram surpreendentes. No início do estudo, dois terços dos pontos de rejeição do auditor eram invisíveis para os testes. O programa poderia ser despojado da maior parte de sua capacidade de dizer "não" e ainda assim reportaria uma pontuação perfeita. Era como se um segurança tivesse sido treinado para verificar itens roubados, mas os exercícios de treinamento nunca tivessem incluído um item roubado, de modo que o segurança nunca aprendeu a procurar por um.

O estudo começou com um choque de um especialista externo. Um engenheiro independente enviou um pacote de evidências onde os números principais eram completamente falsos, mas o auditor imprimiu um "passou" perfeito. A fraude custou apenas quatro bytes para ser criada. O engenheiro havia substituído um arquivo por um pequeno marcador de posição vazio e, como o auditor falhou em verificar se aquele arquivo estava realmente lá, ele assumiu que estava tudo bem. Hill corrigiu esse buraco específico, mas então aplicou sua própria ferramenta sistemática ao programa reparado. Ele descobriu que o problema não era apenas um erro, mas um padrão. Ele descobriu mais quatro maneiras de enganar o auditor, descobrindo, a cada vez, que o programa estava pulando uma verificação inteira. Um desses truques envolvia alterar uma única letra maiúscula em um rótulo de severidade, o que fazia o programa ignorar o peso de uma falha de verificação. Outro envolvia deletar uma chave de uma lista, fazendo o programa pular uma comparação porque o item que ele deveria comparar estava ausente. Em todos os casos, o programa não estava falhando em fazer um cálculo difícil; estava simplesmente falhando em iniciar o cálculo.

Para medir o quão disseminado este problema era, Hill executou sua ferramenta de deleção contra o código do auditor. Ele encontrou 112 lugares onde o programa deveria dizer "não". Quando ele os removeu um por um, 75 deles puderam ser deletados sem que qualquer teste falhasse. Isso significava que 75 de 112 pontos de rejeição eram efetivamente invisíveis para as verificações de segurança do sistema. O programa tinha uma pontuação de 0,330, indicando que apenas cerca de um terço de seus mecanismos de recusa estavam sendo realmente testados. Os dois terços restantes eram "passagens vácuas" — verificações que reportavam sucesso mesmo sem examinar as evidências. Isso não é um glitch raro; é uma falha estrutural onde a rede de segurança tem buracos pelos quais ninguém jamais tentou cair. Os testes estavam verificando se o programa rodava, não se ele realmente olhava para os dados.

Hill então testou uma abordagem comum para corrigir tais problemas: simplesmente corrigir os bugs específicos que foram encontrados e adicionar um teste para cada um deles. Ele corrigiu as quatro falsificações que havia descoberto e adicionou novos testes para garantir que esses truques específicos não funcionassem novamente. Surpreendentemente, isso não melhorou a pontuação geral de segurança. O programa ainda tinha os mesmos 75 pontos de rejeição invisíveis. Os novos testes cobriam apenas os novos buracos que ele acabara de remendar, deixando o resto do sistema tão cego quanto antes. Foi apenas quando ele mudou sua estratégia que os números se moveram. Em vez de corrigir bugs, ele escreveu um novo teste para cada um dos 75 pontos de rejeição invisíveis, forçando o programa a provar que poderia realmente acionar cada um deles. Essa abordagem sistemática elevou a pontuação de 0,330 para 1,000, provando que cada ponto de rejeição poderia, de fato, ser disparado. A lição foi clara: corrigir bugs conhecidos não torna um sistema seguro; você deve provar que cada um dos mecanismos de segurança pode realmente funcionar.

O estudo também revelou um problema mais profundo sobre como esses sistemas são construídos. O pesquisador descobriu que o auditor frequentemente tratava relatórios legíveis por humanos de forma diferente dos arquivos de dados brutos usados para a verificação. Quando um pacote incluía um relatório destinado à leitura de uma pessoa, o auditor frequentemente falhava em verificar se o relatório correspondia aos dados subjacentes. Era como se o auditor confiasse na página de resumo, mas ignorasse os recibos. Isso aconteceu em vários projetos diferentes, sugerindo um hábito comum entre desenvolvedores: eles vinculam os dados que o computador verifica, mas deixam os dados que os humanos leem sem verificação. O pesquisador descobriu que essa lacuna permitia que falsas alegações passassem, onde um relatório poderia dizer "todos os defeitos corrigidos" enquanto os dados mostravam o contrário.

Ao longo do estudo, as próprias ferramentas do pesquisador falharam com ele de maneiras que espelhavam o próprio problema que ele estava estudando. Seus instrumentos de medição às vezes reportavam sucesso mesmo quando não estavam medindo nada. Em uma instância, uma ferramenta projetada para detectar falhas retornou uma pontuação perfeita porque o conjunto de testes de base já havia falhado, fazendo com que a ferramenta interpretasse o erro como um sucesso. Isso aconteceu sete vezes durante a pesquisa, incluindo uma vez em que a ferramenta deu uma pontuação perfeita enquanto o sistema estava quebrado. Essas falhas não foram ocultadas; elas foram documentadas no artigo para mostrar que as ferramentas usadas para verificar o software são tão vulneráveis a esses erros de "passagem vazia" quanto o próprio software que devem verificar.

A conclusão final do trabalho é um apelo para um tipo diferente de teste. O pesquisador argumenta que não podemos confiar em uma lista de bugs conhecidos para manter um sistema seguro. Se um sistema possui um portão de segurança que nunca foi observado falhando, ele nunca foi observado funcionando. A única maneira de ter certeza é testar sistematicamente cada um dos portões para garantir que eles possam realmente disparar. O estudo mostrou que um sistema pode parecer perfeito no papel enquanto é fundamentalmente quebrado na prática. Ao forçar o auditor a provar que poderia rejeitar dados ruins de todas as formas possíveis, o pesquisador transformou um sistema que era cego para suas próprias falhas em um que era totalmente verificado. O trabalho permanece como um lembrete de que, no mundo da confiança digital, o erro mais perigoso não é uma verificação falha, mas uma verificação que nunca aconteceu de fato.