Connexion
Abonnez-vous

Bibliothèque Node.js vérolée : NPM sort un communiqué, le responsable se justifie

Bibliothèque Node.js vérolée : NPM sort un communiqué, le responsable se justifie

Le 29 novembre 2018 à 09h43

Il y a quelques jours, un développeur révélait l’infection de la bibliothèque event-stream, téléchargée jusqu’à 2,4 millions de fois par semaine, par du code visant un portefeuille de cryptomonnaies, Copay.

Le cheval de Troie (flatmap-stream) était insidieux pour plusieurs raisons. D’une part, event-stream est une dépendance d’autres projets, qu’on installe habituellement avec des dizaines d’autres sans y réfléchir. D’autre part, le code infectieux ne fonctionnait qu’en présence de bibliothèques de Copay sur le serveur.

L’histoire a fait son effet, notamment à cause de la première justification du concepteur d’event-stream, Dominic Tarr, qui a laissé les clés de son projet au pirate après un simple email. Ne l’utilisant plus « depuis des années », il a simplement donné son projet à la première occasion, sans le moindre contrôle.

Rapidement, l’équipe de NPM, le système de distribution officiel des bibliothèques Node.js, a pris la main sur le compte d’event-stream et retiré la version 3.3.6, en cause.

Dans un billet de blog, elle explique avoir été avertie le 26 novembre de l’infection, le pirate ayant pris le contrôle du compte NPM du projet. La version 3.3.6 d’event-stream datait du 9 septembre, passant inaperçu pendant deux mois.

Le ciblage très précis des développeurs de Copay limite les dégâts, selon NPM. « La plupart des développeurs ne seraient pas affectés, même s’ils ont installé le module malveillant par erreur. » Le code tentait de récupérer les informations du compte et la clé privée des comptes disposant de plus de 100 bitcoins ou de plus de 1 000 bitcoins cash. Il a été déployé dans Copay entre les versions 5.0.2 et 5.1.0.

Pour sa part, le développeur Dominic Tarr revient sur la polémique, certains le jugeant irresponsable. Il répète son principal point : ce module était devenu un poids pour lui. « Si ce n’est plus amusant, vous n’obtenez absolument rien à maintenir un paquet populaire », estimant que beaucoup de dépendances sont dans le même état d’abandon.

Tarr estime que partager les droits d’édition et de publication est une pratique commune dans le monde de Node.js, et assure qu’il n’aurait pas accepté s’il s’était douté des intentions du pirate. Pour lui, il faut soit payer les mainteneurs des modules (souvent fatigués, ne tirant rien de modules qu’ils n’utilisent plus eux-mêmes), soit contribuer, tout simplement.

Le 29 novembre 2018 à 09h43

Commentaires (15)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







espritordu a écrit :



Il est mignon…Qu’est ce qui a pu te faire penser avec autant de certitudes que je ne serais pas contributeur et militant du libre et que tu m’apprendrais quelque chose ?







Je sais pas… Le fait que tu t’étonnes de la situation :







espritordu a écrit :



L’info que je retiens d’abord là dedans est qu’un paquet aussi utilisé puisse avoir si peu de contributeurs.







Et que tu disent ça :







espritordu a écrit :



La première mesure à prendre est d’abord avant d’installer (ou mettre en dépendance) un paquet de s’assurer qu’il n’est pas maintenu par un seul gars il y a plusieurs années.







P.S. : Mon premier message était plutôt sur le ton de l’humour… désolé.


votre avatar

Npm, c’est juste un gros bordel qui t’installe des centaines de packages très vite obsolètes pour faire 1+1. Et dire que c’est utilisé partout.

votre avatar

Ce n’est pas la première fois qu’il y a un problème d’ampeur avec Node.



Pour beaucoup c’est à l’intégrateur de la lib de faire son travail d’audit.



Cette news pulvérise totalement l’argument disant qu’un projet Open Source est sûr parce que les gens peuvent vérifier le code. Le taff n’a pas été fait.



Ou alors dans les crédits (package-lock.json) pouvoir avoir la liste des reviewers ayant validé le code.

Ca permettrait de pouvoir suivre les gens de confiance.

votre avatar

