IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Un développeur archive le dépôt GitHub de son projet après une avalanche de rapports "douteux" sur une faille


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Juin 2023
    Messages
    711
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2023
    Messages : 711
    Points : 12 884
    Points
    12 884
    Par défaut 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).

    Nom : Capture d'écran 2024-07-03 210047.png
Affichages : 96491
Taille : 69,7 Ko

    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.

    Nom : Capture d'écran 2024-07-03 204418.png
Affichages : 22318
Taille : 133,2 Ko

    « 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.

    Citation 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.
    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.

    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.

    Nom : dev-mast-thread.jpg
Affichages : 22279
Taille : 72,7 Ko

    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"

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    Fonctionnaire
    Inscrit en
    Février 2017
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Fonctionnaire

    Informations forums :
    Inscription : Février 2017
    Messages : 4
    Points : 25
    Points
    25
    Par défaut
    Bonjour,

    Sauf erreur de ma part, on se doit de prévenir en amont le propriétaire/développeur avant de poster la CVE.
    Cela permet, par exemple, d'attendre que la vulnérabilité soit 'patchée' avant de la rendre publique.

    Entre les fausses CVE et les projets libres auxquels ont intègres des portes dérobées à l'insu des développeur, il devient, je trouve, de plus en plus compliqué de s'assurer de la sécurité de son infrastructure.

  3. #3
    Membre averti Avatar de fmartini
    Homme Profil pro
    Ingénieur en Cybersécurité
    Inscrit en
    Mai 2013
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur en Cybersécurité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2013
    Messages : 70
    Points : 326
    Points
    326
    Par défaut
    Citation Envoyé par Thaumasson Voir le message
    Bonjour,

    Sauf erreur de ma part, on se doit de prévenir en amont le propriétaire/développeur avant de poster la CVE.
    Cela permet, par exemple, d'attendre que la vulnérabilité soit 'patchée' avant de la rendre publique.

    Entre les fausses CVE et les projets libres auxquels ont intègres des portes dérobées à l'insu des développeur, il devient, je trouve, de plus en plus compliqué de s'assurer de la sécurité de son infrastructure.
    Malheureusement, les accords de licence OpenSource (comme GPL, MIT, Apache) ne contiennent généralement pas de clauses spécifiques sur la divulgation des vulnérabilités.. Bien que ça soit une bonne pratique éthique, pour certains, la notoriété et l'argent passent avant tout

  4. #4
    Membre habitué Avatar de vivid
    Profil pro
    Inscrit en
    Février 2006
    Messages
    174
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 174
    Points : 135
    Points
    135
    Par défaut
    Citation Envoyé par Thaumasson Voir le message
    Bonjour,

    Sauf erreur de ma part, on se doit de prévenir en amont le propriétaire/développeur avant de poster la CVE.
    Cela permet, par exemple, d'attendre que la vulnérabilité soit 'patchée' avant de la rendre publique.

    Entre les fausses CVE et les projets libres auxquels ont intègres des portes dérobées à l'insu des développeur, il devient, je trouve, de plus en plus compliqué de s'assurer de la sécurité de son infrastructure.
    Il y a un truc qui s'appelle FTP, et tout le monde en a un. La sécurité se paye au manque de confort ou praticité

  5. #5
    Membre averti Avatar de fmartini
    Homme Profil pro
    Ingénieur en Cybersécurité
    Inscrit en
    Mai 2013
    Messages
    70
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur en Cybersécurité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2013
    Messages : 70
    Points : 326
    Points
    326
    Par défaut
    Citation Envoyé par vivid Voir le message
    Il y a un truc qui s'appelle FTP, et tout le monde en a un. La sécurité se paye au manque de confort ou praticité
    Alors je n'ai peut-être pas compris le sens de votre message, et/ou alors je suis totalement à l'Ouest. Mais je ne vois pas vraiment en quoi un FTP viendrait en aide à un projet Open source... 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.

Discussions similaires

  1. Réponses: 83
    Dernier message: 08/12/2022, 13h20
  2. Réponses: 6
    Dernier message: 22/06/2018, 16h36
  3. GitHub célèbre son 5e anniversaire
    Par Hinault Romaric dans le forum Actualités
    Réponses: 4
    Dernier message: 07/05/2013, 17h27
  4. [Débutant] Importer une dll dans son projet + utliser une classe
    Par benny-blanco dans le forum C#
    Réponses: 2
    Dernier message: 08/05/2012, 15h52
  5. Négocier son départ après une démission
    Par gildouille dans le forum Démission
    Réponses: 18
    Dernier message: 10/08/2007, 10h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo