Le développeur du composant JavaScript populaire node-ipc hébergé sur le référentiel npm a décidé de protester contre l'invasion de l'Ukraine par la Russie en ajoutant du code à son propre composant, lequel ajouterait ou supprimerait des fichiers sur les ordinateurs des utilisateurs de manière inattendue. Parce que divers autres projets s’appuient sur ce composant comme dépendance, ils ont dû publier des mises à jour d'urgence pour stopper ce comportement indésirable dont ils ont involontairement hérité. C'est la deuxième fois cette année qu’un évènement de ce genre se produit dans la communauté des développeurs Nodejs, certains ayant même commencé à qualifier ces actes d'auto-sabotage de « protestware ». Les experts estiment que si les développeurs ont certainement le droit de modifier leurs propres logiciels, de tels actes risquent d'entamer la confiance dans l'écosystème open source, déjà confronté ces dernières années à des défis croissants en matière de sécurité de la supply chain.

Que s'est-il passé avec node-ipc ?

Le module nodejs pour la communication interprocessus locale et distante compte plus de 4 millions de téléchargements mensuels sur le référentiel npm. Plus de 350 autres composants npm dépendent du module node-ipc, y compris des composants populaires comme l'interface de ligne de commande (CLI) pour le framework JavaScript Vue.js ou Unity Hub, un projet lié au moteur de jeu Unity. La semaine dernière, le développeur de node-ipc, alias RIAEvangelist sur GitHub, a publié plusieurs mises à jour des versions encore prises en charge de node-ipc afin d'ajouter du code malveillant au composant. Ce problème a été repéré par un autre développeur, Tyler Resch, alias MidSpike sur GitHub, qui a ouvert un rapport sur le système de suivi des bogues de node-ipc le 9 mars. Certains de ses commentaires dans le fil de discussion ont ensuite été supprimés par RIAEvangelist, de sorte que Tyler Resch les a documentés dans un référentiel distinct.

Selon une analyse des chercheurs de l’entreprise de sécurité des développeurs Snyk, tout a commencé le 8 mars quand RIAEvangelist, qui maintient plus de 40 composants sur npm, a publié un composant appelé peacenotwar sur le registre. Ce composant écrit un fichier appelé WITH-LOVE-FROM-AMERICA.txt sur le bureau de l'utilisateur avec des messages en plusieurs langues protestant contre la guerre en Ukraine. Le même jour, le développeur a également publié une nouvelle version majeure de node-ipc portant le numéro 11.0.0, laquelle ajoute peacenotwar comme dépendance. Les choses se sont intensifiées le 15 mars, quand RIAEvangelist a décidé de publier également node-ipc 9.2.2, une mise à jour de la branche 9.x du module, ajoutant également peacenotwar comme dépendance à cette branche. Considérée comme la version stable du module, la branche 9.x est la plus largement utilisée, attirant l'attention sur le problème car les utilisateurs de plusieurs projets qui s‘appuient sur node-ipc ont commencé à trouver le nouveau fichier sur leurs systèmes.

Des malwares dans la chaîne d'approvisionnement logicielle

Cependant, il s'avère que ce n'était pas la première tentative de sabotage de RIAEvangelist via node-ipc. Après avoir repéré peacenotwar, Tyler Resch a parcouru les commits de code et a trouvé un commit suspect le 7 mars qui ajoutait un fichier appelé ssl-geospec.js. Celui-ci contenait un code obscurci en base64 qui, quand il était exécuté, contactait un service de géolocalisation distant pour vérifier si l'adresse IP du système était basée en Russie ou au Belarus. Si le résultat était vrai, le code procédait à l'écrasement de tous les fichiers sur le volume du système avec un caractère de cœur. Il s'agissait essentiellement d'un comportement destructeur destiné à saboter les systèmes des utilisateurs russes et biélorusses.

Selon l'analyse de Snyk, ce code malveillant a été ajouté à la version 10.1.1 de node-ipc le 7 mars, sans qu'il en soit fait mention dans le changelog ou le readme. Une dizaine d'heures plus tard, une version 10.1.2 a été publiée sans pratiquement aucun changement de code. Selon les chercheurs, cette deuxième version était peut-être destinée à déclencher des mises à jour automatiques des dépendances. 5 heures plus, le 8 mars, RIAEvangelist a publié la version 10.1.3, qui supprimait le code malveillant.

