Discussion :

[Bill Fassinou]

Un paquet npm compromis par l'auteur efface les fichiers sur les ordinateurs russes et biélorusses lors de l'installation
pour protester contre l'invasion de l'Ukraine par la Russie

Le développeur à l'origine du populaire paquet npm "node-ipc" a expédié ce mois-ci une nouvelle version pour protester contre l'invasion de l'Ukraine par la Russie. Mais les changements ont introduit un comportement indésirable qui cible les utilisateurs avec des adresses IP situées en Russie ou en Biélorussie et efface tous leurs fichiers lors de l'installation pour les remplacer par un émoji de cœur. Cet acte de sabotage suscite de nouvelles inquiétudes quant à la sécurité de la chaîne d'approvisionnement des logiciels et des logiciels libres.

"node-ipc" est un module Node.js pour "la communication interprocessus locale et distante" avec un support complet pour Linux, Mac et Windows. Il supporte également toutes les formes de communication par socket, des sockets bas niveau d'Unix et de Windows aux sockets UDP et sécurisés TLS et TCP. Avec plus de 1,1 million de téléchargements hebdomadaires, node-ipc est un paquet important utilisé par des bibliothèques majeures comme Vue.js CLI. Cependant, le développe de node-ipc, Brandon Nozaki Miller, a saboté le paquet pour nuire aux utilisateurs se trouvant en Russie ou en Biélorussie, en vue de militer contre l'invasion russe en Ukraine.

Tout a commencé le 8 mars lorsque Miller, plus connu sous le pseudonyme RIAEvangelist, a publié deux paquets open source appelés "peacenotwar" et "oneday-test" sur npm et GitHub. Les paquets semblent avoir été créés à l'origine par Miller comme un moyen de protestation pacifique, car ils ajoutent principalement un "message de paix" sur le bureau de tout utilisateur qui installe les paquets. « Ce code sert d'exemple non destructeur de la raison pour laquelle le contrôle de vos modules Node.js est important. Il sert également de protestation non violente contre l'agression de la Russie qui menace le monde en ce moment », explique RIAEvangelist.

Mais le chaos s'est installé lorsque certaines versions npm de node-ipc ont été vues lançant une charge utile destructrice vers toutes les données et écrasant tous les fichiers des utilisateurs installant le paquet. Fait intéressant, le code malveillant lisait l'adresse IP externe du système et ne supprimait que les fichiers des utilisateurs basés en Russie et en Biélorussie. Le code malveillant présent dans node-ipc, en particulier dans le fichier "ssl-geospec.js", contient des chaînes codées en base64 et des techniques d'obscurcissement pour masquer son véritable objectif. Snyk, une startup spécialisée en cybersécurité, a suivi et documenté les faits.

Une copie simplifiée du code fournie par les chercheurs de Snyk montre que pour les utilisateurs basés en Russie ou en Biélorussie, le code réécrit le contenu de tous les fichiers présents sur un système avec un émoji de cœur, ce qui a pour effet de supprimer toutes les données sur un système. Mais ce n'est pas tout. Les chercheurs ont rapporté que comme les versions 9.2.2, 11.0.0 et les versions supérieures à 11.0.0 de node-ipc intègrent le module "peacenotwar", les utilisateurs concernés ont vu des fichiers 'WITH-LOVE-FROM-AMERICA.txt' apparaître sur leur bureau avec des messages de 'paix' (comme le montre l'image ci-dessous).

Selon les chercheurs, cet acte représente un réel danger pour les utilisateurs de node-ipc basés dans ces régions. « À ce stade, un abus très clair et un incident critique de sécurité de la chaîne d'approvisionnement se produiront pour tout système sur lequel ce paquet npm sera appelé, s'il correspond à une géolocalisation de la Russie ou de la Biélorussie », écrit Liran Tal, directeur de la défense des développeurs chez Snyk dans un billet de blogue. En outre, cet acte de sabotage a déclenché une panique générale dans la communauté du framework JavaScript de développement front-end Vue.js, qui utilise également node-ipc comme dépendance.

