Le protestware gagne du terrain dans l’open source : 4 types et leurs conséquences

Il y a quelques jours, Snyk a signalé l’apparition d’un nouveau type de vecteur de menace dans la communauté open source : le protestware. L’alerte concernait une vulnérabilité transitive — peacenotwar — dans node-ipc, qui a touché la chaîne d’approvisionnement de nombreux développeurs. Snyk s’appuie sur différentes sources de veille sur les menaces et des algorithmes pour suivre les discussions autour des menaces potentielles qui pèsent sur l’open source. Nous pensons que ce n’est peut-être que la partie émergée de l’iceberg du protestware.

Depuis la publication de l’alerte concernant node-ipc, nous avons constaté une forte hausse du nombre d’alertes que nous consacrons aux menaces liées au conflit, ainsi qu’une augmentation du nombre de types différents de protestware potentiel associé à l’invasion de l’Ukraine.

Le protestware prend actuellement de nombreuses formes. Certaines semblent relever de la liberté d’expression, tandis que d’autres, comme node-ipc, sont plus destructrices et dommageables. Chez Snyk, nous souhaitons aider la communauté à trouver un consensus sur la manière d’aborder les différentes formes de protestware qui apparaissent, et à distinguer leurs différents types.

Qu’est-ce que le protestware ?

Le protestware est un terme générique qui désigne des packages modifiés d’une manière ou d’une autre pour protester contre un événement donné. Contrairement aux packages malveillants, ces modifications ne sont pas le fait de « hackers » ou d’autres acteurs malveillants, mais souvent de membres connus et respectés de la communauté open source, qui sont mainteneurs ou contributeurs actifs de projets open source de grande envergure.

Avant d’aller plus loin, Snyk est solidaire de l’Ukraine. Nous l’avons clairement montré en décidant de faire un don pour aider l’Ukraine, de mettre en lumière les formidables projets open source issus d’Ukraine et de mettre fin à nos relations commerciales avec des entités russes et biélorusses. Cela dit, nous avons toujours le devoir de signaler les menaces découvertes dans la communauté open source et de contribuer à la sécurité de l’open source.

Dans cet article, nous présenterons les quatre grandes catégories d’activités liées au protestware que nous avons rencontrées jusqu’à présent, ainsi que notre politique à l’égard de chacune d’elles. Nous espérons que cela permettra d’alimenter les échanges au sein de la communauté.

Types de protestware

1. Bannières dans les dépôts

Dans ce type de package, les mainteneurs ajoutent des messages politiques sous forme de « bannières » directement dans le dépôt. Il peut s’agir de fichiers README modifiés pour exprimer leur soutien à l’Ukraine, d’une description de package modifiée pour soutenir la cause, ou simplement de problèmes ouverts accompagnés d’un message explicite. Du point de vue de Snyk, cette forme de protestation relève clairement de la liberté d’expression non destructrice. Chaque mainteneur et contributeur a le droit d’exprimer son opinion sur les sujets de son choix.

Dans ce genre de cas, nous estimons clairement qu’aucune action n’est nécessaire de notre part.

2. Messages de protestation dans les journaux de la CLI

La deuxième forme de protestation va plus loin : elle affiche directement des messages sur les machines des utilisateurs dans les journaux de la CLI, pendant et après l’installation du package. es5-ext en est un bon exemple dans un package open source très populaire, et le vecteur utilisé est assez représentatif de ces formes de protestware :

1. La machine locale vérifie le fuseau horaire pour déterminer où elle se trouve.

2. En fonction de cette localisation, un script post-installation affiche un message de soutien à l’Ukraine et des informations sur la guerre dans les journaux de la CLI, ainsi que des instructions pour télécharger Tor afin de contourner la censure des sites d’information sur la guerre par le gouvernement russe.

Après examen de ces deux éléments du vecteur, nous estimons que, même si ce comportement est inhabituel, il a des précédents dans l’écosystème logiciel. Concernant la vérification du fuseau horaire, les vérifications locales du système font parfois partie du processus normal d’installation, par exemple pour déterminer la meilleure façon d’installer un package. Quant aux messages affichés dans la CLI pendant l’installation, ils sont souvent très détaillés et ne portent pas tous directement sur l’installation du package (des crédits, des émojis et d’autres informations « secondaires » peuvent parfois être affichés).

Tant que les messages restent dans l’environnement d’installation (la CLI), nous estimons actuellement qu’il n’est pas nécessaire de signaler spécifiquement ces packages.

3. Messages de protestation hors de l’environnement d’installation

Cette dernière distinction nous amène naturellement à la troisième catégorie de protestware : les packages qui protestent en exécutant du code en dehors de l’environnement d’installation. Les packages event-source-pollyfill et peacenotwar en sont des exemples. Tous deux utilisent le « vecteur de géolocalisation par fuseau horaire » décrit précédemment, mais vont plus loin que l’affichage de messages de protestation dans les journaux : ils exécutent activement du code sur la machine pour protester.

Nous estimons que ce type de protestware, bien que non destructeur, crée un comportement que nous ne nous attendons pas à trouver et ne souhaitons pas voir dans un package open source. Les auteurs peuvent choisir de diffuser des informations en créant des fenêtres d’alerte, en ouvrant un navigateur et en le redirigeant vers des sites d’information, ou même en créant de nouveaux fichiers contenant des informations sur le bureau du système.

Pour ces packages, nous ajouterons une alerte intitulée « Comportement indésirable ». Nos vecteurs CVSS détailleront précisément ce comportement indésirable et son impact sur l’intégrité de la machine où le package s’exécute.

4. Protestations destructrices

Enfin, il y a les packages qui affichent clairement un comportement destructeur et menacent directement les machines sur lesquelles ils s’exécutent. Node-ipc est actuellement le plus important et le plus connu de ces packages et, comme nous l’avons déjà révélé, tente d’effacer les disques durs du système.

Les packages qui ont un comportement réellement dommageable — suppression de fichiers, fuite d’informations privées ou toute autre action de ce type — seront classés sous l’intitulé « Package malveillant », avec une gravité élevée ou critique (selon l’impact précis du package).

Restez vigilant face au protestware

En résumé, la situation actuelle est instable et nous nous attendons à devoir continuer à faire face à de nouveaux vecteurs de menace liés au protestware. Nous estimons avoir deux rôles à jouer :

1. Continuer à informer la communauté des nouveaux schémas de menace dès qu’ils apparaissent, avec la plus grande diligence possible.

2. Contribuer à orienter les discussions sur la manière dont notre communauté doit réagir aux différentes formes de protestware, et, nous l’espérons, parvenir à un consensus plus général sur la question.

Si vous découvrez d’autres cas de protestware dans des packages open source, n’hésitez pas à nous contacter dans le cadre de notre programme de signalement des vulnérabilités open source. Merci de contribuer à la sécurité de l’open source pour tous.