À mon sens on ne s’en sortira pas tant que les librairies tierces ne seront pas effectivement validées par des tiers de confiance. On ne peut pas demander à chaque intégrateur de tout relire. C’est inefficace et redondant.



Une solution serait que des entités fassent des review de sécurité des librairies et les “approuvent” formellement (signatures électroniques du code… non j’ai pas dit blockchain) Ces approuveurs seraient eux-mêmes évalués (un peu comme la notoriété sur Stack Overflow). Un approuveur qui laisserait passer un troyen verrait son évaluation chuter.



Et à chacun de dire s’il accepte ou non une librairie non validée dans son environnement.



Ca fait une vache de PKI, mais c’est à-peu-près la seule solution.

votre avatar

Ca passe au volet communication voila tout.

Rien de fondamental ne changera.

 

votre avatar

C’est surtout que JS a une lib standard famélique qui incite à faire des modules pour tout ce qui est commun dans d’autres langages, jusqu’à arriver à la culture du micro-module, avec l’exemple du package is-even qui importe le package is-odd (pour faire une négation) qui require is-number… <img data-src=" />



voir ici :github.com GitHubL’arbre des dépendances part vite dans tout les sens, rien n’est standardisé et les gens sont contents d’avoir des centaines de dépendances pour faire un “hello word”. C’est pas auditable en l’état.

Pour moi la solution viendrait de “gros” modules qui regroupent les fonctions aujourd’hui dispersées. Mécaniquement ils auraient une large base d’utilisateurs et de mainteneurs.

Après c’est pas dans la culture de la communauté JS. <img data-src=" />

votre avatar

Yeah, s’il n’avait pas transféré son repo, il aurait simplement fait comme les autres : l’indiquer comme déprécié et donné un lien vers un repo maintenu par - il n’avait aucun moyen de le savoir - un pirate.



C’est un des soucis de l’open source ou du libre : on veut du gratos, ne payer pour rien, ne jamais contribuer, mais se faire un max de thunes en les utilisant.

votre avatar

Mais pourquoi un “approuveur” ferait ce travail de relecture et de certification gratos s’il n’a rien à y gagner à part une possible évaluation négative ?



La première mesure à prendre est d’abord avant d’installer (ou mettre en dépendance) un paquet de s’assurer qu’il n’est pas maintenu par un seul gars il y a plusieurs années. C’est facile à vérifier et c’est le minimum syndical qu’un dev est censé effectuer. Si ce n’est pas le cas faut-il vraiment installer ça alors que bien souvent quelques lignes de code permettent de faire aussi bien qu’une énième dépendance ?



Et pour ceux qui en ont vraiment besoin qu’ils relisent eux-même le code, et tant qu’on y est en profitent aussi pour le maintenir.



L’info que je retiens d’abord là dedans est qu’un paquet aussi utilisé puisse avoir si peu de contributeurs.

votre avatar



Tarr estime que partager les droits d’édition et de publication est une

pratique commune dans le monde de Node.js, et assure qu’il n’aurait pas

accepté s’il s’était douté des intentions du pirate. Pour lui, il faut

soit payer les mainteneurs des modules (souvent fatigués, ne tirant rien

de modules qu’ils n’utilisent plus eux-mêmes), soit contribuer, tout

simplement.





Autant l’excuse de la pratique répandue est bidon, autant je peux comprendre qu’il en vienne à tout lâcher, sans se préoccuper de ce qu’il adviendra de la librairie. Le sujet de la rémunération des projets open source est épineux et n’est pas prêt d’être résolu… Il y a parfois des millions de projet qui les utilisent, donc certains de grandes sociétés qui gagnent des millions, et ne sont pas foutues de faire un petit don pour remercier le développeur.

votre avatar







skan a écrit :



Cette news pulvérise totalement l’argument disant qu’un projet Open Source est sûr parce que les gens peuvent vérifier le code. Le taff n’a pas été fait.





Oui et non, dans ce cas précis le mainteneur à bien pris soin de faire disparaître les modifications du dépôts Github associé au package après avoir généré la version vérolé.

La sécurité pourrait certainement être renforcé coté NPM, avec par exemple un petit warning pour informer que certains commit inclus dans le package ont disparus des sources voir un blocage automatique des packages dans cette situation.

