Connexion Premium

Arch Linux : encore du rififi dans le dépôt AUR, nouvelle vague de code malveillant

C'était mieux avant

Arch Linux : encore du rififi dans le dépôt AUR, nouvelle vague de code malveillant

Illustration : Flock

Pour la deuxième fois en deux mois, l’équipe de la distribution Arch Linux a dû intervenir dans le dépôt AUR (Arch User Repository). En cause, une nouvelle vague de prises de contrôle sur des paquets existants pour leur injecter du code malveillant.

La décision a été annoncée initialement le 30 juillet par le contributeur Robin Candau. Dans son message, il indiquait que la solution était temporaire, le temps qu’une solution soit trouvée.

Mais de quoi parle-t-on ? D’une désactivation de la fonction d’adoption, pour empêcher toute personne « d’adopter » un paquet plus ou moins abandonné du dépôt AUR pour contribuer à nouveau à son code. Ce processus avait été détourné en juin et avait abouti à l’insertion de code malveillant dans plus de 1 600 paquets du dépôt AUR.

Une ampleur moindre, un danger identique

Le gros problème dans la campagne malveillante de juin était le nombre élevé de paquets concernés. Même avec des actions rapides, il était impossible de s’assurer que personne n’avait reçu les versions contaminées via des mises à jour. Ce qui était tout l’intérêt pour les pirates et qui rend les attaques par compromission de la chaine d’approvisionnement aussi efficaces.

Dans la nouvelle attaque, comme relevé notamment par Bleeping Computer, l’ampleur semble nettement moindre, mais on ne connait pas encore le nombre exact de paquets compromis. Sur les listes officielles, on trouve des listes compilant une trentaine de paquets compromis, tandis que d’autres sur Reddit évoquent plus de 200 paquets.

Si l’on en croit l’analyse technique publiée par l’Independent Federated Intelligence Network (IFIN), la campagne a débuté le 29 juillet avec le paquet « openconnect-sso ». Les similitudes avec la campagne de juin sont évidentes, dont l’usage du réseau Tor pour l’hébergement de l’infrastructure ou l’emploi d’un fichier ELF précompilé et obscurci.

Il reste 58% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (17)

votre avatar
notamment des logiciels très récents, d’autres propriétaires (comme Chrome et Discord),
Discord est dans extra pour info :chinois: (sur Manjaro)


Name : discord
Version : 1:1.0.150-1
Description : All-in-one voice and text chat for gamers
URL : https://discord.com
Licences : LicenseRef-custom
Repository : extra


Par contre VSCodium, Bruno, MongoDB Compass, etc., sont dans AUR en ce qui me concerne.
votre avatar
Mince, je suis allé un peu vite en besogne, c'est corrigé merci :)
votre avatar
Discord est d'un chiantisme absolu sur sa version Linux contrairement à sous Android, il t'envoie paître si tu n'as pas fait la dernière mise à jour, hors il y a souvent un décalage entre le dépôt et la sortie effective.
Il n'est pas rare de se retrouver avec la proposition de télécharger un paquet deb de mise à jour et l'impossibilité que le client ne démarre tant que la mise à jour n'est pas faite.
votre avatar
Oui, chaque semaine il y avait une journée où il n'était plus à jour et ne démarrait plus.

Cela dit, je n'ai pas eu ça depuis un bail, seulement les mises à jour "flèche verte en haut à droite". Ils n'ont pas du en pousser une qui exige une mise à jour du soft installé depuis je suppose.
votre avatar
Salut.

J'ai souvent eu le soucis et effectivement beaucoup moins récemment. Mais quand ça se produisait, il suffisait d'ouvrir ce fichier : /opt/discord/resources/build_info.json, incrémenter le numéro de version dedans, et voilà discord démarrait et téléchargeait tout seul ses mises à jour. :D

Mais je vois que je n'ai plus de /opt/discord, peut-être qu'ils ont modifié, et donc fixé définitivement ce souci !
votre avatar
En regardant, le paquet ne déploie plus que /usr/bin/discord qui est un shell installant l'appli dans ~/.config, avec en complément les fichiers Desktop. C'est tout ce que contient l'archive publiée par Discord. Ça explique ce fonctionnement plus fluide comme sur les autres OS.
votre avatar
BTW
votre avatar
En outre, il est de la responsabilité de chaque utilisateur d’inspecter les fichiers PKGBUILD avant de s’en servir.
Tout à fait. Installer à l'aveugle un truc venant de l'AUR, ça revient à exécuter une commande inconnue en root. Pas vraiment conseillé...
votre avatar
Un peu comme les installations d'application qui mettent en avant un one-liner du style
curl https://url_du_script_d'install.sh | bash

Bien sûr sans fournir ne serait-ce qu'un checksum pour vérifier si le fichier est bon.
votre avatar
Et encore, Tu n'es pas prêt avec la version encore pire : demandes à ton agent IA de faire l'installation (merci Bortzmeyer via Mastodon pour cette pépite : github.com GitHub
votre avatar
Encore faut-il être capable de comprendre le contenu du fichier PKGBUILD !
Le commun du mortel veut juste installer un logiciel dont il a besoin sans se poser des questions.
votre avatar
Oui mais C'est pour ça que les antivirus existent ☺️😅
votre avatar
Vu que AUR n'est pas activé par défaut (sauf une distrib de ce que j'ai vu dans l'article), ça ne sera pas la source préférée de l'utilisateur lambda.

Activer AUR demande une action positive et, il me semble de mémoire, que le gestionnaire d'applications alerte qu'il ne garantie pas la sécurité des paquets par sa nature communautaire.

L'utilisateur lambda aura donc plus tendance à installer un flatpak (qui se confond aussi via le gestionnaire d'applis du DE), voire un AppImage téléchargé, que d'activer AUR pour installer un paquet. C'est rarement l'option affichée dans les pages "Install" des outils.
votre avatar
Mieux : le gestionnaire de paquet par défaut (pacman) ne gère pas le dépôt AUR.
Il ne gère que le paquet une fois qu'il a été construit (via le fichier PKGBUILD et makepkg).
votre avatar
Oui, en effet, c'est pamac qui le gère en CLI.

Quand je parlais du gestionnaire d'applis, c'était celui de l'environnement de bureau qui gère de manière transparence les différentes sources d'install.
votre avatar
Le commun du mortel veut juste installer un logiciel dont il a besoin sans se poser des questions.
Si c'est leur but, ils se sont trompés en installant Arch :transpi:
Ou, s'ils utilisent un de ses dérivés, en s'approchant de l'AUR.
votre avatar
Manjaro est plus simple d'accès (ou CachyOS pour les gamer).
Et je suis d'accord avec vous que l'AUR n'est pas activé par défaut.