Avant cet incident, Vue.js n'épinglait pas les versions de la dépendance node-ipc à une version sûre et était configuré pour récupérer les dernières versions mineures et correctives. En tant que tels, les utilisateurs de Vue.js CLI ont lancé un appel urgent aux mainteneurs du projet afin qu'ils épinglent la dépendance node-ipc à une version sûre, après que certains aient été surpris. Et, comme l'ont observé les chercheurs, Vue.js n'est pas le seul projet open source à être touché par ce sabotage. Ainsi, ils avertissent les développeurs et les autres responsables de projets de s'assurer qu'ils ne sont pas sur une version malveillante de node-ipc.

Les chercheurs de Snyk estiment que les versions 10.1.1 et 10.1.2 de node-ipc qui causent des dommages flagrants au système ont été retirées par npm dans les 24 heures suivant leur publication. Cependant, les versions 11.0.0 et supérieures de node-ipc restent disponibles sur npm et ils contiennent toujours le module "peacenotwar" qui crée les fichiers 'WITH-LOVE-FROM-AMERICA.txt' mentionnés ci-dessus sur le bureau. En tant que tel, si votre application est construite en utilisant la bibliothèque node-ipc, assurez-vous de définir la dépendance sur une version sûre telle que 9.2.1 (il s'avère que 9.2.2 n'est pas innocent non plus).

Il s'agit du deuxième incident majeur de protestation d'un développeur open source cette année, après le sabotage des paquets "colors" et "fakers" en janvier par leur développeur. Dans le cas de "colors", son développeur Marak Squires a suscité des réactions mitigées de la part de la communauté open source parce que sa manière de protester impliquait de casser des milliers d'applications en y introduisant des boucles infinies. Cependant, l'action de RIAEvangelist, qui maintient plus de 40 paquets sur npm, a suscité de vives critiques pour avoir dépassé la simple "protestation pacifique".

Il a déployé activement des charges utiles destructrices dans une bibliothèque populaire sans aucun avertissement aux utilisateurs honnêtes. Un utilisateur de GitHub a qualifié ce comportement d'"énorme dommage" pour la crédibilité de l'ensemble de la communauté open source. « Ce comportement est au-delà du f**** up. Bien sûr, la guerre est mauvaise, mais cela ne justifie pas ce comportement (par exemple, supprimer tous les fichiers pour les utilisateurs de Russie/Biélorussie et créer un fichier étrange dans le dossier du bureau). F*** you, allez en enfer. Vous venez de ruiner avec succès la communauté open source », a déclaré un autre.

« Tu es content maintenant @RIAEvangelist ? », a-t-il demandé. Pour d'autres, les développeurs devraient trouver d'autres terrains de protestation et arrêter de nuire à la réputation de l'open source. « 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. Comment cela se répercute-t-il sur la réputation future du mainteneur et sur sa place dans la communauté des développeurs ? », demande Tal de Snyk.

D'après Tal, cet incident de sécurité implique des actes destructeurs de corruption de fichiers sur le disque par un mainteneur et ses tentatives de cacher et de reformuler ce sabotage délibéré sous différentes formes. Bien qu'il s'agisse d'une attaque aux motivations contestataires, elle met en lumière un problème plus large auquel est confrontée la chaîne d'approvisionnement des logiciels : les dépendances transitives de votre code peuvent avoir un impact énorme sur votre sécurité.

Les chercheurs de Snyk avertissent que les développeurs doivent faire preuve de prudence avant d'utiliser node-ipc dans leurs applications, car il n'y a aucune garantie que les futures versions de cette bibliothèque ou de toute autre bibliothèque publiée par RIAEvangelist seront sûres. L'épinglage de vos dépendances à une version de confiance est l'un des moyens de protéger vos applications contre de telles attaques de la chaîne d'approvisionnement.

Sources : Snyk, discussions sur node-ipc (1, 2), les paquets npm maintenus par RIAEvangelist, le code malveillant

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des agissements du mainteneur du paquet npm node-ipc ? Est-ce bien ?
Même s'il s'agit de son œuvre, a-t-il le droit de saboter un paquet dont dépendent des milliers de projets ?
Selon vous, quels impacts ces sabotages pourraient avoir sur la communauté open source et les logiciels libres ?

