💻 computer science

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

Este artigo apresenta uma prova formal de que um único programa C, denominado "Vulnerability Factory", pode conter um conjunto infinitamente enumerável de vulnerabilidades distintas, introduzindo o conceito de "abundância de vulnerabilidades" para analisar sua distribuição dinâmica em relação à linguagem de programação e ao uso no mercado, ao mesmo tempo que distingue teoricamente a existência infinita de falhas da sua exploração prática limitada.

Autores originais: Eireann Leverett, Jeroen van der Ham-de Vos

Publicado 2026-04-10

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Eireann Leverett, Jeroen van der Ham-de Vos

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está em uma fábrica de brinquedos, mas em vez de bonecas ou carros, essa fábrica produz falhas de segurança (vulnerabilidades) para computadores.

Este artigo de pesquisa, escrito por dois especialistas em segurança, apresenta uma prova matemática de que essa fábrica pode produzir um número infinito de falhas diferentes. Eles chamam essa máquina de "Fábrica de Vulnerabilidades".

Aqui está a explicação do que eles descobriram, usando analogias do dia a dia:

1. A Fábrica Infinita (O Problema)

Normalmente, pensamos que um programa de computador tem um número fixo de erros. Se você consertar um, sobram 99, depois 98, até chegar a zero.

Os autores dizem: "Não, isso não funciona assim."

Eles criaram um pequeno programa (uma "Fábrica") que, cada vez que você o roda, cria um novo arquivo de código com 5 erros novos.

A Analogia: Imagine uma impressora que, a cada clique, imprime um bilhete com um erro de português diferente. Se você apertar o botão 100 vezes, terá 500 erros. Se apertar 1 milhão de vezes, terá 5 milhões. Como você pode apertar o botão para sempre, o número de erros é infinito.
O Resultado: Eles provaram matematicamente que, dentro do universo do código de computador, existem infinitas falhas possíveis. Não importa o quanto você conserte, sempre haverá mais uma nova "especie" de erro esperando para ser descoberta.

2. A Abundância de Vulnerabilidades (A Nova Medida)

Se há infinitos erros, como podemos gerenciá-los? O artigo introduz um conceito novo chamado "Abundância de Vulnerabilidades".

A Analogia da Química: Pense nos elementos químicos. No universo, o Hidrogênio é superabundante (73% de tudo), enquanto o Ouro é muito raro.
Aplicação ao Código: Da mesma forma, alguns tipos de erros são "Hidrogênio" (muito comuns) e outros são "Ouro" (raros).
- Em linguagens antigas como C e C++, erros de memória (como vazamentos ou estouro de buffer) são o "Hidrogênio": estão em todo lugar.
- Em linguagens modernas e seguras, esses erros desaparecem, mas surgem outros tipos, como erros de lógica ou injeção de comandos.
A Lição: Em vez de tentar contar todos os erros (o que é impossível porque são infinitos), devemos medir quais tipos são mais comuns em cada linguagem e sistema. Isso ajuda a saber onde focar nossos esforços.

3. Erros Infinitos vs. Explorações Finitas (O Perigo Real)

Aqui está a parte mais importante para o seu dia a dia: Ter infinitos erros não significa que estamos todos em perigo infinito.

A Analogia do Tesouro: Imagine que existem infinitas moedas de ouro espalhadas pelo mundo (os erros). Mas, para roubar uma, você precisa de um mapa específico e uma chave (o "exploit" ou ataque).
A Realidade: Os hackers não têm tempo ou dinheiro para criar chaves para todos os erros infinitos. Eles só criam chaves para as portas que estão em casas muito famosas (softwares muito usados).
O Fator Mercado: Se um erro existe em um software que 90% das pessoas usam (como o Windows ou um navegador popular), um único ataque pode derrubar quase tudo. Se o erro está em um software que só 0,01% das pessoas usam, mesmo que seja um erro "infinito", ele raramente será atacado.
A Estatística: O artigo diz que menos de 6% de todas as falhas conhecidas são realmente exploradas por hackers. A maioria fica lá, esperando, sem nunca ser usada.

