[Cyber: CanisterWorm] Hoax ou vraie menace ?

Bonjour les amis,

Depuis quelques jours, une onde de choc parcourt les réseaux spécialisés (LinkedIn, X, certains blogs de chercheurs) concernant une nouvelle menace baptisée « CanisterWorm ». J'ai creusé le sujet pour voir si nous devions paniquer sur nos environnements de dev.

La menace décrite (le scénario « catastrophe ») :

Le CanisterWorm est présenté comme un ver auto-propageable ciblant les écosystèmes JavaScript (npm) et Python (PyPI).

- Vecteur : Injection via des scripts postinstall dans des paquets compromis (on parle de scopes comme @emilgroup ou d'outils comme Trivy).
- Innovation : Il utiliserait la blockchain Internet Computer (ICP) comme infrastructure de commande (C2) décentralisée, rendant son démantèlement quasi impossible par les autorités (réponse HTTP 451).
- Action : Vol de secrets (.npmrc, clés AWS, SSH) et destruction de données (rm -rf /).

Rester prudent (L'homme qui a vu l'ours...)

Malgré la précision technique des rapports qui circulent sur LinkedIn, Twitter, etc., plusieurs zones d'ombre m'interpellent et devraient vous inciter à la retenue avant de relayer l'alerte partout :

1. L'absence de CVE : Une attaque de cette ampleur « mondiale » devrait déjà avoir ses numéros de vulnérabilités officiels. À ce jour : rien.
2. Le silence des géants : Cela fait 6 jours que la toile s'enflamme, mais aucun rapport détaillé n'est sorti chez Kaspersky, CrowdStrike ou Mandiant. Un tel silence sur une menace « blockchain-backed » est suspect.
3. Incohérences techniques : Le ver est décrit comme un « wiper » (effaceur) redoutable. Or, sur une machine Linux bien configurée (sans privilèges sudo par défaut), ses capacités de nuisance sont techniquement limitées au /home.

Ma conclusion de terrain

Vrai ver ou « hallucination collective » alimentée par des IA de génération de contenu ? La question reste ouverte.

Quoi qu'il en soit, cette alerte est un excellent rappel des fondamentaux de sécurité :
- Ne travaillez jamais en root : Si vous n'avez pas de sudo actif pour votre user, le ver reste enfermé.
- Utilisez des alias protecteurs : De mon côté, mon alias rm='trash-put -i'¹ suffit à rendre n'importe quel script de suppression inopérant (il demande confirmation et met en corbeille).
- Verrouillez vos dépendances : pnpm-lock.yaml ou poetry.lock sont vos meilleurs remparts.
____
¹ trash-put
Modifié par Niuxe (27 Mar 2026 - 00:00)

Salut,
"Or, sur une machine Linux bien configurée"
Une fois de plus, Linux montre sa robustesse.
Qu'entends-tu par " Si vous n'avez pas de sudo actif pour votre user, le ver reste enfermé".
Il faudrait se passer de la commande sudo ? L'éliminer de la machine ?
C'est vrai que cette commande est un peu une facilité, donc une faille potentielle.

Salut,

Bonne question. Quand je dis « si vous n'avez pas de sudo actif », je ne parle pas d'éliminer sudo de la machine, mais de ne pas donner à l'utilisateur la possibilité d'exécuter n'importe quelle commande en tant que root. Chez moi je dois explicitement changer de user :

su -

Le principe de sudoers
Le fichier /etc/sudoers détermine qui peut faire quoi avec sudo. Une configuration sécurisée typique ressemble à ça :

%sudo   ALL=(ALL:ALL) ALL

Cela signifie : les membres du groupe sudo peuvent exécuter des commandes en root, mais seulement après avoir saisi leur mot de passe.

Là où ça devient dangereux, c'est quand on configure :

monuser ALL=(ALL) NOPASSWD: ALL

Ou pire, quand on travaille directement en root (sudo -i ou su -).

Comment vérifier si l'utilisateur est dans le groupe sudo ?
Pour savoir si l'utilisateur a le droit d'utiliser sudo (avec mot de passe) :

groups

ou plus précisément :

id

Tu verras une ligne du genre :

uid=1000(tonuser) gid=1000(tonuser) groupes=1000(tonuser),27(sudo),...

Si sudo apparaît dans la liste, l'utilisateur peut exécuter des commandes en root après avoir saisi son mot de passe. C'est la configuration par défaut sur Ubuntu/Ubuntu-like ¹

Ne jamais éditer sudoers directement
Si un jour tu dois modifier les droits sudo, n'ouvre jamais /etc/sudoers avec vim, nano ou autre. La commande à utiliser est :

sudo visudo

ou

su - && visudo

Pourquoi visudo est obligatoire ?
visudo fait 3 choses importantes :
- Vérification syntaxique : avant d'enregistrer, il contrôle que ton fichier n'a pas d'erreur. Une ligne mal formée peut verrouiller définitivement l'accès sudo sur la machine.
- Verrouillage : il empêche deux modifications simultanées.
- Éditeur sécurisé : il utilise ton éditeur par défaut (nano, vim, etc.) mais avec ces garde-fous.

Si tu édites /etc/sudoers directement avec vim ou autres et que tu fais une erreur, tu peux te retrouver dans une situation où plus personne ne peut faire sudo/su (ni pour corriger le fichier !). Avec visudo, la sauvegarde est bloquée si la syntaxe est incorrecte.

____
¹ Personnellement, c'est une des raisons pourquoi, je vois Ubuntu/Ubuntu-like d'un mauvais oeil). Ceci dit, c'est un autre débat
Modifié par Niuxe (27 Mar 2026 - 12:32)

Merci pour ces infos, je ne m'étais jamais trop penché sur ces problèmes. J'avoue (honteusement, mais j'ai plus de 25 ans de Linux) que je travaille sous root quand j'ai besoin des droits admin. J'ai plusieurs distros à la maison. Une Ubuntu QX Studio pour la MAO, une Debian sur un desktop et une autre Debian sur un laptop. Parce que ce ne sont pas des machines de même puissance, j'ai adopté différentes distros adaptées.
J'avais bien remarqué que les distros différentes n'avaient pas toutes les mêmes comportements avec su/sudo, mais je ne m'en étais pas inquiété plus que ça.
Voilà 25 ans que certains de mes amis me narguent en disant "tu verras, un jour il y aura des virus sous Linux". Je n'ai toujours rien vu pour le moment, peut-être m'ont-ils oublié (les virus, pas les amis). Et il n'y a aucun antivirus sur mes machines.