💻 computer science

Vulnerability Abundance: A formal proof of infinite vulnerabilities in code

Ce papier présente une preuve constructive démontrant qu'un seul programme C, nommé « Vulnerability Factory », peut contenir une infinité dénombrable de vulnérabilités distinctes, introduisant ainsi le concept d'« abondance des vulnérabilités » pour analyser leur distribution dans le corpus logiciel mondial et leur interaction avec les risques cybernétiques.

Auteurs originaux : Eireann Leverett, Jeroen van der Ham-de Vos

Publié 2026-04-10

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Eireann Leverett, Jeroen van der Ham-de Vos

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🛠️ Le Titre : "L'Abondance des Failles : La preuve qu'il existe une infinité de bugs"

Imaginez que vous êtes un plombier. Jusqu'à présent, vous pensiez qu'il y avait un nombre fini de fuites possibles dans les tuyaux de votre maison. Si vous trouviez et répariez toutes les fuites connues, vous seriez en sécurité.

Ce papier de recherche dit : "Non, vous vous trompez. Il y a une infinité de fuites possibles."

Voici comment les auteurs (E. Leverett et J. van der Ham-de Vos) le prouvent, en utilisant des métaphores simples.

1. La "Usine à Bugs" (Le cœur de la preuve)

Les chercheurs ont créé un petit programme informatique (un fichier C de 622 lignes) qu'ils appellent la "Vulnérabilité Factory" (Usine à Vulnérabilités).

L'analogie :
Imaginez une machine à café magique.

Vous appuyez sur un bouton (numéro 1) : elle sort une tasse avec une petite fissure à 1 mm du bord.
Vous appuyez sur le bouton (numéro 2) : elle sort une tasse avec une fissure à 2 mm du bord.
Vous appuyez sur le bouton (numéro 100) : elle sort une tasse avec une fissure à 100 mm du bord.

Cette machine ne s'arrête jamais. Elle peut produire des milliards, des billions, et même une infinité de tasses différentes, chacune ayant une fissure unique et spécifique.

