Le mainteneur d’un package open source met fin aux packages npm colors et faker : que faire maintenant ?

Le 8 janvier 2022, le mainteneur open source du très populaire package npm colors a publié colors@1.4.1 et colors@1.4.44-liberty-2, dans lesquels il a volontairement introduit un commit ajoutant une boucle infinie au code source. La boucle infinie se déclenche et s’exécute dès l’initialisation du code source du package, provoquant un déni de service (DoS) sur tout serveur Node.js qui l’utilise.

En bref : Snyk a signalé une vulnérabilité de sécurité de type déni de service dans colors@1.4.1, due à ce code vulnérable. Nous vous recommandons vivement de revenir à colors@1.4.0 et d’épingler les versions de vos dépendances afin d’éviter les mises à niveau automatiques vers la version problématique. Nous vous recommandons également de migrer vers un autre package. Poursuivez votre lecture pour en savoir plus sur le périmètre, l’impact et les mesures de prévention recommandées.

À propos de colors

Le package npm open source colors totalise plus de 20 millions de téléchargements par semaine. Projet incontournable de l’écosystème JavaScript et Node.js, il alimente de nombreux projets. Selon les données de GitHub, le projet colors est utilisé dans plus de 4 millions d’autres projets, et npmjs.org indique que 18 962 autres packages en dépendent.

Voici quelques projets qui dépendent de colors :

• L’outil d’aide en ligne de commande prompt (environ 500 000 téléchargements par semaine)

• L’outil de mise en forme de tableaux Unicode cli-table3 (environ 7 millions de téléchargements par semaine)

• Le propre package aws-cdk d’AWS (environ 2 millions de téléchargements par semaine)

En réalité, la version défectueuse colors@1.4.1 touche un grand nombre d’utilisateurs et ne doit pas être prise à la légère. D’après les statistiques de la page du package sur npmjs, cette version avait été téléchargée 95 397 fois au moment de la rédaction de cet article :

Le code problématique

Le code problématique suivant a été introduit dans la bibliothèque vulnérable colors :

1for (let i = 666; i < Infinity; i++;) {
2   if (i % 333) {
3       // console.log('testing'.zalgo.rainbow)
4   }
5   console.log('testing testing testing testing testing testing testing'.zalgo)
6}

Cette boucle infinie, située dans le fichier index.js du code source du package, perturbe toute utilisation du package tout en affichant dans le terminal un texte zalgo particulièrement inquiétant :

Je dépends du package colors : que faire pour limiter les risques ?

Si vous êtes actuellement touché par l’incident colors parce que vous utilisez la version défectueuse 1.4.1, nous vous recommandons de revenir à la dernière version fiable connue, colors@1.4.0, qui ne contient pas le code problématique avec la boucle infinie. Par exemple, pour fixer la version stable et sûre du package colors dans votre fichier package.json, remplacez ce qui suit :

1"colors":"^1.4.0"

par :

1"colors":"1.4.0"

Pour l’avenir, nous vous recommandons d’appliquer les bonnes pratiques suivantes lors de la gestion des bibliothèques open source dans vos projets :

1. Épinglez vos dépendances, soit dans votre fichier package.json, soit à l’aide d’un fichier de verrouillage. Vous éviterez ainsi que des résolutions au moment de l’installation n’installent de nouvelles versions, notamment la version 1.4.1 de colors, qui a introduit le problème.

2. Cet incident devrait vous inciter à envisager de passer à un autre package de gestion des couleurs, comme chalk.

3. Examinez les pratiques de maintenance et la pérennité des packages open source que vous envisagez d’utiliser, et vérifiez qu’ils disposent d’un modèle de gouvernance adapté, avec plusieurs contributeurs, par exemple.

Faker.js : même mainteneur, même histoire ?

Cet événement fait suite à un incident similaire concernant le populaire package npm faker (plus connu sous le nom de Faker.js), maintenu par la même personne. Faker est utilisé par de nombreux développeurs pour générer de grandes quantités de données fictives, notamment dans le cadre de tests logiciels.

