Le projet open source populaire, ‘ip’, a récemment vu son référentiel GitHub archivé ou rendu « en lecture seule » par son développeur.
Fedor Indutny, en raison d’un rapport CVE déposé contre son projet, a commencé à se faire traquer par des internautes portant la vulnérabilité à son attention.
Malheureusement, le cas d’Indutny n’est pas isolé. Ces derniers temps, les développeurs open source ont été confrontés à une légère augmentation de la réception 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é, qui se transforment toutes en une source de maux de tête pour les développeurs.
dépôt GitHub’ node-ip ‘ archivé
Plus tôt ce mois-ci, Fedor Indutny, l’auteur du projet « node-ip », a archivé le référentiel GitHub du projet, le rendant ainsi en lecture seule et limitant la capacité des utilisateurs à ouvrir de nouveaux problèmes (discussions), demandes d’extraction ou soumettre des commentaires au projet.
Le projet ‘node-ip’ existe sur le npmjs.com registry en tant que package » ip » qui enregistre 17 millions de téléchargements par semaine, ce qui en fait l’un des utilitaires d’analyse d’adresses IP les plus populaires utilisés par les développeurs JavaScript.
Le mardi 25 juin, Indutny s’est rendu sur les réseaux sociaux pour exprimer son raisonnement derrière l’archivage de « node-ip »:
« Il y a quelque chose qui me dérange depuis quelques mois, et qui m’a amené à archiver le dépôt node-ip sur GitHub », a posté le développeur via son compte Mastodon.
Cela a à voir avec CVE-2023-42282, une vulnérabilité révélée dans le projet plus tôt cette année.
« Quelqu’un a déposé une CVE douteuse à propos de mon package npm, puis j’ai commencé à recevoir des messages de toutes les personnes recevant des avertissements de » npm audit » », déclare le développeur dans le même article.
Nœud.les développeurs js utilisant d’autres projets ouverts, tels que les packages npm et les dépendances dans leur application, peuvent exécuter la commande « audit npm » pour vérifier si l’un de ces projets utilisés par leur application a fait l’objet de vulnérabilités signalées.
La CVE 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 hexadécimal. Cela amènerait l’utilitaire ‘node-ip’ à traiter une adresse IP privée (au format hexadécimal) telle que » 0x7F. 1… »(ce qui représente 127.1…) en tant que public.
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 affectées de l’utilitaire.
Impact « douteux » sur la sécurité
Des sources publiques suggèrent que CVE-2023-42282 avait initialement reçu la note de 9,8 ou « critique ». »
Bien qu’Indutny ait effectivement résolu le problème dans les versions ultérieures de son projet, il a contesté que le bogue constituait une vulnérabilité réelle et cela aussi d’une gravité élevée.
« Je pense que l’impact du bogue sur la sécurité est plutôt douteux », a écrit le développeur plus tôt, demandant à GitHub de révoquer le CVE.
« Bien que je n’aie 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 finir par être transmise à ip.isPrivate ou ip.isPublic [fonctions] puis utilisé pour vérifier d’où vient la connexion réseau. »
Contester une CVE n’est pas non plus une tâche simple, comme l’a expliqué un membre de l’équipe de sécurité de GitHub. Cela nécessite qu’un responsable de projet poursuive les autorités de numérotation CVE (CNA) qui avaient initialement émis la CVE.
Les CNA comprenaient classiquement le NVD et la MITRE du NIST. Au cours des dernières années, les entreprises technologiques et les fournisseurs de sécurité ont rejoint la liste et sont également en mesure d’émettre des CVE à volonté.
Ces CVE, ainsi que la description de la vulnérabilité et l’indice de gravité signalé, sont ensuite syndiqués et republiés par d’autres bases de données de sécurité, telles que les avis GitHub.
Suite à la publication d’Indutny sur les réseaux sociaux, GitHub a réduit la gravité de la CVE dans sa base de données et a suggéré au développeur d’activer les rapports de vulnérabilité privés pour mieux gérer les rapports entrants et réduire le bruit.
Au moment de la rédaction de cet article, la gravité de la vulnérabilité sur NVD reste « critique ». »
Une nuisance grandissante
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 cataloguer 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 vulnérabilités de sécurité crédibles, une tendance croissante récente implique que les amateurs de sécurité débutants et les chasseurs de primes de bogues « collectent » ostensiblement des CVE pour enrichir leur CV plutôt que de signaler des bogues de sécurité qui constituent monde réel, impact pratique de l’exploitation.
Par conséquent, les développeurs et les responsables du projet ont repoussé.
En septembre 2023, Daniel Stenberg, créateur du célèbre projet logiciel ‘curl’ a réprimandé le « faux problème de boucle CVE-2020-19909 », un bogue de déni de service signalé contre le projet.
Initialement noté 9,8 ou de gravité critique selon l’historique de NVD, le CVE désormais contesté a vu sa note tomber à un « faible » 3,3 après que des discussions se sont ensuivies remettant en question l’impact tangible de la faille sur la sécurité.
« Ce n’était pas un cas unique et ce n’était pas la première fois que cela se produisait. Cela dure depuis des années », a écrit Stenberg critiquant l’entrée CVE.
« Je ne suis pas un fan des exercices de pensée philosophique autour des vulnérabilités. »
« Ce sont des distractions des vraies questions et je les trouve plutôt inutiles. Il est facile de tester comment cette faille se manifeste sur de nombreuses plates-formes à l’aide de nombreux compilateurs. »
« Ce n’est un problème de sécurité sur aucun d’entre eux. »
Selon Stenberg, les détails techniques du » bogue idiot » signifiaient qu’il pouvait entraîner un comportement inattendu, et non une faille de sécurité qui pourrait être abusée.
Encore un autre projet npm, micromatch, qui reçoit 64 millions de téléchargements hebdomadaires, a fait l’objet de vulnérabilités ReDoS de gravité « élevée » signalées à son encontre, ses créateurs étant poursuivis par des membres de la communauté se renseignant sur les problèmes.
« Pouvez-vous indiquer au moins une bibliothèque qui implémente micromatch ou des accolades qui est sensible à la vulnérabilité afin que nous puissions voir en quoi il s’agit réellement d’une vulnérabilité dans le monde réel, et pas seulement théorique? »a demandé Jon Schlinkert, réagissant au CVE-2024-4067 déposé pour son projet, micromatch.
Dans le même fil, le développeur, apparemment après avoir échoué à recevoir une preuve de concept satisfaisante exploiter du journaliste de vulnérabilité a répondu avec:
« J’ai tout le temps ces problèmes pour des choses qui ne peuvent même pas être une vulnérabilité à moins que vous ne vous le fassiez à vous-même. Comme les expressions régulières dans les bibliothèques de bas niveau qui ne seront jamais accessibles à un navigateur, à moins que vous ne laissiez les utilisateurs soumettre des expressions régulières dans un formulaire Web qui ne sont utilisées que par votre application. »
« J’ai demandé des exemples de la façon dont une bibliothèque du monde réel rencontrerait ces « vulnérabilités » et vous ne répondez jamais par un exemple. »
Moi aussi, j’ai récemment envoyé un message aux développeurs de micromatch après qu’un tiers nous a informés d’un « risque » potentiel posé par le projet, car cela semblait être la chose responsable à faire à l’époque.
Malheureusement, au lieu de représenter une vulnérabilité exploitable, il s’agissait d’un rapport de nuisance (un peu comme CVE-2024-4067) pour lequel les développeurs avaient déjà été poursuivis.
En plus d’être une simple gêne pour les responsables de projet, le fait d’obtenir des CVE pour des rapports de vulnérabilité non vérifiés revient à attiser un déni de service (DoS) contre un projet, ses créateurs et sa base de consommateurs plus large, et pour de bonnes raisons.
Les solutions de sécurité des développeurs (telles que npm audit) conçues pour empêcher les composants vulnérables d’atteindre vos applications peuvent déclencher des alertes si des vulnérabilités connues sont détectées et, en fonction de vos paramètres, interrompre vos versions.
« Jackson a eu ce problème il y a quelques mois, où quelqu’un a signalé un CVE critique contre le projet et a cassé des constructions partout sur la planète », avait écrit un commentateur en 2023, réagissant au faux curl CVE.
Plutôt que d’être un problème de sécurité avec le projet, comme l’ont déclaré d’autres développeurs, le problème représentait la nature inhérente des structures de données Java récursives.
Où est l’équilibre?
Des incidents récurrents comme ceux-ci soulèvent la question suivante: comment trouver un équilibre?
Signaler sans relâche les vulnérabilités théoriques peut laisser les développeurs open source, dont beaucoup sont des bénévoles, épuisés par le bruit de triage.
D’un autre côté, serait—il éthique que les praticiens de la sécurité, y compris les novices, s’assoient sur ce qu’ils pensaient ê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 mainteneur actif. Les projets logiciels abandonnés qui n’ont pas été touchés depuis des années contiennent des vulnérabilités qui, même lorsqu’elles sont divulguées, ne seront jamais corrigées et il n’existe aucun moyen de contacter leur responsable d’origine.
Dans de tels cas, les intermédiaires, y compris les CNA et les plateformes de primes aux bogues, sont laissés dans les limbes.
Lorsqu’elles reçoivent un rapport de vulnérabilité d’un chercheur, ces organisations peuvent ne pas toujours être en mesure d’examiner suffisamment chaque rapport de ce type de manière indépendante. Sans entendre les responsables du projet (maintenant absents), ils peuvent être obligés d’attribuer et de publier des CVE une fois la fenêtre de « divulgation responsable » écoulée.
Il n’existe pas encore de réponse simple à ces problèmes.
Jusqu’à ce que les communautés de recherche en sécurité, de développeurs et de fournisseurs se réunissent pour identifier une solution efficace, les développeurs seront forcément frustrés par les faux rapports qui les épuisent et le système CVE sera inondé de « vulnérabilités » exagérées qui peuvent sembler crédibles sur le papier mais sont effectivement sans objet.