Support technique
Documentation
Connexion
Nous contacter
"Tout" et l'évier de cuisine Node.js aussi
Joao Correia
11 janvier 2024 - Évangéliste technique
- *La chaîne d'approvisionnement est vulnérable à tous les niveaux, du code à la distribution.
- *Le dépôt Node.js a été verrouillé après qu'un développeur a téléchargé un paquet malveillant.
Il est souvent difficile de faire la différence entre les conséquences voulues et non voulues. Une récente "farce" pendant les vacances a compliqué la vie des développeurs Node.js, soulignant un adage familier : aucune bonne action ne reste impunie.
Il y a un peu de narration, donc le pop-corn est vraiment recommandé pour ce film.
Dans les temps lointains de 2016...
...un développeur Node.js a créé un paquetage appelé "leftpad", qui ne comporte que 11 lignes de code. Le remplissage de chaînes de caractères est une tâche courante pour les développeurs, qui préfèrent généralement ne pas réinventer la roue (principe de programmation "Don't Repeat Yourself" - DRY).
Naturellement, beaucoup ont choisi d'importer "leftpad" dans leurs projets. Mais cette dépendance a introduit une vulnérabilité - l'exposition à tous les problèmes liés à "leftpad", qu'il s'agisse de bogues, de lacunes de sécurité ou des caprices de son créateur. Dans un tournant dramatique, le développeur de "leftpad", invoquant le droit de retirer son travail, l'a fait. Cette action a provoqué la panne d'un grand nombre de sites web importants, soulignant la fragilité de telles dépendances. En toute honnêteté, l'auteur a fourni quelques raisons pour agir de la sorte, et le fait que vous soyez ou non d'accord avec la commercialisation du code source ouvert par les entreprises modifiera votre point de vue à ce sujet (vous pouvez en savoir plus à ce sujet icisi vous le souhaitez).*
En fin de compte, la suppression de "leftpad" a provoqué de graves perturbations sur de nombreux paquets et sites web tiers. Pour éviter que cela ne se reproduise, le registre npm a mis en place une politique : un paquet ne peut pas être dépublié s'il est une dépendance d'un autre paquet. Cette règle a semblé efficace pendant un certain temps.
C'est très bien, mais que s'est-il passé récemment ?
Comme nous ne pouvons évidemment pas avoir de belles choses, les gens ont cherché des moyens potentiels d'abuser du changement introduit par le registre. Et, en inversant la logique, si je ne peux pas supprimer un paquetage dont quelqu'un d'autre dépend, peut-être que quelqu'un d'autre ne peut pas supprimer le sien si mon code dépend de son paquetage... et, bien sûr, cela a fonctionné.
Ainsi, dans ce que le développeur a décrit plus tard comme un "test" et une "farce", un paquet appelé "everything" a été ajouté au registre. Il ne faisait rien d'autre que d'inclure, en tant que dépendances, un groupe d'autres paquets appelés "everything chunk 1", "everything chunk 2", etc. Ceux-ci, à leur tour, incluaient tous les paquets dans le registre. Il était donc impossible de dépublier un paquet, quel qu'il soit, puisqu'il y avait toujours une dépendance.
Mais cela s'améliore. Ou pire, selon la quantité de pop-corn qu'il vous reste.
La déclaration de dépendance d'un paquetage npm permet aux développeurs de "dépendre" d'une version spécifique. En général, il s'agit d'une version testée qui fait ce qu'elle prétend faire, correctement, et le développeur qui inclut ce paquet a effectué des tests approfondis pour s'assurer que le comportement est celui nécessaire pour son paquet ou son application.
Mais vous n'êtes pas limité à spécifier une seule version. En définissant "*" comme valeur de la version, vous indiquez à npm que *n'importe quelle* version de ce paquetage peut être utilisée comme dépendance.
Eh bien, "tout" incluait chaque dépendance... et chaque version de ces dépendances, puisqu'il utilisait "*" dans la déclaration.
Ainsi, les autres développeurs n'étaient pas simplement empêchés de supprimer leurs propres paquets (par exemple, s'ils présentaient un bogue), mais aussi toute ancienne version.
"Tout était bien verrouillé.
Le problème a-t-il été résolu ?
Oui, heureusement. Le créateur de "everything" a collaboré avec l'équipe de support npm pour rectifier le problème, ce qui a nécessité une intervention en marquant les dépôts "everything chunk" comme privés, rompant ainsi la chaîne de dépendance (plus d'informations à ce sujet, y compris une capture d'écran du développeur s'excusant, peuvent être consultées ici).
La communauté de la cybersécurité et des technologies de l'information a frôlé l'incident. Il soulève une possibilité qui fait froid dans le dos : au lieu qu'un développeur crée ce chaos pour faire une farce (ou un "test"), que se serait-il passé s'il s'était agi d'un acteur de menace sérieux ? Et si un paquet de type "everything" n'était que la partie émergée de l'iceberg, utilisé pour interdire la suppression d'un autre paquet dont le code présente une vulnérabilité de sécurité de niveau log4j ?
L'écosystème npm et, en fait, tout environnement similaire axé sur les dépendances de paquets, doit encore relever des défis importants pour remédier à ces vulnérabilités. Il est possible qu'il n'y ait pas de solution parfaite, étant donné la créativité avec laquelle les gens exploitent les failles.
Dans ce combat permanent, l'IA pourrait peut-être apporter une aide précieuse.
* Pour d'autres exemples de paquets apparemment insignifiants mais ayant un impact important, voir la page suivante "One liner rpm package "is-windows" has 2.5 million dependents, why on earth ?!" (Un paquet rpm "is-windows" a 2,5 millions de dépendants, pourquoi sur terre ?) sur Reddit. Un seul développeur est crédité de plus de 1 400 paquets, dont la plupart sont de simples lignes, ce qui montre l'influence surprenante du code minimal.
