Un incident stupéfiant survenu ces derniers jours met en évidence les risques liés à la dépendance généralisée aux logiciels open source, tout en soulignant le travail gratuit dont profitent les entreprises qui utilisent ces logiciels.
Marak Squires, développeur et mainteneur open source, a saboté son dépôt pour protester contre le travail non rémunéré et ses tentatives infructueuses de monétiser faker.js et color.js, deux packages NPM majeurs utilisés par un grand nombre d’autres packages et projets.
L’industrie logicielle repose sur divers écosystèmes et ressources interdépendants. Cet incident illustre un problème bien connu et toujours irrésolu de la chaîne logistique logicielle : l’« enfer des dépendances ». Il est particulièrement présent dans l’univers de Nodes.js et de JavaScript, mais constitue également une préoccupation courante pour les logiciels open source en général.
Lors d’une attaque visant la chaîne logistique, les pirates tentent d’infecter des applications légitimes afin de diffuser des logiciels malveillants. Dans le cas de faker.js et de color.js, nous avons affaire à une variante assez rare qui exploite les privilèges d’accès les plus élevés.
À lire aussi : La sécurité de l’open source : un problème majeur
Des packages NPM populaires corrompus par leur auteur
NPM est le gestionnaire de packages de Node.js. Il s’agit du plus grand registre logiciel au monde, avec des centaines de milliers de packages.
Son utilisation est gratuite, et il n’est même pas nécessaire de s’inscrire ou de se connecter pour télécharger des tonnes de scripts et de bibliothèques tiers.
Colors est un package assez populaire, avec des millions de téléchargements, utilisé par les développeurs JavaScript et Node.js pour obtenir des couleurs et des styles personnalisés dans leur console. Selon GitHub, 4,3 millions de projets l’utilisaient, parmi lesquels figuraient de nombreux autres packages populaires.
Résultat : les nouvelles versions sont téléchargées par une multitude d’installations dès leur mise à disposition, ce qui rend le package particulièrement essentiel dans la chaîne logistique.
Quelques jours plus tôt, Squires avait « mis fin » à un autre dépôt bien connu, utilisé par 168 000 projets, appelé faker.js, avec un message de commit explicite : fin de partie.
Les fichiers principaux ont disparu ; seules quelques configurations subsistent.
Squires a publié le message suivant sur son dépôt GitHub :
« Nous avons constaté la présence d’un bug zalgo dans la version v1.4.44-liberty-2 de colors. »
Le nom de la branche fusionnée dans le cœur était étrange, et le commit associé, intitulé « fix bug », contenait des instructions malveillantes destinées à déclencher une boucle infinie :
for (let i = 666; i < Infinity; i++) {
if (i % 333) {
// console.log('testing'.zalgo.rainbow)
} console.log('testing testing testing testing testing testing testing'.zalgo)
}Le code ci-dessus se trouve dans le fichier index.js, qui s’exécute automatiquement lorsque la bibliothèque est utilisée. Le texte zalgo désigne des caractères spéciaux non ASCII qui ne s’affichent pas comme prévu et provoquent des dysfonctionnements de l’interface utilisateur.
Une fois exécuté, le code ne s’arrête jamais. Il s’agit d’un problème logique appelé « boucle infinie ». Tout, de l’entier utilisé pour initialiser la boucle (666) à la limite fixée par l’auteur (Infinity), laisse penser que c’était intentionnel.
À première vue, cela ressemble à une plaisanterie pour quiconque a déjà joué avec JavaScript, mais les projets qui dépendent de cette célèbre bibliothèque en ont subi les conséquences, avec de nombreuses interruptions de pipelines CI/CD et d’invites de terminal :
Squires n’est pas le seul mainteneur du dépôt, mais il a révoqué l’accès des autres mainteneurs afin de s’assurer que personne ne puisse annuler son action. Un message qu’il a ensuite publié sur Twitter a suscité un débat important sur le modèle open source, certains exprimant leur sympathie tandis que d’autres affirmaient que l’accord open source avait toujours été clair.
Les utilisateurs pourraient éventuellement revenir à des versions antérieures du logiciel, ce qui semble plus facile dans le cas de colors. La page de faker.js semble avoir été entièrement supprimée, mais archive.org reste une solution possible. Cette solution ne devrait toutefois être que temporaire, car il n’est plus possible de faire confiance à ces dépôts. Il existe des packages alternatifs et, dans le cas de faker, une alternative a déjà fait son apparition.
Github a publié un avis de sécurité concernant colors.
À lire aussi : Les meilleurs outils de débogage et de sécurité du code
L’état de l’open source
Sur son blog, le développeur a déclaré qu’aucune entreprise n’avait soutenu financièrement faker.js et color.js. Il n’a reçu que quelques dons via GitHub Sponsorships, provenant de développeurs comme lui.
Il a essayé de monétiser son code en lançant un service cloud avec des abonnements mensuels, mais n’a pas réussi à attirer suffisamment d’utilisateurs. Il affirme que l’un de ses sponsors GitHub, qui semblait également être un abonné inscrit, s’est approprié son idée pour lancer la même offre.
Une impasse dans l’open source n’est pas totalement inhabituelle et peut conduire à des réactions extrêmes dans les pires scénarios, comme celle de Squires avec ses dépôts.
Cela pourrait inciter davantage de mainteneurs open source à agir de la sorte et même devenir une tendance si personne ne trouve de modèles économiques durables, notamment lorsque de nombreuses organisations privées et à but lucratif utilisent ou forkent des ressources publiques.
Même si GitHub et NPM ont réagi rapidement en supprimant les packages et en suspendant temporairement le compte de l’auteur, le mal est fait.
Les développeurs devraient se préparer à ce type d’incident en améliorant la gestion des dépendances.
Comment atténuer les incidents liés aux dépendances
Même s’il est impossible d’anticiper de telles actions radicales, il est possible d’améliorer sa préparation. Vous pouvez appliquer des bonnes pratiques de sécurité open source pour atténuer les incidents, notamment :
- Tester avant de déployer quoi que ce soit dans un environnement distant
- Verrouiller les versions exactes : dans le fichier package.json qui répertorie les packages, n’utilisez pas de symboles tels que “^” ou “~” pour les dépendances, car cela est plus permissif et autorise les mises à jour automatiques mineures (ou plus importantes) lorsque vous exécutez une mise à jour npm
- Être particulièrement vigilant face aux packages mal orthographiés afin d’empêcher les attaques par typosquatting
Pour aller plus loin : Les meilleurs outils de gestion des vulnérabilités