Ceci dit dans ce cas les modification malveillantes auraient pu rester dans le dépôts ça n’aurait pas forcément rendus la détection plus rapide mais ça laisse au moins la possibilité de mettre outils pour auditer le code et détecter ce genre de “problème” (là aussi c’est de la responsabilité de NPM) dans le cas de produit dont le code est fermé ce genre de possiblité n’existe pas.


votre avatar







espritordu a écrit :



Mais pourquoi un “approuveur” ferait ce travail de relecture et de certification gratos s’il n’a rien à y gagner à part une possible évaluation négative ?







Parce que pour beaucoup ce n’est pas un travail, mais une passion. Parce que pour beaucoup ils ne font pas ça que pour leur gueule, mais pour le développement de leur écosystème de dev. Parce que ça fait bien sur un CV. Parce que ça rend service à d’autres gens.





Bienvenue dans notre monde Neo. Je vois que tu viens tout juste d’avaler ta pilule rouge ; Il existe un monde derrière le pognon.







espritordu a écrit :



L’info que je retiens d’abord là dedans est qu’un paquet aussi utilisé puisse avoir si peu de contributeurs.







Tout simplement parce que ce paquet est utilisé par d’autres paquets qui sont utilisés par d’autres paquets qui sont utilisés par d’autres paquets qui sont… ça n’en finit pas. Pour un pauvre module Node tu peux te retrouver avec plusieurs centaines de dépendances. C’est aussi la raison pour laquelle l’audit des dépendances est quasiment impossible.



On se base sur des dépendances pour gagner du temps. Si on en venait à devoir auditer des millions de lignes de codes avant de déclarer des dépendances et bien… on marcherait sur la tête, parce que le but initial c’est le gain de temps.



P.S. : Je ne suis pas fan du tout de l’écosystème Node.js


votre avatar

Il doit être dégoûté du fait d’être quasiment seul à contribuer à un module utilisé par des milliers de personnes. L’argent c’est secondaire… S’il n’y a pas de communauté pour épauler un projet, là ça devient problématique.

votre avatar

Il est devenu difficile de trouver des mainteneurs pour n’importe quel projet de nos jours de toute façon.



Il faut dire que la somme de travail augmente avec le temps (sécurité à prendre en compte, demandes des utilisateurs de plus en plus pointues, etc…), alors si en plus ce n’est pas paié, difficile de garder la motivation requise.



Et après en tant que user, on désespère parce qu’on doit remplacer un produit qui était excellent mais abandonné, ou on peste parce que ce dont on se sert n’a toujours pas la fonction X ou Y que l’on considère de base mais il n’y a pas assez de personnel pour s’en charger, ils ont une vie après tout.

votre avatar







Kevsler a écrit :



Parce que pour beaucoup ce n’est pas un travail, mais une passion. Parce que pour beaucoup ils ne font pas ça que pour leur gueule, mais pour le développement de leur écosystème de dev. Parce que ça fait bien sur un CV. Parce que ça rend service à d’autres gens.



Bienvenue dans notre monde Neo. Je vois que tu viens tout juste d’avaler ta pilule rouge ; Il existe un monde derrière le pognon.







Il est mignon…Qu’est ce qui a pu te faire penser avec autant de certitudes que je ne serais pas contributeur et militant du libre et que tu m’apprendrais quelque chose ?

Et en admettant que je sois un clone francophone de Steve Ballmer tu avais vraiment besoin de profiter de ta tirade pour t’offrir ton petit shoot égotique en me prenant de haut ? Tu penses convaincre qui à contribuer au libre de cette manière à part des fans de BDSM ?

Donc ta pilule tu sais où tu peux te la carrer.

Un moment faudra vraiment songer à arrêter ce genre de comportements qui pourrit le monde du libre et plus largement du développement.


votre avatar

Des millions de download par semaine. Combien donnaient au moins 1ct au dev ? Et combien remplissaient des tickets pour que des bugs soient corrigés gratuitement ?



Open source ou libre ne veut pas dire gratuit. Des fois, faut payer.

Bibliothèque Node.js vérolée : NPM sort un communiqué, le responsable se justifie

Fermer