Ce que cela signifie :
Dans le monde du code informatique, cette "machine" prouve mathématiquement que pour un seul programme, on peut générer une infinité de bugs différents. Chaque bug est si unique (taille de la mémoire, moment de l'erreur, etc.) qu'il mérite son propre numéro officiel (appelé CVE), comme une plaque d'immatriculation unique.

2. La différence entre "Bugs" et "Exploits" (La nuance cruciale)

C'est ici que le papier devient très important pour notre sécurité quotidienne.

Les Bugs (Vulnérabilités) : C'est comme les minéraux dans la croûte terrestre. Il y en a une infinité, dispersés partout. Certains sont du fer, d'autres de l'or, d'autres du cuivre.
Les Exploits (Piratages) : C'est comme les outils pour extraire ces minéraux.

La métaphore chimique :
Les auteurs comparent cela à la chimie.

Il existe une infinité de combinaisons chimiques possibles dans l'univers (comme il y a une infinité de bugs).
Mais, seuls quelques éléments (Hydrogène, Oxygène, Carbone) sont vraiment abondants et utiles pour construire des choses.
De même, bien qu'il y ait une infinité de bugs potentiels, seulement quelques-uns sont réellement dangereux et utilisés par les pirates.

Le chiffre clé :
Les chercheurs notent que moins de 6 % des bugs découverts sont jamais utilisés pour pirater quelque chose. La grande majorité sont comme des minerais rares et inutiles : ils existent, mais personne ne prend la peine de les creuser.

3. Pourquoi certains logiciels sont-ils plus dangereux ? (L'Abondance)

Le papier introduit le concept d'"Abondance des Vulnérabilités".

Les langages "dangereux" (C, C++) : Imaginez une usine qui produit uniquement des bombes à fragmentation. C'est le langage C. Il est très populaire, mais il permet des erreurs de mémoire (comme des débordements de tampon) très fréquentes. C'est comme si l'air que nous respirons contenait beaucoup de poussière toxique.
Les langages "sûrs" (Rust, Java, Python) : Imaginez une usine qui produit des jouets en plastique. Les erreurs de mémoire y sont impossibles, mais on peut toujours avoir des erreurs de logique (un jouet qui ne fonctionne pas comme prévu) ou d'injection (quelqu'un qui glisse un poison dans le jouet).

La leçon :
Le danger ne dépend pas seulement du nombre de bugs, mais de qui utilise le logiciel.
Si un logiciel très populaire (comme Windows ou un navigateur web) a un bug, c'est une catastrophe mondiale car tout le monde l'utilise. Si un logiciel obscur a un bug, peu de gens sont concernés.

C'est comme une épidémie : un virus mortel est dangereux s'il touche une ville entière, mais moins s'il touche un village isolé.

4. Conclusion : Que faire face à l'infini ?

La conclusion du papier est à la fois rassante et réaliste :

On ne peut pas tout réparer : Puisqu'il y a une infinité de bugs possibles, essayer de trouver et réparer tous les bugs est une tâche impossible (comme essayer de vider l'océan avec une cuillère). C'est ce qu'on appelle un "travail de Sisyphe".
Il faut changer de stratégie : Au lieu de chercher à éliminer chaque bug, nous devons comprendre quels types de bugs sont les plus fréquents (l'abondance) et quels logiciels sont les plus utilisés.
L'objectif : Ne pas essayer de rendre le code parfait (ce qui est impossible), mais réduire les risques là où ils sont les plus probables et les plus dangereux.

En résumé :
Ce papier nous dit : "Arrêtez de paniquer à l'idée qu'il reste des bugs cachés. Il y en a une infinité, c'est normal. Concentrez-vous plutôt sur les logiciels que tout le monde utilise et sur les types d'erreurs les plus courants. C'est là que se joue la vraie sécurité."

C'est un changement de perspective : on passe de la chasse aux bugs (impossible) à la gestion des risques (réaliste).

1. Problématique

L'article s'attaque à une question fondamentale en sécurité informatique : les vulnérabilités logicielles sont-elles finies ou infinies ?
Ce débat oppose deux visions :

Vulnérabilités rares (Sparse) : Si le nombre de vulnérabilités est fini et déclinant, une stratégie de correction exhaustive (patching) est cohérente et réduit significativement l'exposition au risque.
Vulnérabilités denses (Dense) : Si le stock de vulnérabilités est inépuisable, corriger une vulnérabilité spécifique devient « essentiellement sans importance » pour la sécurité globale, car de nouvelles apparaîtront indéfiniment.

Les auteurs soutiennent que la réponse à cette question détermine la viabilité des stratégies de sécurité actuelles et la nature du risque cybernétique.

2. Méthodologie

Pour résoudre ce débat de manière constructive (et non seulement théorique), les auteurs utilisent une approche combinant la théorie des ensembles, la théorie de la calculabilité et l'analyse formelle :

Construction d'un artefact concret (« Vulnerability Factory ») : Ils ont développé un programme C autonome de 622 lignes capable de générer dynamiquement des modules de code contenant des vulnérabilités.
Preuve par construction : Au lieu de simplement arguer de la complexité, ils exhibent un programme qui produit mathématiquement un ensemble infini de vulnérabilités distinctes.
Modélisation formelle :
- Utilisation de la théorie des ensembles élémentaires pour définir la cardinalité de l'ensemble des vulnérabilités.
- Vérification contre les règles de comptage de la CVE (Common Vulnerabilities and Exposures) de l'organisme MITRE.
- Caractérisation du système comme une Machine de Turing, prouvant que la génération de vulnérabilités est une propriété calculable et décidable.
Analyse par modèle (Model Checking) : Simulation du système pour confirmer la génération illimitée de vulnérabilités.

3. Contributions Clés

A. La « Vulnerability Factory » (Usine à Vulnérabilités)

Il s'agit d'un programme C composé de deux parties :

L'ensemble de base ( $B$ ) : 11 fonctions contenant chacune une vulnérabilité classique (ex: débordement de tampon, injection de commande, etc.) correspondant à des classes CWE spécifiques.
Le Générateur ( $G$ ) : À chaque exécution, il lit un compteur persistant $n$ , génère un nouveau fichier source (vuln_module_n.c) contenant 5 vulnérabilités paramétrées par $n$ (tailles de tampons, seuils d'overflow, etc.), le compile en une bibliothèque partagée distincte, et incrémente le compteur.

B. Preuve Formelle de l'Infinité

Les auteurs démontrent que l'ensemble des vulnérabilités générées, noté $\mathcal{V}$ , est dénombrablement infini ( $\aleph_0$ ) et que chaque élément est éligible à une attribution CVE distincte.

Distinctivité : Chaque module généré est une composante logicielle distincte (bibliothèque partagée différente). Selon les règles CVE, des vulnérabilités dans des composants différents, même de même type, reçoivent des identifiants uniques.
Paramétrisation : Les paramètres (tailles de mémoire, seuils) varient avec $n$ , rendant chaque vulnérabilité unique et nécessitant un payload d'exploitation différent.
Robustesse : La preuve résiste à l'invalidation d'un nombre fini de cas ou même à la suppression de certaines classes de vulnérabilités (tant qu'au moins une classe subsiste, l'ensemble reste infini).

C. Concept d'« Abondance des Vulnérabilités »

Les auteurs introduisent une nouvelle métrique inspirée de l'abondance des éléments chimiques :

Définition : La proportion relative de chaque classe de vulnérabilité (CWE) au sein d'un corpus logiciel global.
Dynamique : Cette abondance n'est pas statique ; elle dépend du langage de programmation utilisé (ex: C/C++ favorisent les erreurs de mémoire, Rust/Go les erreurs de logique) et de l'évolution des pratiques de développement.
Analogie : Tout comme la nucléosynthèse stellaire détermine la composition chimique de l'univers, le choix du langage de programmation détermine le « spectre » des vulnérabilités possibles.

D. Distinction Cruciale : Vulnérabilités vs Exploits

L'article souligne une distinction fondamentale :

Vulnérabilités : Potentiellement infinies.
Exploits : Finis et rares.
Données empiriques : Moins de 6 % des CVE publiées sont jamais exploitées dans la nature.
Facteur multiplicateur : Le risque réel dépend de l'interaction entre l'abondance des vulnérabilités et la part de marché du logiciel affecté. Un exploit contre un système dominant (ex: Windows, Linux) a un impact systémique bien supérieur à des milliers d'exploits contre des logiciels de niche.

4. Résultats Principaux

Théorème de l'Infinité : L'ensemble de toutes les vulnérabilités logicielles est infini. Puisqu'un seul programme (la Vulnerability Factory) peut en générer une infinité dénombrable, l'ensemble global l'est aussi.
Impossibilité de complétude : Aucune base de données de vulnérabilités finie ne peut être complète pour un corpus contenant ce type de générateur.
Principe du « Petit Exploit » : Pour saturer la population des machines vulnérables, un attaquant n'a pas besoin d'exploiter l'infinité des vulnérabilités, mais seulement un petit nombre d'exploits ciblant les « monocultures » logicielles dominantes.
Validité des règles CVE : La construction respecte strictement les règles du MITRE, prouvant que l'attribution d'une infinité de CVE est théoriquement possible et conforme aux standards actuels.

5. Signification et Implications

Changement de paradigme : Il faut abandonner l'idée de « vider l'océan » des vulnérabilités par le patching exhaustif. L'objectif doit être de cartographier les courants (l'abondance) et de comprendre la distribution des risques.
Analyse Économique et Prédictive : La mesure de l'abondance des vulnérabilités permet d'orienter les investissements de sécurité vers les classes de vulnérabilités les plus prédominantes (ex: migration vers des langages sûrs en mémoire pour réduire l'abondance des erreurs de mémoire).
Outil de Recherche : La « Vulnerability Factory » est proposée comme un artefact de preuve réutilisable (un « objet test ») pour les futures recherches en théorie des vulnérabilités, servant de contre-exemple concret aux outils de vérification formelle et aux scanners de sécurité.
Gestion du Risque Cyber : Les organisations doivent se concentrer sur la réduction de leur exposition aux monocultures logicielles, car c'est là que la concentration du déploiement amplifie le risque, indépendamment de l'infinité théorique des vulnérabilités.

En conclusion, l'article démontre mathématiquement que la sécurité logicielle ne peut être atteinte par l'élimination totale des failles, mais doit se concentrer sur la gestion de l'abondance des types de vulnérabilités et la réduction de la concentration des déploiements critiques.