Un développeur archive le dépôt GitHub de son projet après une avalanche de rapports "douteux" sur une faille
Un développeur contraint d'archiver le dépôt GitHub de son projet après une avalanche de rapports "douteux" sur une vulnérabilité
il dénonce une tendance qui peut nuire à la réputation des projets open source
Les rapports sur les vulnérabilités des logiciels open source échappent-ils à tout contrôle ? Le développeur du projet open source "node-ip" a alerté sur le fait que certains chercheurs en sécurité exagèrent outrageusement les rapports sur les vulnérabilités afin de se forger la réputation d'avoir trouvé une vulnérabilité critique. Il a été contraint d'archiver temporairement le dépôt GitHub de son projet après des rapports exagérés sur une vulnérabilité critique avec un score de 9,8 qui affecterait son utilitaire. Mais il ne s'agissait que d'une vulnérabilité de gravité faible. Les critiques suggèrent que cette tendance pourrait détruire la réputation des projets open source.
Fedor Indutny est le développeur du projet node-ip, un paquetage de gestion d'adresses IP pour Node.js. En vérifiant les informations sur le paquetage de node-ip, l'on peut voir qu'il s'agit d'un projet populaire qui est téléchargé plus de 17 millions de fois par semaine. Le 9 février 2024, une vulnérabilité dans node-ip a été signalée. La description indique qu'il s'agit d'une vulnérabilité dans laquelle "les adresses IP privées peuvent être traitées comme des adresses IP publiques". Et l'exploitation de cette vulnérabilité pourrait permettre une attaque de falsification de requêtes côté serveur (Server-side Request Forgery - SSRF).
La vulnérabilité est liée au fait que l'utilitaire n'identifie pas correctement les adresses IP privées qui lui sont fournies dans un format non standard, tel que l'hexadécimal. Ainsi, l'utilitaire node-ip traiterait une adresse IP privée (au format hexadécimal) telle que "0x7F.1..." (qui représente 127.1...) comme une adresse publique. Et si une application s'appuie uniquement sur node-ip pour vérifier si une adresse IP fournie est publique, des entrées non standard peuvent entraîner des résultats incohérents renvoyés par les versions concernées de l'utilitaire. Indutny considère cette vulnérabilité comme étant mineure et non critique.
Elle a été enregistrée comme une vulnérabilité "critique" avec un score élevé de 9,8 dans la National Vulunerability Database (NVD), une base de données de vulnérabilités gérée par le National Institute of Standards and Technology (NIST). Le CVE est CVE-2023-42282. Après qu'elle a été signalée dans la NVD, la vulnérabilité a été répertoriée sur la page de résumé des informations sur les vulnérabilités de GitHub appelée GitHub Advisory Database (base de données d'avis de GitHub). En outre, Indutny a annoncé le 19 février 2024 avoir corrigé la vulnérabilité et s'attendait à ce que les rapports sur celle-ci cessent d'affluer.
Mais les choses se sont empirées. Même après que la vulnérabilité a été corrigée, les utilisateurs qui ont exécuté l'outil de signalement des vulnérabilités npm "npm-audit" ont continué à recevoir un grand nombre de rapports indiquant que node-ip est vulnérable. Pour cette raison, Indutny a archivé le dépôt GitHub de node-ip. Indutny s'est ensuite rendu sur les réseaux sociaux le mardi 25 juin pour expliquer les raisons qui l'ont poussé à archiver le référentiel. « Il y a quelque chose qui m'a dérangé ces derniers mois, et qui m'a poussé à archiver le dépôt node-ip sur GitHub », a déclaré le développeur via son compte Mastodon.
« Quelqu'un a déposé un CVE douteux à propos de mon paquet npm, et ensuite j'ai commencé à recevoir des messages de toutes les personnes qui reçoivent des avertissements de "npm audit" », a-t-il ajouté. Les développeurs Node.js qui utilisent d'autres projets ouverts, tels que les paquetages et les dépendances npm dans leur application, peuvent lancer la commande "npm audit" pour vérifier si l'un de ces projets utilisés par leur application a fait l'objet d'un rapport sur les vulnérabilités. Indutny reconnaît l'existence de la vulnérabilité CVE-2023-42282, mais s'est plaint du fait que sa gravité a été exagérée sans raison.
Selon les experts, contester un rapport CVE n'est pas une tâche aisée, mais Indutny semble avoir partiellement obtenu gain de cause. À la suite de ses messages sur les médias sociaux, GitHub a abaissé la gravité de la vulnérabilité dans sa base de données et a suggéré à Indutny d'activer le signalement privé des vulnérabilités afin de mieux gérer les rapports entrants et de réduire le bruit. En revanche, la gravité de la vulnérabilité dans la base de données NVD reste "critique". Pour contester ce score, Indutny doit se retrouver les autorités de numérotation des CVE qui ont initialement rédigé le rapport sujet à polémiques.Envoyé par Fedor Indutny
Malheureusement, le cas d'Indutny n'est pas isolé. Ces derniers temps, les développeurs de logiciels open source ont été confrontés à une augmentation du nombre de rapports CVE discutables ou, dans certains cas, carrément faux, déposés pour leurs projets sans confirmation. Cela peut entraîner une panique injustifiée parmi les utilisateurs de ces projets et des alertes générées par les scanners de sécurité, ce qui inquiète les développeurs. « Le niveau de gravité est une connerie depuis quelques années. C'est comme si chaque CVE recevait 9.x, même si pour l'exploiter il faut utiliser de la magie », note un développeur.
Certains critiques remettent en cause le fonctionnement du système CVE. « Donc les personnes qui développent des produits éventuellement concurrents peuvent maintenant soulever des CVE bidons contre l'équivalent FOSS pour le forcer à mettre la clé sous la porte ? Ce système a certainement besoin d'être réformé », a écrit un critique. Le système CVE, conçu à l'origine pour aider les chercheurs en sécurité à signaler de manière éthique les vulnérabilités d'un projet et à les répertorier après une divulgation responsable, a récemment attiré un segment de membres de la communauté déposant des rapports non vérifiés.
Alors que de nombreux CVE sont déposés de bonne foi par des chercheurs responsables et représentent des failles de sécurité crédibles, une tendance qui s'est récemment développée concerne des passionnés de sécurité débutants et des chasseurs de bogues qui collectent ostensiblement des CVE pour enrichir leur CV au lieu de signaler des bogues de sécurité dont l'exploitation aurait des conséquences pratiques dans le monde réel. De nombreux projets open source populaires, dont cURL et micromatch, ont été victime de ces signalements abusifs au cours des deux dernières années. Ils dénoncent une tendance dangereuse.
Les incidents récurrents de ce type soulèvent la question suivante : comment trouver un équilibre ? Le signalement incessant de vulnérabilités critiques théoriques peut épuiser les développeurs de logiciels open source, qui sont souvent des bénévoles, à force de trier le bruit. D'un autre côté, serait-il conforme à l'éthique que les praticiens de la sécurité, y compris les novices, s'assoient sur ce qu'ils pensent être une faille de sécurité, afin de ne pas gêner les responsables du projet ?
Un troisième problème se pose pour les projets sans un responsable actif. Les projets de logiciels abandonnés qui n'ont pas été touchés depuis des années contiennent des vulnérabilités qui, même si elles sont divulguées, ne seront jamais corrigées et il n'existe aucun moyen de contacter leur mainteneur d'origine. Dans de tels cas, les intermédiaires, y compris les autorités de numérotation CVE et les plateformes de recherche de failles, sont laissés dans l'incertitude.
Après la décision de GitHub d'abaisser le score de gravité de la vulnérabilité CVE-2023-42282, Indutny a désarchivé le projet node-ip. L'on ignore toutefois si le développeur a été en mesure de contacter les autorités de numérotation des CVE qui ont initialement rédigé le rapport polémique.
Sources : billet de blogue, CVE-2023-42282, node-ip (1, 2)
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Répondre avec citation
tout en sachant qu'un FTP est par défaut vulnérable d'un point de vue chiffrement, authentification, IAM et naturellement, du côté du patch management.
Partager