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é à être harcelé par des internautes attirant son attention sur la vulnérabilité.

Malheureusement, le cas d’Indutny n’est pas isolé. Ces derniers temps, les développeurs 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 conduire à 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 se transforme en une source de maux de tête pour les développeurs.

Archivage du dépôt GitHub « node-ip »

Plus tôt ce mois-ci, Fedor Indutny, auteur du «nœud-ip' projet archivé le GitHub du projet le référentiel le rendant effectivement en lecture seule et limitant la capacité des personnes à ouvrir de nouveaux problèmes (discussions), des demandes d'extraction ou à soumettre des commentaires sur le projet.

Le projet « node-ip » existe sur le registre npmjs.com en tant que le paquet '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 a exprimé sur les réseaux sociaux son raisonnement derrière l'archivage de « node-ip » :

« Il y a quelque chose qui a [sic] cela m'a dérangé ces derniers mois et m'a amené à archiver le dépôt node-ip sur GitHub, » publié le développeur via son compte Mastodon.

Cela a à voir avec CVE-2023-42282une vulnérabilité révélée dans le projet plus tôt cette année.

« Quelqu'un a déposé un CVE douteux concernant 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 message.

Les développeurs Node.js utilisant d'autres projets ouverts, tels que les packages npm et les dépendances dans leur application, peuvent exécuter le « Audit NPM » commande pour vérifier si l'un de ces projets utilisés par leur application a fait l'objet de vulnérabilités signalées.

Le CVE est dû 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… » (qui représente 127.1…) comme publique.

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 le renvoi de résultats incohérents par les versions affectées de l'utilitaire.

Un impact « douteux » sur la sécurité

Des sources publiques suggèrent que CVE-2023-42282 avait initialement été noté comme un 9,8 ou « critique ».

Bien qu'Indutny avait déjà réparé le problème dans les versions ultérieures de son projet, il a contesté que le bug constituait un réel vulnérabilité et cela aussi d’une gravité élevée.

« Je pense que l'impact du bug sur la sécurité est plutôt douteux », avait écrit le développeur plus tôt, demander à GitHub de révoquer le CVE.

« Bien que je n'aie pas vraiment prévu que le module soit utilisé pour des contrôles liés à 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 [functions] et ensuite utilisé pour vérifier d'où vient la connexion réseau. « 

Contester un CVE n’est pas non plus une tâche simple, car un membre de l'équipe de sécurité de GitHub expliqué. Cela nécessite un responsable du projet pour chasser le Autorités de numérotation CVE (CNA) qui avait initialement délivré le CVE.

Les CNA comprennent traditionnellement le NVD et le MITRE du NIST. Au cours des dernières années, des entreprises technologiques et des 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 Avis GitHub.

Suite à la publication d'Indutny sur les réseaux sociaux, GitHub a réduit la gravité du CVE dans leur base de données et a suggéré au développeur d'activer Rapport de vulnérabilité privé 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 croissante

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 nombreuses CVE sont déposées de bonne foi par des chercheurs responsables et représentent des vulnérabilités de sécurité crédibles, une tendance récemment croissante implique des passionnés de sécurité débutants et des chasseurs de primes de bugs qui « collectent » ostensiblement des CVE pour enrichir leur CV plutôt que de signaler des bogues de sécurité qui constituent le monde réel. , impact pratique de l’exploitation.

Par conséquent, les développeurs et les responsables du projet ont reculé.

En septembre 2023, Daniel Stenberg, créateur du célèbre projet de logiciel « curl », a réprimandé le «problème de boucle fictive CVE-2020-19909, » un bug de déni de service signalé contre le projet.

Initialement noté 9,8 ou critique en termes de gravité. L'histoire de NVDle CVE, désormais contesté, a vu sa note abaissée à 3,3 « faible » après des discussions qui ont suivi 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 en critiquant l'entrée du CVE.

« Je ne suis pas fan des exercices de réflexion philosophique autour des vulnérabilités. »

« Ils détournent l'attention des choses réelles et je les trouve plutôt inutiles. Il est facile de tester comment cette faille se manifeste sur de nombreuses plates-formes en utilisant de nombreux compilateurs. »

« Ce n’est un problème de sécurité sur aucun d’entre eux. »

Selon Stenberg, compte tenu des détails techniques de ce « bug stupide », même s’il pouvait entraîner un comportement inattendu, il ne s’agissait pas d’une faille de sécurité susceptible d’être exploitée abusivement.

Encore un autre projet npm, micromatch qui obtient 64 millions de téléchargements hebdomadaires a une gravité « élevée » Refaire des vulnérabilités ont été signalées à son encontre et ses créateurs ont été poursuivis par des membres de la communauté qui s'enquéraient des problèmes.

« Pouvez-vous indiquer au moins une bibliothèque qui implémente Micromatch ou Braces et qui est sensible à la vulnérabilité afin que nous puissions voir comment il s'agit réellement d'une vulnérabilité dans le monde réel, et pas seulement théorique ? » demandé Jon Schlinkert, réagissant à 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 de la part du rapporteur de vulnérabilité a répondu avec:

« Je reçois ces problèmes tout le temps pour des choses qui ne peuvent même pas constituer une vulnérabilité à moins que vous ne 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 est simplement utilisé par votre application. »

« J'ai demandé des exemples de la manière dont une bibliothèque du monde réel rencontrerait ces « vulnérabilités » et vous n'avez jamais répondu avec 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'est avéré qu'il s'agissait d'un rapport de nuisance (un peu comme CVE-2024-4067) pour lequel les développeurs avaient déjà été poursuivis.

Outre le fait que cela soit simplement une nuisance pour les responsables de projets, le fait d'obtenir des CVE émis pour des rapports de vulnérabilité non vérifiés s'apparente à 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 l'audit npm) 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 builds.

« Jackson a eu ce problème il y a quelques mois, où quelqu'un a signalé un CVE critique contre le projet et a détruit des constructions partout sur la planète », a déclaré un commentateur écrit en 2023, en réaction au faux CVE curl.

Plutôt que de constituer un problème de sécurité avec le projet, comme d'autres développeurs ont déclaré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 des vulnérabilités théoriques peut épuiser les développeurs open source, dont beaucoup sont des bénévoles, à force de trier le bruit.

D’un autre côté, serait-il éthique que les praticiens de la sécurité, y compris les novices, s’asseyent 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 mainteneur actif. Par exemple, les projets logiciels abandonnés qui n'ont pas été modifiés depuis des années contiennent des vulnérabilités qui, même si elles sont révélé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, notamment les CNA et les plateformes de bug bounty, sont laissés dans l’incertitude.

Lorsqu’elles reçoivent un rapport de vulnérabilité d’un chercheur, ces organisations ne sont pas toujours en mesure d’examiner suffisamment chacun de ces rapports de manière indépendante. Sans entendre les responsables du projet (maintenant absents), ils pourraient ê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.

Tant que la communauté des chercheurs, des développeurs et des fournisseurs en matière de sécurité ne se réunira pas pour identifier une solution efficace, les développeurs seront forcément frustrés par les faux rapports qui les épuiseront et par le fait que le système CVE sera inondé de « vulnérabilités » exagérées qui peuvent sembler crédibles sur le papier mais qui sont en réalité sans objet.