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.
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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
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.