Voir aussi

Un dev open source aurait volontairement corrompu des bibliothèques largement utilisées, affectant des tonnes de projets, il avait précédemment demandé à être rémunéré pour son travail

La bibliothèque npm populaire "coa" est détournée pour voler les mots de passe des utilisateurs, le paquet npm "rc" serait également compromis

Environ 26 % de toutes les menaces JavaScript malveillantes sont obfusquées, selon une étude d'Akamai

Les paquets npm malveillants font partie d'un "déferlement" de logiciels malveillants qui frappent les référentiels, la popularité des paquets en fait de parfaits vecteurs d'attaques

[kain_tn]

Que pensez-vous des agissements du mainteneur du paquet npm node-ipc ? Est-ce bien ?

Ce n'est pas "bien", non (enfin, la notion de bien est relative, mais son action ne colle pas avec mon éthique personnelle en tous cas)..

C'est un comportement de malware. C'est quoi l'étape suivante suivante? Chiffrer le disques des utilisateurs Russes et leur demander une rançon comme un vulgaire ransomware? Bon, le gars ne cherche pas non plus à faire des dégâts avec ses émojis mais ça reste du sabotage.

Une exagération absurde qui me vient comme ça à l'esprit est la suivante: si cette personne avait été chasseur de métier plutôt que développeur, elle aurait tiré sur le peuple Russe pour protester? Oui, c'est clairement exagéré, mais c'est ma façon de montrer que je considère son geste comme inutile et bête.

Même s'il s'agit de son œuvre, a-t-il le droit de saboter un paquet dont dépendent des milliers de projets ?

Oui, ça reste son droit le plus strict.

[sevyc64]

Bon, le gars ne cherche pas non plus à faire des dégâts avec ses émojis mais ça reste du sabotage.

heuuu, il est quand noté

le code réécrit le contenu de tous les fichiers présents sur un système avec un émoji de cœur, ce qui a pour effet de supprimer toutes les données sur un système

Il y a une différence entre supprimer un fichier et le modifier. Un fichier supprimé, est, dans certaines conditions et avec les bons outils, récupérable.

Un fichier modifié est, tout au moins son contenu initial, dans la plupart des cas définitivement perdu.
Donc il me semble que les dégâts sont bien réels et nettement plus important que lors d'une simple suppression.


Moi, ce qui m’interpelle c'est que cela fait des années, des décennies, que l'on nous serine que le monde du libre est plus sur car les contributions sont vérifiées, revérifiées, auditées par la communauté.
Qu'une telle chose puisse arriver montre bien finalement que ce monde n'est pas aussi sur que l'on veut bien nous le dire. Et étant ouvert, par définition, à énormément plus de contributeurs, il en est finalement bien plus exposé.

[frenchlover2]

les risque de l'open source quand tout le monde connait le code source , tu est une cible facile

[TotoParis]

Je ne peux que lancer un appel au BOYCOTT international de ce logiciel. Et du type en question. S'il l'a fait une fois, il recommencera dans la futur, selon son sentiment, ses émotions. Son comportement est inadmissible, d'autant que dans les pays visés, il y a plein de monde contre cette guerre d'Ukraine ! Faut vraiment avoir un pois-chiche à la place du cerveau pour agir ainsi.

[defZero]

Quel est votre avis sur le sujet ?

C'est son projet, son code et il le met gracieusement à disposition.
Partant de là personne n'à le droit de le critiquer et encore moins ceux qui en font un usage commerciale.
Le code est dispo, à charge aux utilisateurs de le vérifier.

Que pensez-vous des agissements du mainteneur du paquet npm node-ipc ? Est-ce bien ?

Ce n'est ni bien, ni mal, c'est son code il en fait bien ce qu'il veut.

Même s'il s'agit de son œuvre, a-t-il le droit de saboter un paquet dont dépendent des milliers de projets ?

Est-ce que parmi les milliers de projets qui dépendent de son code, aucun ne l'a validé avant intégration ou fait une relecture de code ?
Dans ce cas, la faute revient aux milliers de projets.
C'est comme faire un copier / coller d'un code sans vérification préalable, ce serait qui le fautif dans ce cas ?
L'auteur ou bien l'utilisateur ?

