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.
Commentaires (15)
#1
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.
#2
À 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.
#3
Ca passe au volet communication voila tout.
Rien de fondamental ne changera.
#4
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…
" />
" />
voir ici :https://github.com/jonschlinkert/is-even/blob/master/index.js
L’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.
#5
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.
#6
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.
#7
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.
#8
#9
#10
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.
#11
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.
#12
#13
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.
#14
#15
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.