Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Social Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Node.js : une bibliothèque populaire vérolée vise un portefeuille de crypto-monnaies

Node.js : une bibliothèque populaire vérolée vise un portefeuille de crypto-monnaies

Le 27 novembre 2018 à 09h24

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.

Abonnez-vous
votre avatar

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.

votre avatar







33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



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 !





Node est un serveur, cobol est un langage, il aurait fallu dire qu’il n’y a que les mainframe MVS et les as400 qui tiennent la route <img data-src=" />

#schtroumpfalunettes



Je plussoie sinon et j’irais même plus loin. Des webapps ont été créées pour palier aux pb de compatibilité des clients lourds, on a aujourd’hui des pb de compatibilité de navigateurs avec en prime des perfs dégueulasses dans les affichages de listes et les enchainements d’écrans en général.



On fait du code libre soit disant plus sécurisé mais quasi personne n’a le niveau ni le temps pour le relire.



On voulait s’émanciper de la centralisation autour des outils Microsoft et tout le monde fout ses dockers chez AWS.



On voulait éviter de tout centraliser niveau traitements avec la micro informatique et on obtient le cloud 25 ans après globalement.



Cette industrie est tellement une merde inefficiente, contradictoire, incapable d’aucune cohérence et qui suit les modes. Je comprend les gens qui restent sur cobol perso. <img data-src=" />


votre avatar

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.





&nbsp;



&nbsp;

votre avatar

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.

votre avatar



Il m’a envoyé un email et dit qu’il voulait maintenir le module, donc je lui ai donné.







  • Salut tu me donnes les droits root ?

  • Ok, lol.



    <img data-src=" />

votre avatar







TexMex a écrit :



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.





&nbsp;



&nbsp;





Bha peut être car la “communauté libriste”&nbsp; n’est pas une entreprise, donc chacun fait a sa sauce.



Sinon pour les projets pas updaté/en sommeil, certains réagissent comme si le type avait obligation de maintenir le truc jusqu’a la fin de ses jours, les fork c’est pas pour les chiens.



edit: @Jarodd: d’ailleur, j’utilise pas node, mais y’a rien qui t’avertis quand le proprio d’un module change ?


votre avatar







Gersho a écrit :



edit: @Jarodd: d’ailleur, j’utilise pas node, mais y’a rien qui t’avertis quand le proprio d’un module change ?





A ma connaissance, il n’y a que NuGet / .NET qui utilise des modules signés cryptographiquement (et encore, uniquement les binaires compilés, pas les sources) mais si on transfère la clé privée en même temps que les sources, c’est foutu.



&nbsp;


votre avatar







Jarodd a écrit :





  • Salut tu me donnes les droits root ?



    • Ok, lol.



      <img data-src=" />





      Bah oui, s’il y a transfert intégral d’un truc que je n’utilise plus, il n’y a pas de risque de sécurité pour moi : si je donne un PC à mon voisin, je vais logiquement lui donner les droits root dessus ; faire ça ne met pas en péril les PC qui sont encore chez moi.



votre avatar







Gersho a écrit :



Bha peut être car la “communauté libriste”&nbsp; n’est pas une entreprise, donc chacun fait a sa sauce.



Sinon pour les projets pas updaté/en sommeil, certains réagissent comme si le type avait obligation de maintenir le truc jusqu’a la fin de ses jours, les fork c’est pas pour les chiens.



edit: @Jarodd: d’ailleur, j’utilise pas node, mais y’a rien qui t’avertis quand le proprio d’un module change ?





Oui m’enfin libriste ne veut pas dire “n’importe quoi” non plus.

&nbsp;

&nbsp;Certes les gens n’ont pas d’obligations mais si le bébé n’est pas transmis dans de bonnes condition ça finira toujours mal. Forker à tout va n’est pas bon non plus.



&nbsp;Il y a un manque criant d’organisation. Ou tout du moins d’un niveau d’information qui permettrait de voir si on peut faire confiance à un truc ou un autre.



C’est ce qui fait que les gens croient que le mec est supposé maintenir rapidement. C’est en cela aussi que le librisme à du lol dans l’aile.



&nbsp;Node en est un parfait exemple. Ça présente comme un truc sérieux qui a un gros vivier de package mais en fait sous le capot c’est le bordel. Y’a pas d’organisation qui relie les choses entres elles. Et ça loupe pas comme on le voit.



&nbsp;&nbsp;


votre avatar

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 :).

votre avatar

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.

votre avatar

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.

&nbsp;

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.

&nbsp;

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

&nbsp;

&nbsp;

votre avatar

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 <img data-src=" /><img data-src=" />



Edit: on a eu (information) du souci 20 minutes après la news :)

votre avatar

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 ?

votre avatar

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.

votre avatar







brazomyna a écrit :



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”





je sais pas pour node, mais c’est comme ça que python/pip fonctionne


Node.js : une bibliothèque populaire vérolée vise un portefeuille de crypto-monnaies

Fermer