Selon vous, quels impacts ces sabotages pourraient avoir sur la communauté open source et les logiciels libres ?

Il faudrait que tout le monde dans l'IT réapprenne que l'on ne doit pas utiliser un code sans vérifications.
Ce qui était une pratique standard jusque dans les années 80/90 et qui visiblement a totalement était oublié.
L'open source et le logiciel libre devait faciliter cela, mais par "paresse" (intellectuel ou économique) plus personne ne le fait.

Alors oui, ça fait gagner du temps et ça évite d'avoir à tout comprendre dans les détails pour chaque brique, mais ça reste une mauvaise idée de réutiliser du code "trouvé" sur le net directement en prod.
Un dépôt, même officiel, ce n'est rien d'autre qu'une collection de projets qui sont mis, gracieusement ou pas, à disposition par leurs auteurs et c'est à votre charge de valider qu'il font bien ce que vous voulez, pas aux auteurs.

[daerlnaxe]

Ce n'est pas "bien", non (enfin, la notion de bien est relative, mais son action ne colle pas avec mon éthique personnelle en tous cas)..

C'est un comportement de malware. C'est quoi l'étape suivante suivante? Chiffrer le disques des utilisateurs Russes et leur demander une rançon comme un vulgaire ransomware? Bon, le gars ne cherche pas non plus à faire des dégâts avec ses émojis mais ça reste du sabotage.

Une exagération absurde qui me vient comme ça à l'esprit est la suivante: si cette personne avait été chasseur de métier plutôt que développeur, elle aurait tiré sur le peuple Russe pour protester? Oui, c'est clairement exagéré, mais c'est ma façon de montrer que je considère son geste comme inutile et bête.




Oui, ça reste son droit le plus strict.

Il ne cherche pas à faire du dégât... t'as tes documents importants, tes photos de famille, et tu te retrouves avec plus rien... Chez moi ça s'appelle faire du dégât et c'est une pourriture. Si on avait fait ça à l'encontre d'autres pays les gens hurleraient au racisme. J'ajoute que c'est du code qui va nous revenir tôt ou tard dans les gencives... Les gens sont complètement timbrés en ce moment.

Ce mec doit simplement être poursuivi et pourrir à l'ombre un moment, il entache très clairement la communauté de l'open source et du libre. C'est à cause de ce genre d'abrutis d'ailleurs qu'on se retrouve avec une évolution des machines, des certificats et j'en passe... Avec des machines qui tournent très bien encore qui deviennent obsolètes sur le plan software. Il faut regarder le crime par tous ses angles, ce type d'action est déjà criminel pour les gens qui sont impactés mais le cercle est élargi rapidement à cause des conséquences, et s'élargit encore quand ça amène du coup une obsolescence software pour répondre aux critères des nouveaux OS qui intègrent d'avantage de sécurité.

[Doksuri]

moi qui considerait l'open source comme le dernier lieu "encore sur"...

qu'on fasse passer un message une fois de temps en temps dans un commit ou un log, pourquoi pas... mais la ca va trop loin...

un petit "return false" a la 1ere ligne aurait suffit je pense

avant, je faisais les mises a jour de projets "open source" en aveugle... maintenant, je vais attendre quelques semaines pour m'assurer qu'il n'y a pas de retours negatifs

[daerlnaxe]

moi qui considerait l'open source comme le dernier lieu "encore sur"...

qu'on fasse passer un message une fois de temps en temps dans un commit ou un log, pourquoi pas... mais la ca va trop loin...

un petit "return false" a la 1ere ligne aurait suffit je pense

avant, je faisais les mises a jour de projets "open source" en aveugle... maintenant, je vais attendre quelques semaines pour m'assurer qu'il n'y a pas de retours negatifs

Je t'invite à regarder du côté des sandbox, tu peux avoir des gens qui font même de faux avis positifs tellement ça va loin de nos jours. Les gens n'ont vraiment plus de recul et mêlent trop de choses. Tu veux jouer les justiciers, tu fais hacker, il faut savoir séparer les choses dans la vie, en prime c'est vraiment la méthode la plus facile, gratuite et immonde, je ne peux pas cautionner. Je suis développeur amateur, je suis désolé mais il y a une éthique ce n'est pas parce que c'est MON code et que je mets gracieusement que je dois fracasser les données des gens, bien au contraire je porte une responsabilité sur ce qu'il advient des machines qui utilisent mon code si celui ci altère leur fonctionnement.

