Divulgation des vulnérabilités : qu’est-ce qui vient en premier, la faille de sécurité dans PHP ou le CVE ?

Pour les chercheurs en sécurité, plusieurs obstacles se dressent avant même qu’une vulnérabilité potentielle soit largement reconnue. Le premier consiste à convaincre les responsables du projet qu’il existe bien un problème, même avec un exemple fonctionnel.

Il est parfois difficile de distinguer un chemin vulnérable d’un bug plutôt que d’une vulnérabilité de sécurité. L’inverse est également possible : une vulnérabilité signalée peut être reclassée comme un bug, même si elle a été utilisée comme vecteur d’attaque.

Un bon exemple est la divulgation d’une vulnérabilité que DeveloperSteve a suivie dans le langage PHP lui-même, concernant un type de vulnérabilité Use After Free identifié dans la fonction `concat()`. Elle a été démontrée lors d’un événement capture the flag. L’équipe a signalé le problème de sécurité, mais le signalement a été requalifié en bug plusieurs publications plus tard, malgré l’exploitation de la vulnérabilité.

J’ai récemment suivi le processus CVE pour l’incident de la bibliothèque dompdf, ce qui a prolongé de 7 mois le calendrier de l’incident. Cette expérience renforce mon appréciation du travail nécessaire pour maîtriser les subtilités de la publication d’un CVE.

Il est important de noter que de nombreux projets open source comme celui-ci sont gérés et enrichis par des personnes passionnées. Beaucoup travaillent aussi à temps plein et subissent les mêmes pressions que nous au quotidien, tout en gérant des projets de grande envergure.

Examinons le calendrier de l’incident.

Comprendre le calendrier du signalement de l’incident dompdf

Dans le cadre de la divulgation publique de Positive Security en mars 2022, l’équipe a également publié le calendrier des événements qui ont précédé la divulgation.

Le premier signalement aux responsables du projet a eu lieu en octobre 2021, via le processus de la page de signalement des problèmes de sécurité du projet. Après plusieurs mois sans réponse, l’équipe de Positive Security a tenté de faire remonter le problème en le signalant comme un bug dans le dépôt.

Cette démarche a finalement abouti à la publication d’une version corrigée après la divulgation publique de la vulnérabilité. Dans le cadre de cet incident, DeveloperSteve a également pu exploiter le chemin vulnérable pour créer les conditions nécessaires à l’ouverture d’un shell inversé. 

Cette démonstration figure dans l’application Snyk-Labs PHP-Goof, qui intègre la vulnérabilité initiale à laquelle DeveloperSteve a ajouté des vulnérabilités de sécurité liées à PHP.

En s’appuyant sur les recherches précédentes et les exemples de code de preuve de concept pour le shell inversé, DeveloperSteve a obtenu un CVE pour l’incident 7 mois après le signalement initial. 

Comprendre le processus CVE 

Après avoir récemment suivi le processus CVE, nous comprenons et apprécions davantage le travail des chercheurs en sécurité qui signalent des vulnérabilités. 

DeveloperSteve a soumis une demande de CVE à Mitre, accompagnée de l’ensemble des recherches initiales. Elle est actuellement en attente d’une analyse plus approfondie. Cette vulnérabilité a également été ajoutée à titre d’exemple à l’application de démonstration PHP-Goof.

Dans un exemple récent, un chercheur a signalé en janvier une vulnérabilité de type Use After Free. Elle a été répertoriée sur les pages de vulnérabilités de Snyk et identifiée sous le numéro CVE-2021-21708.

Demander un CVE

Au départ, la procédure semblait assez simple : remplir un formulaire en ligne et attendre la validation des résultats par quelqu’un. En consultant la page de signalement et de demande de CVE.org, DeveloperSteve a découvert qu’il fallait suivre plusieurs étapes avant de pouvoir soumettre une demande. 

La première étape consiste à identifier l’organisation partenaire CVE autorisée à réserver et à publier des CVE associés à la vulnérabilité signalée. Ces organisations sont appelées autorités de numérotation CVE, ou CNA. 

Une organisation désignée comme CNA peut évaluer les vulnérabilités de sécurité, puis réserver et publier des identifiants CVE pour les vulnérabilités signalées.

Par exemple, en 2021, Snyk a pris en charge le programme de divulgation des vulnérabilités de l’écosystème Node.js. Snyk est donc une CNA et publie régulièrement des rapports de sécurité CVE pour de nombreux écosystèmes, comme npm.

Remarque : Snyk met à votre disposition un formulaire de divulgation des vulnérabilités simple à utiliser pour signaler des vulnérabilités de sécurité.

En conclusion : le signalement des CVE

Il est parfois difficile de déterminer si un chemin vulnérable signalé relève d’un bug ou d’une vulnérabilité. De plus, il arrive qu’un bug signalé crée un chemin vulnérable et constitue en réalité une menace pour la sécurité. 

Après la découverte initiale d’un bug ou d’un problème de sécurité par la communauté, un chercheur en sécurité ou un contributeur, vient la phase d’investigation, au cours de laquelle le problème signalé est étudié plus en détail. Bien souvent, un acteur malveillant exploite des bugs comme vecteurs d’attaque pour introduire des comportements indésirables dans une application et/ou une infrastructure. 

Chez Snyk, l’équipe de sécurité s’attache à détecter les vulnérabilités de sécurité dès leur apparition sous forme de signalements de bugs, avant même qu’elles ne deviennent des CVE officiels. Cet engagement permet à Snyk de protéger et d’informer ses utilisateurs le plus tôt possible.