Faker totalise 2 millions de téléchargements par semaine et est également une dépendance très répandue dans les projets JavaScript et Node.js. Pourtant, le 5 janvier 2022, le dépôt GitHub open source de ce package a reçu un commit forcé qui a entièrement remplacé le code source d’origine du package :

La version du package npm faker est ainsi passée à 6.6.6 et a été publiée sur le registre public npmjs sous la forme d’un package vide, sans code source.

Le mainteneur a créé un ticket indiquant qu’il ne maintiendrait plus gratuitement le package :

L’auteur a ensuite supprimé le dépôt GitHub contenant le code source du projet, ce qui a probablement fortement perturbé des milliers de développeurs qui utilisent ce package et doivent désormais trouver une solution de migration.

Plus tard, il a publié un article sur son blog personnel à ce sujet, détaillant les tentatives infructueuses de monétisation ou de recherche de sponsors pour le projet, et expliquant que le niveau actuel des dons n’est pas viable : « Comme la plupart d’entre nous, j’ai des personnes qui comptent sur moi et des factures à payer ».

Comme ce même mainteneur contribue à environ 170 autres packages npm, cette histoire pourrait bien ne pas s’arrêter là.

Les risques liés à la gouvernance et au financement de l’open source

Cet événement s’inscrit dans une tendance générale au sein de la communauté open source : les entreprises et les organisations qui s’appuient sur du code open source en production pour créer leurs produits doivent-elles en être responsables ?

Après la publication du code problématique dans colors, le mainteneur a également ouvert lui-même un ticket GitHub sur le sujet, où il plaisante en expliquant ne pas trouver l’origine de ce « bug » et ne pas avoir le temps de s’en occuper.

Marak poursuit en identifiant d’autres développeurs Node.js très prolifiques pour leur demander de l’aide, mais aucun d’entre eux n’a réellement accès au dépôt du projet :

Ces incidents s’inscrivent dans une tendance récente de la communauté open source : de plus en plus de mainteneurs expriment leur mécontentement face aux entreprises et organisations qui monétisent et utilisent des logiciels open source dans leurs produits.

En réponse aux critiques visant l’open source après Log4Shell, nous avons récemment abordé les difficultés des mainteneurs à assurer la pérennité de logiciels open source sains sans financement.

Nous pourrions assister à une tendance persistante : des mainteneurs bloquent totalement l’accès à leurs packages. Si leur mécontentement est tout à fait compréhensible et leurs arguments valables, il faut noter que bloquer l’accès aux packages open source nuira également à d’autres développeurs et mainteneurs open source.

Adopter les bonnes pratiques de sécurité open source

Utiliser des logiciels open source implique d’évaluer correctement les risques liés à ce type d’incident, ainsi que les autres problèmes de sécurité et juridiques, et de se préparer à y faire face. Mieux encore, nous pouvons adopter les bonnes pratiques qui permettent d’éviter et d’atténuer les problèmes potentiels de sécurité de la chaîne d’approvisionnement logicielle.

Pour mieux vous préparer à de futures situations similaires, nous vous recommandons les pratiques et ressources suivantes :

1. Examinez l’état de la maintenance et la pérennité des projets open source. Snyk Advisor est un outil qui vous aide à évaluer le niveau de santé d’un package.

2. 10 bonnes pratiques pour sécuriser npm souligne l’importance d’activer l’authentification à deux facteurs, d’épingler les dépendances à l’aide de fichiers de verrouillage adaptés, et bien plus encore.

3. Découvrez comment sécuriser votre chaîne d’approvisionnement logicielle moderne, notamment face à la confusion de dépendances, au typosquattage et aux packages malveillants.

4. Des conseils pratiques sur la façon dont Snyk vous aide à prévenir les packages malveillants et les attaques contre la chaîne d’approvisionnement logicielle.