Montée en puissance du protestware dans l’open source : présentation de 4 types d’initiatives et de leur impact

wordpress-sync/blog-feature-social-trends

March 22, 2022

0 minutes de lecture

Il y a quelques jours, Snyk a fait état d’un nouveau type de vecteur de menace détecté au sein de la communauté open source : le protestware. Ce bulletin évoquait une vulnérabilité transitoire nommée peacenotwar. Intégrée dans node-ipc, elle touchait la chaîne d’approvisionnement d’un grand nombre de développeurs. Snyk a recours à divers flux et algorithmes de données sur les menaces pour suivre les discussions autour des menaces pesant sur la communauté open source. Et d’après nos informations, cette vulnérabilité n’est peut-être que la face émergée de l’iceberg.

Depuis la publication de ce bulletin, nous avons en effet constaté une hausse massive des alertes concernant des menaces associées à la guerre, ainsi qu’une diversification des protestwares potentiels liés à l’invasion de l’Ukraine.

Les protestwares actuels se présentent sous de nombreuses formes. Certains semblent relever de la seule liberté d’expression, tandis que d’autres, comme node-ipc, sont de nature plus destructive et créent plus de dégâts. Snyk souhaite aider la communauté à atteindre un consensus sur l’attitude à adopter face aux différents protestwares qui fleurissent un peu partout et faciliter leur différenciation.

Qu’est-ce qu’un protestware ?

Le terme « protestware » est une dénomination générique décrivant les paquets altérés pour faire passer un message de protestation contre un événement. À la différence des paquets malveillants, ces modifications ne sont pas réalisées par des « hackers », mais par des membres connus et respectés de la communauté open source, qui gèrent ou contribuent activement à de grands projets.

Avant d’aller plus loin, nous tenons à préciser que Snyk est de tout cœur avec l’Ukraine. Nous avons clairement exprimé notre soutien au pays, que ce soit par le biais de dons, de la mise en avant des incroyables logiciels open source créés en Ukraine ou par la rupture de nos partenariats commerciaux avec toute entité russe ou biélorusse. Néanmoins, il est de notre devoir d’évoquer les menaces que nous découvrons dans la communauté open source et de jouer notre rôle dans sa sécurisation.

Dans cet article, nous allons présenter les quatre grands types de protestwares que nous avons rencontrés jusqu’ici, ainsi que les politiques que nous adoptons pour chacun. Nous espérons que ces informations ouvriront le débat dans la communauté.

Types de protestwares

1. Messages visibles dans les référentiels

Dans ces types de paquets, les chargés de maintenance ajoutent des messages politiques dans les référentiels. Ces protestwares prennent la forme de fichiers README modifiés pour exprimer un soutien à l’Ukraine, de modifications dans la description du paquet ou même de tickets ouverts contenant un message explicite. Pour Snyk, ce type d’initiative entre dans le cadre de la liberté d’expression et n’est aucunement destructif. Chaque chargé de maintenance et contributeur a le droit d’exprimer son opinion sur ce conflit.

Nous estimons n’avoir aucune mesure particulière à prendre face à ces actions.

2. Journaux de protestation dans les CLI

La deuxième forme de protestation va un peu plus loin. Des messages sont transmis directement sur les machines des utilisateurs, via les journaux des CLI, pendant et à la fin de l’installation des paquets. es5-ext, un paquet open source très populaire, illustre bien ce phénomène. Le vecteur utilisé est très représentatif de ce type de protestware :

  1. Une machine locale vérifie le fuseau horaire pour déterminer l’emplacement de l’environnement d’installation.

  2. En fonction de cet emplacement, un journal de CLI est enregistré via le script post-installation. Il contient un message de soutien à l’Ukraine et des informations sur la guerre, ainsi que des instructions de téléchargement du navigateur Tor pour contourner la censure du gouvernement russe.

