💻 computer science

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

El artículo presenta una demostración formal de que un solo programa en C puede contener un conjunto infinito de vulnerabilidades distintas, introduciendo el concepto de "abundancia de vulnerabilidades" para analizar su distribución y su relación con los riesgos cibernéticos.

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

Publicado 2026-04-10

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

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

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que el código informático es como un gigantesco océano. Durante años, los expertos en seguridad han debatido una pregunta fundamental: ¿Este océano tiene un fondo? ¿Podemos, en teoría, encontrar todos los agujeros (vulnerabilidades) en el software, parchearlos y dejar el mundo seguro?

Este paper, titulado "Abundancia de Vulnerabilidades", llega con un mensaje contundente y un poco inquietante: El océano no tiene fondo. Es infinito.

Aquí te explico la idea central usando analogías sencillas:

1. La "Fábrica de Vulnerabilidades" (El Experimento)

Los autores crearon un pequeño programa de computadora (llamado "Fábrica de Vulnerabilidades") que funciona como una máquina de copiar y pegar con un giro malvado.

Cómo funciona: Imagina una máquina que escribe un nuevo libro cada vez que la enciendes. Pero en lugar de escribir una historia, escribe un pequeño programa de computadora.
El truco: Cada vez que la máquina escribe un nuevo programa, le añade un "defecto" único. Si la primera vez el defecto es un agujero en la pared de 10 centímetros, la segunda vez será de 11 centímetros, la tercera de 12, y así sucesivamente.
El resultado: Como la máquina puede seguir escribiendo números para siempre (1, 2, 3... hasta el infinito), puede crear un número infinito de programas, cada uno con un defecto ligeramente diferente.

La conclusión matemática: Si un solo programa puede generar infinitos defectos distintos, entonces todo el software del mundo tiene infinitas vulnerabilidades posibles. No importa cuántos parches pongamos; siempre habrá uno nuevo esperando ser creado.

2. La Analogía Química: "Abundancia"

Dado que no podemos contar hasta el infinito, los autores proponen dejar de contar y empezar a medir la abundancia.

La analogía: Piensa en los elementos químicos. En el universo, el Hidrógeno es el elemento más abundante (hay muchísimo). El Oro es muy raro.
Aplicado al software: Algunos tipos de errores son como el Hidrógeno (muy comunes, como los errores de memoria en programas escritos en C). Otros son como el Oro (muy raros).
El mensaje: No todos los errores son iguales. El lenguaje de programación que usas determina qué "elementos" (errores) son posibles. Si usas un lenguaje antiguo y peligroso, tu "universo" estará lleno de Hidrógeno (errores de memoria). Si usas uno moderno y seguro, tendrás menos Hidrógeno, pero quizás más "Carbono" (errores de lógica).

3. El Gran Malentendido: ¿Infinitos errores = Infinitos ataques?

Aquí está la parte más importante para entender la seguridad real.

El error infinito: Sí, hay infinitos agujeros teóricos en el software.
Los ataques reales: Pero, ¿quién va a intentar explotarlos todos? Casi nadie.

Imagina que tienes un castillo con un millón de puertas.

La teoría: Hay infinitas formas de abrir esas puertas (infinitas vulnerabilidades).
La realidad: Los ladrones (hackers) solo tienen tiempo y dinero para probar tres o cuatro puertas específicas.

Los autores explican que menos del 6% de los errores conocidos en el mundo son realmente explotados por hackers. ¿Por qué? Porque crear un "ataque" (un exploit) es caro, difícil y requiere mucho trabajo. Es como si un ladrón tuviera que fabricar una llave maestra única para cada una de las infinitas cerraduras. No vale la pena.

4. El Factor "Popularidad" (El Efecto Multiplicador)

¿Qué hace que un error sea peligroso? Cuántas personas lo usan.

