Node.js : une bibliothèque populaire vérolée vise un portefeuille de crypto-monnaies
Le 27 novembre 2018 à 09h24
2 min
Logiciel
Logiciel
Un reproche de plus en plus fréquent à l’endroit des projets libres, dont ceux fondés sur Node.js, est la forêt de dépendances plus ou moins solides sur lesquelles ils reposent. Certaines, pourtant considérées comme essentielles, sont maintenues par des particuliers sur leur temps libre, voire abandonnées.
C’était le cas d’event-stream pour Node.js, très utilisé. Pourtant, son concepteur Dominic Tarr a cessé son développement depuis longtemps, ouvrant la porte à right9ctrl.
Il a repris le projet et immédiatement publié even-stream 3.3.6, vérolé avec « flatmap-stream 1.1 ». Problème : la bibliothèque est téléchargée jusqu’à 2,4 millions de fois par semaine, selon NPM Stat.
« Il m’a envoyé un email et dit qu’il voulait maintenir le module, donc je lui ai donné. Je n’obtiens rien en maintenant ce module, je ne l’utilise même plus, depuis des années », s’est défendu le créateur de l’outil, face à des pairs dubitatifs. Certains lui ont dit d’archiver son projet sur GitHub s’il n’était plus activement développé ; une précaution oubliée.
Le projet est resté sous le nom de Dominic Tarr sur GitHub. Il ne peut être transféré officiellement à right9ctrl, qui avait déjà ouvert un dérivé (fork). Pourtant, le concepteur a perdu tous droits sur le projet sur npm, le système de distribution de modules de Node.js. Un utilisateur demande à revenir à la version 3.3.4, la dernière mouture sûre connue.
Le code masqué ne fonctionnerait qu’en présence de bibliothèques liées à Copay de Bitpay sur le même serveur. Copay permet de créer des portefeuilles de crypto-monnaies partagés. Le code malveillant inclus dans event-streamer tenterait donc de voler les bitcoins que contient Copay.
Selon NPM, la version 3.3.6 d’event-stream a disparu du dépôt, ne laissant que les moutures 3.3.5 et 4.x. Cette nouvelle branche a été publiée il y a deux mois par right9ctrl.
« La seconde mise à jour (commit) après [la version 3.3.6] retire l’injection et crée une nouvelle version majeure [4.x] pour nettoyer le dépôt GitHub de la présence de flatmap-stream, tout en conservant tous ceux utilisant la branche 3.x affectés », estime FallingSnow, qui a révélé le scandale sur GitHub.
Le 27 novembre 2018 à 09h24
Commentaires (16)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 27/11/2018 à 10h17
Voilà ! Je l’avais bien dit ! Pour tout ce qui concerne les applications financières, il n’y a que COBOL sur cartes perforées qui est sécurisé par design !
Sur un ton plus sérieux, c’est vrai qu’avec le foisonnement de librairies tierces qui se mettent à jour de manière plus ou moins transparente via PIP, NuGet ou NPM, on a d’une certaine façon réinventé le DLL hell… Y’a un boulot de fourmi derrière pour s’assurer que chaque projet qu’on développe ne pète pas l’environnement d’un autre. Un truc comme les Virtual Environments de Python, ça devrait être implémenté nativement par la plateforme, pas un opt-in qu’on déploie après avoir frôlé la cata en prod.
Le 27/11/2018 à 11h13
Le 27/11/2018 à 11h28
C’est tout simplement qu’il n’y pas de règles tangibles ni d’universalité.
Pour les règles : Bin on a pas de stress test, de test de sécurité, de vrais benchs quoi. Et surtout pas de responsables. C’est même un concept étranger pour certains.
Pour l’universalité : on code et recode les mêmes libs/modules dans un tas de langages différent. C’est juste très idiot.
Le 27/11/2018 à 11h55
D’un autre côté, les tests c’est bien, mais c’est loin d’être une panacée. Un test vérifie que la lib fait tout ce qu’elle doit faire, mais ne peut pas tester universellement qu’elle ne fait pas plus qu’elle n’est censée faire.
C’est tout le problème ici. Si le dév avait altéré une fonctionnalité, les tests unitaires l’auraient détecté. Il a plutôt ajouté un troyen et personne ne le remarque. Parce qu’aucun test unitaire ou d’intégration ne va vérifier qu’il n’y a pas des fonctionnalités cachées.
Bémol : c’est vrai qu’un test + code coverage pourrait détecter du code dormant.
Le 27/11/2018 à 14h18
Il m’a envoyé un email et dit qu’il voulait maintenir le module, donc je lui ai donné.
Le 27/11/2018 à 14h22
Le 27/11/2018 à 15h12
Le 27/11/2018 à 15h17
Le 27/11/2018 à 15h51
Le 27/11/2018 à 17h48
Je suis tout à fait d’accord, surtout sur le manque d’organisation, mais c’est justement une composante systemique du libre, car il existe certe des normes et autres “netiquettes” (désolé pour l’abus de language mais je sais pas trop quoi utiliser a la place xD), mais elle sont multiple, et chacun est libre de les implémenter ou non.
Certains se regroupent et forment des autorités de confiance, mais cette confiance se construit sur le long sur la base de ses resultats au lieux d’être mise en place par le haut (pour ça que je faisait le parallèle avec l’entreprise)
Des cas ou ça marche y’en a, mais c’est pas mieux car c’est libre, c’est mieux car c’est mieux, et le fait que ça soit libre fait que potentiellement tout le monde peut venir vérifier, par contre si en pratique personne viens vérifier, forcément, on vas pas aller loin :).
Le 27/11/2018 à 19h50
Si 2.4 millions de pc sont connectées à ton pc, et ne sont pas au courant que tu l’as cédé à un tiers, il peut aussi y avoir quelques surprises.
Le 27/11/2018 à 20h31
Aussi notons le cas fondation. Je pense que les fondations sont le meilleur espoir.
Blender Foundation : Blender, Document foundation : libreoffice, mariaDb Foundation et probablement d’autres que j’oublie.
C’est pas forcément des gros trucs mais au moins je les trouve plus utiles que certaines fondations en France qui ont des gros budgets sans qu’on comprenne pourquoi.
Certains diraient Linux foundation mais y’a un hic. C’est noyauté par MicroSoft dans un processus (3E - Embrace, Extend, Extinguish). C’est le bémol. Bon d’un autre coté MS ne peut pas avoir d’autre stratégie sur le sujet.
Bref le modèle des fondations me semble mieux tenir la route. C’est plus organisé par un coté gestion comme une boite mais moins con parce que pas vraiment tourné vers le commercial d’abord (comme une boite).
Le 27/11/2018 à 20h47
On l’a eu sur notre projet aujourd’hui. Le NPM ne passait plus.
" />
" />
C’était la dépendance d’une dépendance d’une dépendance
Edit: on a eu (information) du souci 20 minutes après la news :)
Le 28/11/2018 à 09h15
je comprends pas: avec le package.json on peut parfaitement spécifier une version en partuculier ; il me semble même que c’est la raison d’être de package-lock.json pour les arborescences de dépendances, non ? (à vérifier, j’ai suivi le truc que de loin).
au delà, le mec qui utilise une dépendance dans son projey, c’est un peu à lui de faire que son projet utilise la bonne version avec laquelle il a développé et testé son projet, et pas spécifier “trucmuche 3.5 ou n’importe quoi d’autre comme version qui suivra à l’avenir”
non ?
Le 28/11/2018 à 09h35
Tu rate un point: un projet qui est volontairement passé à la 3.6 (récup dernière version et tests unitaires de régression). Le projet fonctionne, mais ppersonne n’a détecté le virus.
Dés qu’il y a eu blocage du dépôt, ça a entrainé les dysfonctionnements.
Le 28/11/2018 à 13h55