[walfrat]

Il faudrait que tout le monde dans l'IT réapprenne que l'on ne doit pas utiliser un code sans vérifications.
Ce qui était une pratique standard jusque dans les années 80/90 et qui visiblement a totalement était oublié.
L'open source et le logiciel libre devait faciliter cela, mais par "paresse" (intellectuel ou économique) plus personne ne le fait.

Comme si dans les annéees 80/90, tout les développeurs relisaient l'entièreté du code qu'ils intégraient.

En outre aujourd'hui la "pile" qu'on intègre est sans conteste 100 fois plus grosses qu'a l'époque. Je veux dire, tu veux intégrer Angular ? Il te faudra non seulement te palucher les quelques Mega de code pur Angular mais aussi le code de toutes les dépendances.

Aujourd'hui c'est simple : a part si tu veux avancer cent fois moins vite que le reste du monde, c'est impossible de valider l'entièreté du code que tu ajouterais comme dépendance. Tu as évidemment l'option de tout recoder toi-même, en moins bien, en admettant que ça finisse par marcher, et en plus cher.

En revanche je trouve ça un peu dommage côté outillage, détecter du code sciamment obfusqué en base 64 ne devrait plus être si compliqué que ça de nos jour.

Enfin j'ai beau être développeur, pour les experts du domaines, ce ne serait pas trop difficile de me pondre un code malveillant et que je ne vois rien, comme la plupart des développeurs.

[onilink_]

Moi, ce qui m’interpelle c'est que cela fait des années, des décennies, que l'on nous serine que le monde du libre est plus sur car les contributions sont vérifiées, revérifiées, auditées par la communauté.
Qu'une telle chose puisse arriver montre bien finalement que ce monde n'est pas aussi sur que l'on veut bien nous le dire. Et étant ouvert, par définition, à énormément plus de contributeurs, il en est finalement bien plus exposé.

Faut pas confondre npm et le monde libre.

[leguminator]

Je vois la communauté Open Source avec un état d'esprit, un peu comme les médecins avec leur maxime "d'abord ne pas nuire" : cette dernière pourrait très bien s'appliquer à l'Open Source, tout du moins de mon point de vue.
Si le type veut protester, eh bien qu'il retire son package ou en change la licence s'il le veut.
Mais introduire du code malveillant est pour moi la limite à ne pas franchir !

Enfin vouloir punir la totalité des Russes et Biélorusses alors que certains ne soutiennent pas la guerre (il y a eu des manifestations réprimandées me semble-t-il) ne résoudra malheureusement pas les choses, avec au contraire le risque de diffuser plus largement un sentiment d'animosité. Triste époque...

[BleAcheD]

Les Russes se font cancel et doivent supporter le Kremlin/Putin ET les occidentaux qui leur souhaite le pire. ça n'est pas du niveau de se prendre un bombardement / devoir quitter son pays mais je ne pense pas que ça soit très intelligent.
On arrête même de vendre un parfum "Rose de Russie" parce qu'il y a Russie dans le nom... c'est dire le niveau.

[kain_tn]

Il y a une différence entre supprimer un fichier et le modifier. Un fichier supprimé, est, dans certaines conditions et avec les bons outils, récupérable.

Un fichier modifié est, tout au moins son contenu initial, dans la plupart des cas définitivement perdu.
Donc il me semble que les dégâts sont bien réels et nettement plus important que lors d'une simple suppression.

Mais justement, en lisant l'article, j'en ai compris qu'il ajoute un seul fichier avec ses emotes après avoir supprimé les fichiers du bureau. Donc c'est récupérable en principe, contrairement à un ransomware. J'aurais peut-être dû préciser "considérables" (ou "irrécupérables") derrière le mot "dégâts" dans ma phrase.