Si un error está en un programa que usa solo el 0.1% de la gente, aunque sea un error terrible, no es un gran problema global.
Si ese mismo error está en un sistema operativo que usan el 90% de las computadoras del mundo, es una catástrofe.

Los autores dicen que el riesgo no depende solo de cuántos errores hay, sino de dónde están. Un solo ataque a un sistema muy popular puede afectar a millones de personas, mientras que miles de ataques a sistemas raros no afectan a nadie.

En Resumen: ¿Qué nos dice esto?

No podemos ganar la carrera: No podemos "parchear todo" porque el software es tan complejo que siempre habrá infinitas formas de romperlo.
Cambia el enfoque: En lugar de intentar encontrar todos los errores, debemos entender cuáles son los más comunes (la abundancia) y dónde se usan más (la popularidad).
La economía importa: Los hackers atacan donde hay más "botín" y donde es más fácil. Si cambiamos los lenguajes de programación para que sean más seguros (menos "Hidrógeno" tóxico), reduciremos la abundancia de los errores más peligrosos.

La moraleja: No intentes vaciar el océano de agua. En su lugar, aprende a navegarlo, entiende dónde están las corrientes peligrosas y construye barcos (software) que no se hundan tan fácilmente.

Resumen Técnico: Vulnerability Abundance

1. El Problema

La comunidad de seguridad cibernética ha debatido durante décadas si el stock de vulnerabilidades de software no descubiertas es finito (y, por tanto, agotable mediante parches exhaustivos) o infinito (densamente poblado).

La dicotomía: Si las vulnerabilidades son escasas (sparse), corregirlas reduce significativamente la exposición. Si son densas (dense), corregir una sola es irrelevante para la seguridad general.
La limitación actual: Argumentos previos basados en la teoría de la computabilidad (como el problema de la parada o el teorema de Rice) sugieren teóricamente que las vulnerabilidades podrían ser ilimitadas, pero carecían de una demostración constructiva y ejecutable. Además, existe confusión entre la existencia de vulnerabilidades y la existencia de exploits (códigos de explotación).

2. Metodología

Los autores emplean un enfoque multidisciplinario que combina teoría de conjuntos, teoría de la computabilidad, análisis formal y economía de la seguridad:

Construcción Constructiva ("La Fábrica de Vulnerabilidades"):
- Desarrollaron un programa en C de 622 líneas llamado Vulnerability Factory.
- Este programa contiene un conjunto base de 11 vulnerabilidades clásicas (de diferentes clases CWE) y un generador ( $G$ ).
- En cada ejecución, el generador lee un contador persistente $n$ , crea un nuevo módulo de código fuente (vuln_module_n.c) con 5 vulnerabilidades parametrizadas (donde parámetros como tamaños de búfer, umbrales de desbordamiento y direcciones de memoria dependen de $n$ ), y lo compila en una biblioteca compartida.
- Cada módulo generado es un componente de software distinto y corregible independientemente.
Formalización Matemática:
- Utilizan teoría de conjuntos elemental para demostrar que el conjunto de vulnerabilidades generadas es numerablemente infinito ( $\aleph_0$ ).
- Verifican que cada vulnerabilidad cumple con las Reglas de Asignación de CVE de MITRE (identificable, corregible independientemente y con un tipo CWE reconocido).
Caracterización de Máquina de Turing:
- Formalizan el generador como una Máquina de Turing (MT) para situar el resultado dentro de la teoría clásica de la computabilidad, demostrando que la generación de vulnerabilidades es un proceso computable y decidible en su estructura.
Modelo de Abundancia Química:
- Introducen la analogía de la abundancia elemental química para describir la distribución proporcional de tipos de vulnerabilidades en el ecosistema de software, influenciada por el lenguaje de programación y la arquitectura.

3. Contribuciones Clave

El artículo presenta cinco contribuciones principales:

