Identifier et catégoriser automatiquement les bugs informatiques menaçant la sécurité

Recherche Article publié le 10 juillet 2025

Les techniques automatisées de découverte de bugs informatiques ont fait de grands progrès, au point d’en détecter des milliers. Malheureusement, il demeure impossible de tous les corriger, faute de moyens humains, ce qui apporte un nouveau défi : identifier et prioriser la résolution des vulnérabilités les plus dommageables à la sécurité informatique. Des scientifiques du Laboratoire d'intégration de systèmes et de technologies (List – Univ. Paris-Saclay/CEA) proposent des méthodes automatiques basées sur les approches formelles pour catégoriser la criticité d’un bug.

Alors qu’ordinateurs, programmes et logiciels informatiques sont aujourd’hui monnaie courante, la nécessité de les protéger de potentiels actes malveillants n’a jamais été aussi prégnante. Contourner ces attaques est au cœur des problématiques de cybersécurité, et une des stratégies repose sur la découverte de bugs informatiques et leurs vulnérabilités, sur lesquels s’appuient les attaquants pour mener leurs actions.

En effet, lorsqu’un programme informatique s’exécute sur un ordinateur, il arrive parfois que l’écriture ou la lecture se fassent plus loin que l’espace prévu en mémoire tampon pour cette activité. Dans le meilleur des cas, ce bug - appelé dépassement de mémoire ou buffer overflow - crée un blocage du programme. Dans le pire, des attaquants l’exploitent pour détourner le programme en écrivant de nouvelles instructions ou lire des éléments devant rester secrets. « Cette catégorie de bug est assez prégnante dans des langages de programmation comme C et sont parmi les vulnérabilités les plus sévères », analyse Sébastien Bardin, chercheur au Laboratoire d'intégration de systèmes et de technologies (List – Univ. Paris-Saclay/CEA), qui travaille sur le sujet. Il est donc essentiel d’identifier ces vulnérabilités - et les autres - et de les corriger avant qu’un pirate en profite.

Heureusement, depuis une dizaine d’années, les techniques automatisées de découverte de bugs dans les programmes ont fait d’énormes progrès. C’est le cas des techniques de test automatisé intensif – qui génèrent beaucoup de tests afin d’essayer de trouver des bugs -, notamment utilisées chez des acteurs d’envergure comme Microsoft ou Google.
 

Identifier un bug dangereux

Ces avancées comportent toutefois un revers : elles identifient trop de vulnérabilités dans les programmes. « Des milliers de bugs toujours ouverts ont été trouvés dans le noyau Linux ou dans Firefox, par exemple. Sauf que, sur 1 000 bugs ouverts, on ne peut humainement en corriger qu’une petite partie. La question se pose de trouver lesquels corriger en priorité », expose Sébastien Bardin.

Quelques techniques existent déjà pour cela, comme des scores CVSS (pour Common Vulnerability Scoring System) qui attribuent un score aux différents bugs. Mais les scores CVSS se basent sur des analyses manuelles et des catégories de vulnérabilités trop grossières. Par exemple, tous les dépassements de mémoire tampon sont considérés comme des vulnérabilités importantes. « Ce n’est pas satisfaisant, car pas suffisamment fin - les vulnérabilités catégorisées comme critiques sont encore trop nombreuses - et surtout cela demande toujours une intervention humaine, qui est la ressource limitante. Nous voudrions être capables d’intervenir de manière automatique, avant qu’un expert humain n’ait analysé le problème. »

Les travaux de Sébastien Bardin et ses collègues s’inscrivent dans ce contexte : catégoriser le danger que présente une vulnérabilité face à un attaquant. « Nous sommes parmi les premiers à nous poser la question de l’importance des bugs et non seulement de leur présence. C’est un énorme changement dans la manière de les voir », présente Sébastien Bardin.

Si cela n’avait pas encore été fait, c’est que ce travail n’est pas aisé. En effet, il faut être capable de définir ce qu’est un bug dangereux, de trouver les éléments caractérisant un bug important parmi une quantité d’autres éléments. Or « c’est un problème assez ouvert. Le point le plus important est d’arriver à établir les bonnes définitions pour la criticité, puis d’en automatiser l’analyse. »
 