Moi, ce qui m’interpelle c'est que cela fait des années, des décennies, que l'on nous serine que le monde du libre est plus sur car les contributions sont vérifiées, revérifiées, auditées par la communauté.
Qu'une telle chose puisse arriver montre bien finalement que ce monde n'est pas aussi sur que l'on veut bien nous le dire. Et étant ouvert, par définition, à énormément plus de contributeurs, il en est finalement bien plus exposé.

Bon, pour commencer, toutes les communautés open-source ne se valent pas. Ici, on est sur du développement web, avec beaucoup de script-kiddies. Tu trouves du très bon comme du pas très bon.

Il faudrait que tout le monde dans l'IT réapprenne que l'on ne doit pas utiliser un code sans vérifications.
Ce qui était une pratique standard jusque dans les années 80/90 et qui visiblement a totalement était oublié.
L'open source et le logiciel libre devait faciliter cela, mais par "paresse" (intellectuel ou économique) plus personne ne le fait.

Clairement, oui. C'est comme tous ces tutos qui poussent les gens à installer plein de dépôts tiers / PPA. C'est une mauvaise habitude.

Si on avait fait ça à l'encontre d'autres pays les gens hurleraient au racisme. J'ajoute que c'est du code qui va nous revenir tôt ou tard dans les gencives... Les gens sont complètement timbrés en ce moment.

Je ne peux qu'être d'accord avec toi sur tout ces points.

Je t'invite à regarder du côté des sandbox,

Tu as été plus rapide que moi

@Doksuri, pour ma part, j'utilise AppArmor, et j'ai des profils dédiés pour les logiciels dans lesquels je n'ai pas entièrement confiance, tels que les navigateurs web (du fait qu'ils lancent du code différent à chaque site visité). Avec ça tu peux par exemple empêcher un binaire ou un processus d'écrire/lire/modifier des fichiers même s'ils sont lancés avec un utilisateur qui a les droits de le faire globalement.

[Fagus]

C'est un peu comme l'histoire du 1er virus-ver par courriel. D'un seul coup, on se rend compte à quel point rien n'est sécurisé par conception, car "les gens qui utilisent ce système sont bienveillants".

ça veut dire qu'il va falloir mettre des antivirus sous linux avec un moteur comportemental pour les bombes logiques, des sandbox, des analyseurs plus poussés de code sur les serveurs.

Edit : Sous windows on peut plus ou moins se protéger de ce genre d’attaques avec la protection contre les ransomware (controlled folder access), qui bloque par défaut l'écriture des programmes non autorisés dans les dossiers utilisateurs protégés.
kain_tn me fait découvrir AppArmor sous linux supra : ça a l'air assez puissant mais peu pratique (pas de GUI) et nécessite de créer des profils : mais est-ce applicable par défaut à tout programme sans que ce soit ingérable ? est-ce applicable à un script ou un module d'un ensemble de scripts, ou bien est-ce que la règle s'applique à l'interpréteur de scripts (et donc à tous les scripts ?) ?

[kain_tn]

ça veut dire qu'il va falloir mettre des antivirus sous linux avec un moteur comportemental pour les bombes logiques, des sandbox, des analyseurs plus poussés de code sur les serveurs.

Pas tout à fait. Pour les sandbox et les analyseurs de code, oui, c'est de toutes les façons une bonne pratique, sauf que l'analyseur de code devrait se trouver dans ta chaîne de compilation, pas sur le serveur vers lequel ton code sera déployé.

Pour ce qui est des antivirus pour analyser le comportement d'un programme en boîte noire, tu peux aussi faire tourner ton programme sur un serveur de test et lancer un "strace -f" pour analyser ce que fait le dit programme. En gros, ça trace tous les appels système, donc tu peux réellement voir ce qui est fait par le programme et ses processus enfants. C'est laborieux, mais c'est encore une des meilleures solutions si tu veux savoir ce que fait un programme pour lequel tu n'as pas les sources.

D'ailleurs sous windows il y a une protection assez correcte contre ce genre d'attaques : si on active la protection contre les ransomware (controlled folder access), un programme avec les privilèges utilisateur1 n'a pas le droit par défaut de modifier les fichiers personnels de l'utilisateur1 dans "mes documents", etc. Par contre, un programme malveillant avec les privilèges utilisateur devrait modifier je pense les données des autres programmes de mêmes privilèges (contrairement à android).