4. Por que isso importa para nós?

O objetivo do artigo não é assustar dizendo "é tudo perdido", mas sim mudar a estratégia:

Pare de tentar achar tudo: Como os erros são infinitos, tentar achar e corrigir cada um é como tentar esvaziar o oceano com uma colher. É impossível.
Foque na Abundância: Devemos mudar a linguagem de programação para aquelas que naturalmente não produzem os erros mais comuns (como mudar de C para Rust ou Python). É como mudar de uma mina de carvão (cheia de erros) para uma mina de diamantes (mais segura).
Entenda o Risco: O perigo real não é a quantidade total de erros, mas a combinação de erros comuns + software muito usado.

Resumo Final

Os autores provaram matematicamente que o código de computador é um oceano infinito de falhas. Não podemos secar esse oceano. Mas, entendendo quais "correntes" (tipos de erros) são mais fortes e onde os "navios" (softwares populares) estão navegando, podemos construir barcos mais seguros e evitar os furacões mais perigosos.

A mensagem final é: Não tente contar o infinito. Aprenda a navegar nele com sabedoria.

Resumo Técnico: Abundância de Vulnerabilidades – Uma Prova Formal de Vulnerabilidades Infinitas no Código

Autores: E. Leverett (Concinnity Risks Ltd.) e J. van der Ham-de Vos (Universidade de Twente).
Contexto: Workshop de Novos Paradigmas de Segurança (NSPW '26).

1. O Problema

A comunidade de segurança cibernética debate há décadas se o conjunto de vulnerabilidades de software é finito (escasso) ou infinito (denso).

Visão Escassa: Se as vulnerabilidades forem finitas, a estratégia de "encontrar e corrigir" (patching) eventualmente esgotará o risco, tornando a segurança alcançável.
Visão Densa: Se forem infinitas, o esforço de correção é um "trabalho de Sísifo", onde corrigir uma vulnerabilidade é irrelevante para a segurança geral, pois novas surgem continuamente.
O Dilema: Argumentos anteriores baseavam-se em complexidade computacional ou teoria da computação (como o Teorema de Rice), mas faltava uma prova construtiva e executável que demonstrasse a existência de um número infinito de vulnerabilidades distintas em um único programa.

2. Metodologia

Os autores utilizam uma abordagem híbrida combinando teoria dos conjuntos, verificação formal e teoria da computabilidade:

Construção do "Vulnerability Factory" (Fábrica de Vulnerabilidades):
- Desenvolveram um programa em C de 622 linhas (vuln_factory.c).
- O programa possui um Conjunto Base (B) com 11 funções, cada uma contendo uma vulnerabilidade clássica de uma classe CWE distinta (ex: estouro de buffer, injeção de comando, uso após liberação).
- Possui um Gerador (G) que, a cada execução, lê um contador persistente $n$ , gera um novo módulo de código fonte (vuln_module_n.c) contendo 5 vulnerabilidades parametrizadas por $n$ , compila-o como uma biblioteca compartilhada e incrementa o contador.
- A parametrização (ex: tamanho do buffer = $16 + n$ ) garante que cada módulo seja um componente de software distinto com condições de exploração únicas.
Formalização Matemática:
- Utilizam a teoria dos conjuntos para definir um conjunto de vulnerabilidades $V$ .
- Aplicam as regras de atribuição de CVE (Common Vulnerabilities and Exposures) da MITRE para validar que cada instância gerada merece um identificador único (são componentes distintos, fixáveis independentemente e com causas raiz distintas).
- Modelam o sistema como uma Máquina de Turing para provar que a geração de vulnerabilidades é computável e decidível dentro do contexto da estrutura do código.
Análise de Model Checking:
- O sistema é modelado como um sistema de transição onde o estado inclui o contador e o conjunto acumulado de vulnerabilidades. Propriedades de segurança (como "o número de vulnerabilidades é limitado por C") são refutadas pelo verificador de modelo, que gera contra-exemplos para qualquer limite finito.

3. Principais Contribuições

Prova Construtiva de Infinito: Apresentam o primeiro exemplo concreto de um único programa que admite um conjunto contável e infinito de vulnerabilidades distintas e atribuíveis a CVEs.
Artefato de Prova Reutilizável: Formalizam a "Fábrica de Vulnerabilidades" como uma Máquina de Turing, estabelecendo-a como um "objeto de teste" fundamental para futuros resultados formais na teoria de vulnerabilidades (análogo à função Busy Beaver na teoria da computabilidade).
Conceito de "Abundância de Vulnerabilidades": Introduzem uma nova métrica análoga à abundância de elementos químicos. Define-se a abundância como a distribuição proporcional de classes de vulnerabilidades (CWEs) em um corpus de software, influenciada pela linguagem de programação e arquitetura.
Distinção Crítica entre Vulnerabilidade e Exploração: Clarificam que, embora as vulnerabilidades sejam infinitas, as explorações (exploits) são finitas e raras. A frequência de exploração depende da interação entre a abundância da vulnerabilidade e a participação de mercado do software afetado.
Resolução do Debate Densa vs. Escassa: Provam que o universo de vulnerabilidades é denso (infinito), mas o risco prático é governado pela concentração de implantação de software.

4. Resultados Chave

Cardinalidade Infinita: O conjunto de vulnerabilidades gerado pela Fábrica tem cardinalidade $\aleph_0$ (infinito contável). Mesmo que algumas instâncias sejam invalidadas por critérios de CVE, o conjunto restante permanece infinito (robustez cofinita).
Validação de CVE: Cada módulo gerado ( $M_n$ ) é uma biblioteca compartilhada distinta. Segundo as regras da MITRE, vulnerabilidades em componentes distintos recebem CVEs distintos, independentemente de serem da mesma classe de erro.
Limites Práticos vs. Teóricos: Embora a implementação em C use um contador de 32 bits (limitando a ~10 bilhões de vulnerabilidades), a formalização como Máquina de Turing remove essa limitação, provando a existência teórica de um infinito real.
O "Princípio do Pequeno Explorador": Apenas um pequeno número de exploits é necessário para saturar a população de máquinas vulneráveis, pois a implantação de software é altamente concentrada (monocultura). Um exploit contra um sistema dominante (ex: Windows, Linux, Python) afeta mais do que milhares de exploits contra software de nicho.

5. Significado e Implicações

Mudança de Paradigma na Gestão de Risco: A estratégia de "corrigir tudo" é impossível. A segurança deve focar em medir a abundância de classes de vulnerabilidades e entender como elas interagem com a implantação de software.
Impacto Econômico e de Design de Linguagens: A escolha da linguagem de programação atua como "nucleossíntese", determinando quais "elementos" (vulnerabilidades) são possíveis.
- Linguagens inseguras (C/C++) geram abundância de erros de memória.
- Linguagens seguras (Rust, Go) eliminam certas classes, mas podem introduzir outras (lógica, injeção).
- Migrar para linguagens seguras altera a distribuição de abundância, reduzindo o risco sistêmico de corrupção de memória.
Previsão de Risco Cibernético: A abundância de vulnerabilidades, combinada com dados de participação de mercado, permite criar perfis de risco probabilísticos mais precisos do que apenas contar CVEs.
Futuro da Pesquisa: O "Vulnerability Factory" serve como um benchmark para ferramentas de análise estática e model checking, desafiando-as a lidar com conjuntos de testes infinitos e paramétricos.

Conclusão Final:
O artigo conclui que o oceano de vulnerabilidades é infinito, mas a frota de explorações é pequena e guiada pela concentração de mercado. O objetivo não é esvaziar o oceano, mas mapear suas correntes (abundância) e entender onde o risco se concentra. A "Abundância de Vulnerabilidades" é proposta como a métrica correta para guiar investimentos em prevenção e análise de risco cibernético.