Prueba de Infinitud Constructiva: Demuestran rigurosamente que un solo programa (la Fábrica de Vulnerabilidades) puede generar un conjunto numerablemente infinito de vulnerabilidades distintas y asignables a CVE.
Artefacto de Prueba Reutilizable: Formalizan el generador como una Máquina de Turing, proporcionando un "objeto de prueba" fundamental para futuros resultados formales en la teoría de vulnerabilidades (similar al uso de máquinas de Turing específicas en teoría de la computabilidad).
Concepto de Abundancia de Vulnerabilidades: Definen la Vulnerability Abundance como una métrica cuantitativa que describe la distribución proporcional de clases de vulnerabilidades, análoga a la abundancia de elementos químicos en el universo.
Distinción Crítica Vulnerabilidad vs. Explotación: Diferencian claramente entre la infinitud de las vulnerabilidades y la finitud (y rareza) de los exploits. Presentan evidencia empírica de que menos del 6% de las CVE publicadas son explotadas en la naturaleza.
Marco para el Análisis de Riesgo Cibernético: Proponen que medir la abundancia de vulnerabilidades y su interacción con la cuota de mercado del software es esencial para la prevención y la gestión de riesgos.

4. Resultados Principales

Teorema de Infinitud: El conjunto de vulnerabilidades $V$ generado por la Fábrica es infinito ( $|V| = \aleph_0$ ). Incluso si se invalidan un número finito de instancias o se eliminan ciertas plantillas de CWE, el conjunto restante sigue siendo infinito.
Robustez ante Objeciones:
- Objeción de la causa raíz: Aunque el patrón de código sea similar, las reglas de CVE asignan identificadores distintos a componentes de software distintos (bibliotecas compartidas compiladas por separado).
- Objeción de la finitud física: Aunque una implementación en C tiene límites de enteros, la formalización como Máquina de Turing utiliza una cinta de contador ilimitada, validando la infinitud teórica.
El Principio del "Pequeño Explotador": Aunque las vulnerabilidades son infinitas, el número de exploits necesarios para comprometer la mayoría de los sistemas es pequeño. Esto se debe a que la cuota de mercado del software está altamente concentrada (pocos monoculturos de software dominan). Un solo exploit contra un sistema dominante (ej. Windows, Linux kernel) tiene un impacto desproporcionado comparado con miles de exploits contra software de nicho.
Abundancia Dinámica: La distribución de vulnerabilidades no es estática; cambia según la popularidad de los lenguajes de programación (ej. el paso de C/C++ a Rust reduciría la abundancia de corrupción de memoria pero aumentaría la de errores de lógica o inyección).

5. Significado e Implicaciones

Cambio de Paradigma en la Seguridad: La estrategia de "parchear hasta agotar" es matemáticamente imposible. La seguridad debe centrarse en entender la abundancia y la distribución de las vulnerabilidades, no en contarlas.
Economía de la Seguridad: La abundancia de vulnerabilidades en lenguajes inseguros (como C/C++) justifica económicamente la migración a lenguajes seguros (Rust, Go), ya que elimina clases enteras de vulnerabilidades "abundantes".
Gestión de Riesgos: Los modelos de riesgo deben incorporar la cuota de mercado como un multiplicador. El riesgo sistémico no proviene de la cantidad total de vulnerabilidades, sino de la intersección entre vulnerabilidades abundantes y software ampliamente desplegado.
Herramienta Académica: La "Fábrica de Vulnerabilidades" sirve como un estándar de referencia para evaluar herramientas de análisis estático, verificación formal y bases de datos de vulnerabilidades, demostrando que ninguna base de datos finita puede ser completa.

Conclusión Final:
El artículo concluye que, dado que un solo programa puede albergar infinitas vulnerabilidades, el conjunto de todas las vulnerabilidades de software es necesariamente infinito. Sin embargo, el peligro real no reside en la infinitud de las vulnerabilidades, sino en la concentración del despliegue de software. La seguridad futura debe centrarse en mapear estas corrientes de abundancia y despliegue, en lugar de intentar vaciar el océano de vulnerabilidades.