Mesures d'atténuation et besoin de redonner confiance

À l'heure actuelle, les versions 9.2.2, 10.1.1 et 10.1.2 ont été supprimées du registre npm. La version 11.1.0 demeure, mais la page de description du module indique désormais que cette itération contient la dépendance peacenotwar. Sur le système de suivi des bogues node-ipc, le mainteneur a fait valoir que : « Ce que fait le module fait est documenté et il n'écrit un fichier que s'il n'existe pas. Libre à chacun de verrouiller sa dépendance à une version qui ne l'inclut pas jusqu'à ce que cette situation évolue d’une façon ou d’une autre, tout en agissant entre temps, soit avant qu’on ne bascule vers une troisième guerre mondiale, soit jusqu’à ce qu'elle s’achève, et cette dépendance sera supprimée ». Verrouiller ou épingler la dépendance sur une version sûre de node-ipc, c’est ce qu'ont fait les mainteneurs de Vue.js, ce qui constitue une bonne pratique. Snyk recommande également d'utiliser la fonction override du gestionnaire de paquets npm pour exclure toutes les versions concernées. Cependant, cette fonctionnalité n'est prise en charge qu'à partir de la version 8 de npm. Le gestionnaire de paquets Yarn prend également en charge les résolutions de versions sélectives. GitHub, qui gère le registre npm, a publié des avis de sécurité pour les problèmes d'écrasement de fichiers et de peacenotwar. L'incident soulève de nombreuses questions. Par exemple, peut-on faire confiance à ce mainteneur à l'avenir ? Faut-il lui retirer ses privilèges de publication de projets sur npm ou d'autres référentiels ? Que se passera-t-il si d'autres développeurs ont recours à des actes de sabotage de ce genre ? En janvier, deux autres modules populaires appelés colors et faker ont été intentionnellement sabotés par leur mainteneur. Le protestware va-t-il devenir un problème courant ?

« Même si l'acte délibéré et dangereux du mainteneur RIAEvangelist sera perçu par certains comme un acte légitime de protestation, on ne peut exclure qu’il aura un impact sur la réputation future du mainteneur et sur sa participation à la communauté des développeurs », a déclaré Liran Tal, directeur des développeurs chez Snyk. « Pourra-t-on faire encore confiance à ce mainteneur si l’on craint d’autres actes de ce type ou des actions encore plus agressives sur tous les projets auxquels il participe ? », a-t-il ajouté. « Je crois que la meilleure façon de répondre à cette question particulière de confiance, c’est d’adopter une hygiène appropriée de la supply chain des logiciels », a déclaré pour sa part Brian Fox, directeur technique de Sonatype. « Quand on choisit ses projets open source, on doit aussi s’intéresser à ses mainteneurs », a-t-il ajouté.

L'hébergement délibéré de code malveillant sur la sellette

Brian Fox recommande de choisir exclusivement du code provenant de projets soutenus par des fondations comme la Fondation Apache, dont les projets ne sont pas maintenus par un seul développeur ou un mainteneur unique. Ce qui implique une certaine surveillance, des examens de groupe et une gouvernance plus à même de détecter ce type d'abus avant qu'il ne soit diffusé dans le monde. « La question ne concerne pas seulement le code apporté », a aussi expliqué le directeur technique de Sonatype. « Elle s'applique également aux dépendances. Les fondations font preuve de la même diligence à l'égard des dépendances, ce qui rend le problème beaucoup moins probable et explique pourquoi il est si important de tenir compte de l'hygiène du mainteneur lors du choix d'un projet », a-t-il encore déclaré.

Selon le directeur, certes, Sonatype soutient les droits des développeurs à faire ce qu'ils veulent avec le code dont ils sont propriétaires, mais, en tant que gestionnaire de référentiel - Maven Central de Java - l’entreprise a clairement indiqué qu'elle supprimerait tout code vraiment malveillant. « Nous soutenons le droit du développeur, mais les référentiels ne devraient pas héberger du code délibérément malveillant par nature et nous pourrions refuser d'héberger son code à l'avenir ».