Ça existe depuis deux décennies sous Linux et plus encore si tu prends en compte les sandbox types BSD jails.

Quelqu'un sait s'il y a un "controlled folder access" sous linux, (sans sandbox) ? (c'est à dire qu'un programme par défaut n'a pas le droit d'écrire dans les fichiers utilisateurs dans /home)

SELinux (même si je lui préfère du sandboxing) étend le système de permissions de Linux et permet ce genre de choses. Personnellement, je le trouve quand même compliqué et je lui préfère AppArmor, des chroot, des VMs, des conteneurs, etc.


EDIT:

kain_tn me fait découvrir AppArmor sous linux supra : ça a l'air assez puissant mais peu pratique (pas de GUI) et nécessite de créer des profils : mais est-ce applicable par défaut à tout programme sans que ce soit ingérable ?

Alors les programmes courants ont des profils existants par défaut dans les distributions, ce qui te permet d'éviter de les faire toi-même pour commencer. (par exemple docker a un profil AppArmor, actif par défaut d'ailleurs)

Tu as aussi plusieurs modes dont un mode d'audit qui te permet de générer des profils lorsque tu utilises un programme, pour bien évidemment ensuite le modifier pour en retirer les parties qui ne te plaisent pas.

Je ne connais malheureusement pas de GUI pour faire tout ça.

est-ce applicable à un script ou un module d'un ensemble de scripts, ou bien est-ce que la règle s'applique à l'interpréteur de scripts (et donc à tous les scripts ?) ?

En principe, les profils sont appliqués en fonction du chemin vers un binaire, mais il me semble que tu peux utiliser des wildcards pour que ça puisse correspondre à plusieurs binaires/processus à la fois.


Pour ma part, j'essaye d'être pragmatique car ça prend du temps de tout micro-gérer:

• Si le programme tiers ne fait pas partie de mes dépôts système, et qu'il n'a pas de GUI => conteneur (AppArmor appliqué, donc)
• Si le programme tiers ne fait pas partie des dépôts du système mais qu'il a une GUI, alors soit je lui crée un profil AppArmor, soit je le mets directement dans une VM
• Si le programme est un navigateur en lequel j'ai confiance => profil AppArmor (du fait de la possible exécution de code tiers, même si j'ai plusieurs plugins pour désactiver tout ça par défaut)
• Si le navigateur est quelque chose dont j'ai besoin mais dans lequel je n'ai pas confiance => VM

Évidemment, tout ça ne remplace pas les règles de base, que ce soit du serveur ou un poste client (plusieurs comptes, sudo sans timeout pour réauthentifier à chaque fois, éventuellement des clés FIDO, peu de dépôts tiers, des MAJ fréquentes, utilisation du matériel réseau pour cloisonner les zones, isolation de ports, sauvegardes régulières, etc.).

[kbadache]

C'est pour cela que j'utilise uniquement des librairies / framework open source qui viennent d'entreprise (Google avec Angular, Facebook React, VMWare Spring...).
Il y a beaucoup plus de chance que ça soit carré car elles mettent leurs nom en jeu.
Les lib open source fait par un mec le dimanche, c'est sympa de ça part, mais trop peu de garantie sur le code produit ou la durée de vie de la lib.
Et svp arrêtez d'utiliser des libs qui contiennent qu'une ligne de code !

[quanta]

L'hystérie occidentale est sans borne.

[homex]

Effectivement cette modification est assez préjudiciable

Je me pose juste une question concernant les personnes impactées.

Personnes ne fait de tests concernant les dépendances avant d'intégrer les dernières versions ?

Cela me semble un minimum de tester les nouvelles versions de dépendances sur des environnements dédiés avant de déployer sur les architectures critiques

[Madmac]

Oui, ça reste son droit le plus strict.

Là je ne suis pas d'accord. Parce que c'est comme conduire en état d'ébriété. Agir comme un terroriste, n'est pas un droit. C'est le genre de truc qui risque de créer une riposte. Et créer une forme d'escalade.