Après avoir étudié les deux parties de ce vecteur, nous estimons que bien qu’inhabituel, ce type de comportement s’est déjà vu dans l’écosystème logiciel. Les vérifications locales du fuseau horaire d’un système interviennent parfois dans le cadre d’une installation normale, par exemple pour déterminer le meilleur moyen d’installer un paquet. En ce qui concerne l’enregistrement de messages dans les journaux de la CLI pendant l’installation, il arrive souvent que des messages longs soient enregistrés lors de l’installation d’un paquet, sans qu’ils aient de lien direct avec l’installation (crédits, émojis et autres informations annexes).

Tant que le message reste dans l’environnement d’installation (celui de la CLI), nous pensons qu’il n’y a à l’heure actuelle pas lieu de marquer spécifiquement ces paquets.

3. Journaux de protestation hors environnement

Cette dernière précision nous permet de faire la transition vers le troisième groupe de protestwares, à savoir les paquets qui exécutent du code en dehors de l’environnement d’installation. Nous pouvons par exemple citer les paquets event-source-pollyfill et peacenotwar. Si ces deux paquets font aussi appel au vecteur de géolocalisation via le fuseau horaire que nous avons présenté il y a quelques lignes, ils ne se contentent pas de diffuser leur message dans les journaux : ils exécutent du code directement sur la machine.

Ce type de protestware, même s’il n’est pas destructif, présente un comportement que nous estimons inattendu et indésirable dans un paquet open source. Il peut diffuser des informations via des fenêtres contextuelles, en ouvrant le navigateur ou en redirigeant une fenêtre de navigateur déjà ouverte vers des sites d’informations, ou même en créant des fichiers sur le bureau.

Nous allons étiqueter ces paquets « Comportement indésirable ». Nos vecteurs CVSS seront conçus de sorte à montrer avec précision en quoi consiste le comportement indésirable et son impact sur l’intégrité de la machine sur lequel il s’exécute.

4. Protestwares destructifs

Enfin, nous arrivons aux paquets qui adoptent clairement un comportement destructif et menacent directement les machines sur lesquelles ils s’exécutent. Node-ipc est actuellement le paquet de ce type le plus connu et utilisé. Comme nous l’avons déjà expliqué,il tente d’effacer les disques durs du système.

Les paquets adoptant des comportements destructeurs, par exemple en supprimant des fichiers, diffusant des informations confidentielles ou autres se verront attribuer l’étiquette « Paquet malveillant » et seront associés à une gravité élevée ou critique en fonction de leur impact.

Type de protestware

Exemple

Avis actuel de Snyk

Messages visibles dans les référentiels

Fichier Readme contenant des informations de protestation

Aucun avis

Journaux de protestation dans les CLI

Journal d’installation contenant des informations de protestation

Aucun avis

Journaux de protestation hors environnement

Fichier contenant des informations de protestation écrit sur le bureau

Gravité basse à intermédiaire, étiquette « Comportement indésirable »

Protestwares destructifs

Remplacement des fichiers sur le disque par des informations de protestation

Gravité élevée à critique, étiquette « Paquet malveillant »

Restez vigilant face aux protestwares

En résumé, la situation actuelle est très évolutive, et nous nous attendons à devoir faire face à de nouveaux vecteurs de menaces en lien avec les protestwares à l’avenir. À ce titre, notre mission s’articule autour de deux axes :

  1. Continuer à informer la communauté des nouveaux types de menaces faisant leur apparition aussi rapidement et exhaustivement que possible

  2. Orienter les débats sur la réponse que la communauté doit apporter aux protestwares sous toutes leurs formes et arriver à un consensus sur le sujet

Si vous tombez sur de nouveaux paquets open source contenant des protestwares, n’hésitez pas à nous contacter par le biais de notre programme de divulgation de vulnérabilités. Merci de contribuer à la sécurité de l’open source pour tous.

Patch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo SegmentPatch Logo Segment

Snyk est une plateforme de sécurité des développeurs. S’intégrant directement aux outils, workflows et pipelines de développement, Snyk facilite la détection, la priorisation et la correction des failles de sécurité dans le code, les dépendances, les conteneurs et l’infrastructure en tant que code (IaC). Soutenu par une intelligence applicative et sécuritaire de pointe, Snyk intègre l'expertise de la sécurité au sein des outils de chaque développeur.

Démarrez gratuitementRéservez une démo en ligne