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.
Envoyé par Fedor Indutny
Je ne suis pas en désaccord avec l'existence du problème décrit dans ce rapport, mais je pense que l'impact du bogue sur la sécurité est plutôt douteux. Bien que je n'ai pas vraiment l'intention d'utiliser le module pour des vérifications liées à la sécurité, je suis très curieux de savoir comment une entrée non fiable pourrait être passée dans ip.isPrivate ou ip.isPublic et ensuite utilisée pour vérifier d'où vient la connexion au réseau.
Après tout, si vous voulez empêcher l'accès au service sur la base de l'adresse IP, vous obtiendrez l'adresse IP du système d'exploitation et elle sera correctement formatée 100 % du temps. Compte tenu de ce qui précède, j'aimerais contester ce rapport et voir si nous pouvons effectivement supprimer l'avis de mon module.
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 ? Que pensez-vous de la chasse aux bogues polémique dont font l'objet les projets open source ? Quels pourraient être les impacts de la multiplication des rapports CVE douteux, voire faux, sur les projets open source ? Quels pourraient être les impacts de ces rapports sur la communauté open source ? Le besoin d'enrichir son CV justifie-il des comportements préjudiciables aux mainteneurs de projets de open source ?Voir aussi
Les cybercriminels exploitent rapidement une vulnérabilité d'injection d'arguments dans PHP-CGI, avec un niveau de gravité de 9.8, permettant l'exécution de code à distance 80 % des failles de sécurité sont dues à des erreurs de configuration et les entreprises ont généralement environ 15 000 failles que des attaquants compétents pourraient exploiter Augmentation de 49 % du nombre de victimes signalées par les sites de fuite de ransomware en 2023, en raison de l'impact massif des attaques qui exploitent des vulnérabilités de type "zero-day" 
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.