Deux angles d’attaque pour catégoriser la vulnérabilité

Afin de jauger le danger d’un bug, l’équipe de Sébastien Bardin prend en compte deux notions importantes : la réplicabilité d’une attaque et le contrôle de cette attaque par l’attaquant. Dans le premier cas, on dit d’une attaque qu’elle est plus ou moins « réplicable » selon la capacité du pirate informatique à la mettre en place sans résistance. Sébastien Bardin prend l’exemple d’un lecteur PDF installé sur n’importe quel ordinateur. Si le logiciel gère mal certaines entrées du système, c’est-à-dire certaines données envoyées par un périphérique, « l’attaquant peut vous envoyer un PDF qui possède exactement les bons défauts pour corrompre l’exécution du lecteur PDF et de fil en aiguille, prendre le contrôle de votre système. » Cette attaque est alors réplicable - tous les utilisateurs et utilisatrices du lecteur PDF y sont vulnérables - et déclenchable à volonté.

À l’inverse, d’autres vulnérabilités découlent d’une combinaison de circonstances, par exemple lorsque le lecteur PDF comporte un défaut dans une certaine configuration du système d’exploitation, du matériel ou du réseau. Ici, pour que l’attaque aboutisse, l’attaquant doit avoir de la chance et que le système de la personne visée soit dans la bonne configuration de paramètres. C’est pour cela que l’équipe de Sébastien Bardin a introduit la notion d’accessibilité robuste, qui distingue les bugs dont les entrées ne dépendent pas de circonstances externes à l’attaquant. Pour autant cette catégorisation est presque trop tranchée : il arrive qu’une attaque dépende aussi d’une configuration de paramètres très fréquente, et l’attaquant risque ainsi de souvent réussir son attaque. « Nous avons affiné cette notion pour caractériser si un attaquant peut assez probablement atteindre ses objectifs. »

Le contrôle qu’un bug octroie à un attaquant est l’autre notion sur laquelle Sébastien Bardin et ses collègues se penchent pour mieux évaluer la vulnérabilité d’un bug. « Généralement, plus une vulnérabilité permet à l’attaquant d’écrire des valeurs à certains endroits du système, plus elle lui donne des possibilités pour agir. » Dans le cas du bug de dépassement de mémoire tampon, sa dangerosité n’est pas la même selon que l'attaquant est en capacité d’écrire une valeur ou des milliers. Pour l’analyser, « nous regardons les entrées qui font planter le programme, puis suivons leurs traces d’exécution pour calculer une représentation du contrôle que le bug donne à l’attaquant. »

Une fois les leviers de criticité identifiés et leurs définitions établies, l’équipe de Sébastien Bardin construit des approches basées sur des méthodes formelles pour implémenter des analyses de programmes automatiques, enrichies de la capacité d’évaluer la criticité d’un bug. Ces méthodes formelles ont l’avantage d’offrir des garanties mathématiques à la détection et à la caractérisation de bugs. D’un point de vue mathématique, trouver un bug, c’est trouver une solution à une équation qui découle des chemins d’exécution du programme. Pour évaluer la réplicabilité et le contrôle de l’attaquant, l’équipe introduit des manipulations particulières de l’ensemble des solutions de ces équations.
 

Des progrès importants pour la cybersécurité

« Il y a peut-être d’autres leviers complémentaires aux deux notions précédemment citées pour affiner la mesure de la vulnérabilité. Les identifier fait clairement partie des difficultés scientifiques du travail », continue Sébastien Bardin.

Pour réussir à trouver concrètement ce qui rend un bug critique, les scientifiques dialoguent et collaborent avec des industriels et experts du domaine, comme l’Agence nationale de la sécurité des systèmes d'information (Anssi). « C’est vraiment un processus itératif de recherche. Les industriels nous font part de leurs problématiques et nous nous demandons comment y apporter des solutions. Ensuite, ils nous font un retour sur nos techniques et ce qu’elles apportent à leurs cas concrets. » Une manière de mieux coller à la réalité du terrain.
 

Références :