S3 1 Tio
S3 1 Tio
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Atomic Arch : 1 600 paquets vérolés dans le dépôt AUR d’Arch Linux

Mon seignaur, il est l'AUR de se protéger

Atomic Arch : 1 600 paquets vérolés dans le dépôt AUR d’Arch Linux

Illustration : Flock

Une attaque non revendiquée a permis à des pirates d’infecter des centaines de paquets dans le dépôt AUR d’Arch Linux. La distribution n’est pas directement touchée, le dépôt étant consacré aux paquets gérés par la communauté. L’ampleur de l’attaque montre une nouvelle fois les limites d’un modèle de sécurité avant tout basé sur la confiance.

AUR, pour Arch User Repository, est un dépôt communautaire pour la distribution Arch Linux (et celles qui en dérivent). Comme indiqué sur le wiki d’Arch Linux, il « a été créé pour organiser et partager les nouveaux paquets de la communauté et pour aider à accélérer l’inclusion des paquets populaires dans le dépôt « extra » ». Il n’est donc pas géré par l’équipe de maintenance d’Arch Linux, n’est le plus souvent pas activé par défaut et contient un grand nombre de paquets (archives regroupant les fichiers nécessaires à un logiciel et les métadonnées associées) non présents dans la distribution.

Pratique, AUR est aussi un fourre-tout dans lequel la traçabilité est parfois très relative. C’est cet aspect qui a été exploité par les pirates.

L’attaque

Le 11 juin, les chercheurs de l’entreprise de sécurité Sonatype découvrent une campagne d’attaque coordonnée contre le dépôt AUR. Le ou les pirates ont pris le contrôle de paquets AUR dits « orphelins », c’est-à-dire abandonnés et en quête d’un repreneur. Ces paquets ont été modifiés : les fichiers de description des paquets (PKGBUILD) pointent vers un paquet npm malveillant à l’installation.

Dans son billet, Sonatype indique qu’une vingtaine de paquets modifiés ont ainsi été détectés. Un script post-installation a même été injecté pour appeler la commande « npm install atomic-lockfile ».

Entre les 11 et 12 juin, le nombre de paquets détectés comme malveillants s’envole, comme rapporté par le collectif de renseignement open source IFIN (Independent Federated Intelligence Network) et la communauté AUR. On passe ainsi de 20 à plus de 400 paquets, qui distribuent à la fois un rootkit assurant la persistance dans les machines infectées et un malware dédié au vol d’identifiants et de jetons d’accès (tokens d’authentification).

Il reste 80% 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 (21)

votre avatar
Le sous-titre... :copain:
votre avatar
J'en reviens pas qu'il n'ai pas fermé le dépôt directement.
votre avatar
Salut,

Oui, je suis bien d’accord. Combien de personnes se sont fait compromettre pendant l’intervalle où ils découvraient l’ampleur du problème ?

Et qu’on ne vienne pas me dire : "Il suffit de lire le PKGBUILD." Pour moi, cette phrase rejette la faute sur l’utilisateur final, alors que très peu de personnes ont vraiment les compétences pour détecter une backdoor intentionnelle.

C’est facile de lire un PKGBUILD qui fait un simple ./configure && make && make install (ou son équivalent CMake). En revanche, une backdoor intentionnelle à la XZ (via un simple .!) est bien plus ardue à repérer.

Prenez l’exemple des paquets CUDA (https://aur.archlinux.org/cgit/aur.git/tree/?h=cuda-12.8): il y a un patch diff, une fonction prepare avec des commandes find, sed, etc., un fichier de profile.d, des modifications des options de compilation via les fichiers *.pc...

Bref, il y a un problème avec le système de maintenance des paquets AUR. L’ignorer serait contre-productif. c'est plus facile a ecrire qu'à faire j'en suis bien conscient et j'ai pas la solution..

PS: Soyons bien content que l'attaque ait été massive et pas dilué dans le temps (avec des users/comitters différents pour chaque paquet). L'attaque aurait été beaucoup plus difficile a détecter..
votre avatar
Et qu’on ne vienne pas me dire : "Il suffit de lire le PKGBUILD." Pour moi, cette phrase rejette la faute sur l’utilisateur final, alors que très peu de personnes ont vraiment les compétences pour détecter une backdoor intentionnelle.
Dans la mesure où AUR n'est pas activé par défaut, m'est avis que les utilisateurs lambda ont peu de chances d'installer quelque chose par ce moyen sans mettre un peu trop les mains dedans.
votre avatar
Salut,
l'AUR est une force de la distribution Archlinux, je pense pas que tu puisses l'utiliser au quotidien sans y avoir recours.

et meme pour les utilisateurs "pas lambda", quel est le pourcentage d'entre eux expert en packaging/backdooring/malware?

As tu toutes les compétences pour affirmer à 100% qu'il n'y a rien de malicieux dans le paquet cuda cité? Moi pas en tout cas alors meme que je package et suis féru de cybersec...
votre avatar
Ma seule affirmation est qu'AUR n'est pas activé par défaut. En tous cas, pas chez Manjaro, et je doute que ce soit pareil sur Arch (que je ne vois pas entre les mains d'un utilisateur lambda).

La surface d'attaque reste donc réduite chez eux.

Cela n'enlève rien à la problématique de ce repository et ses risques.
votre avatar
AUR ne peut pas être "activé par défaut" sur Arch. C'est un dépôt de paquets sources pas de binaires.

D'ailleurs les outils dans les dépôts officiels ne permettent pas de builder automatiquement des paquets depuis AUR et c'est volontaire.

Le but est que l'utilisateur utilise AUR en étant conscient de ce qu'il fait et en comprenant les mécanismes.
votre avatar
Je ne pense pas qu'on puisse être néophyte quand on utilises Arch. Par contre, on peut très bien l'utiliser sans trop mettre les mains dedans. Les wikis sont suffisamment détaillés et simple pour te donner une marche à suivre générique. J'ai utilisé ArchLinux pendant 6 mois, y compris AUR. Et si j'ai parfois mis les mains dedans (en modifiant le PKGBUILD) pour construire des paquets un peu plus allégés. Je ne prétendrais pas pour autant avoir la maîtrise du sujet. Et à un certain niveau de complexité, j'aurais sans doute pas cherché plus loin. Et j'aurais plutôt fait confiance car j'aurais pensé que si il y avait eu quelque chose de suspect, quelqu'un de plus compétent s'en serait rendu compte.
Oui, la naïveté, tout ça.... Mais je partage l'idée que tout n'incombe pas à l'utilisateur. C'est pas comme si AUR était stocké sur un site tier.
votre avatar
C'est pourtant pas nouveau qu'on doive considérer tout dépôt AUR comme suspect.
Perso, je lis toujours le PKGBUILD et si je comprends pas (comme le paquet cuda que tu cites en exemple), bah j'installe pas.
Quand je vois certains utiliser des outils d'installation automatique basés sur l'AUR, ça me donne froid au dos... Faut limite être inconscient.

Honnêtement, je comprends pas pourquoi tout le monde semble s'exciter maintenant qu'une attaque d'ampleur a eu lieu. Ça a toujours été facilement possible et on l'a toujours su.
Après, tant mieux si ça mène à des mesures de sécurité supplémentaires mais faudrait pas que ça détruise l'esprit de l'AUR non plus.
votre avatar
salut,

le probleme est plus pernicieux, car l'attaque a abusée de la liberté de passer mainteneur d'un paquet devenu "orphelin" sans controle.

il ne s'agit pas seulement d'inspecter un paquet à son installation mais de l'ensemble de tes paquets AUR à chaque mise à jour, ca peut vite devinir tres compliqué!

PS: la commande pacman -Qm listera vos paquets non maintenu officiellement, vérifiez s'ils sont toujours nécessaires et supprimez les s'ils sont inutilisés pour réduire la surface d'attaque
votre avatar
il ne s'agit pas seulement d'inspecter un paquet à son installation mais de l'ensemble de tes paquets AUR à chaque mise à jour, ca peut vite devinir tres compliqué!
Il faut vérifier à chaque mise à jour ouais. Le plus souvent, y'a que le numéro de version qui change, ça se fait rapidement. Après, j'ai que 5 paquets AUR dont 1.5 que je maintiens moi-même donc je suis pas débordé :D

Merci pour le pacman -Qm, je viens de remarquer que j'avais un vieux lib32-openssl-1.1 maintenant inutile qui s'était fait rétrograder dans l'AUR. C'est supprimé !
votre avatar
Il me semble que le soucis de autour de la sécurité de Aur est une des raisons ayant justifié la création de chaotic Aur.

Or ils n'en disent pas grand chose à part avoir bloqué quelques update.
Quelqu'un en sait-il plus ?
votre avatar
ça devient quand même un peu cauchemardesque.
Pis, je subodore que les US vont maintenant s'en donner à coeur joie après avoir coupé Mythos à leurs "alliés"...
votre avatar
votre avatar
Je m'interroge sur la cible: arch, c'est pas vraiment la distribution de tout le monde, en général, on est des gros geek (oui, je suis un utilisateur Arch et oui, j'en suis à mon 4-5em script de vérification clean...), et je ne pense pas que cette distribution soit rependu en entreprise.
Les attaquants ne sont donc probablement pas un/des APT. D'un point de vu criminel, je pense que c'est beaucoup d'effort pour peu de résultat au final. Reste le défie technique: je pense que notre attaquant est soit en manque de reconnaissance, soit quelqu'un qui voulais "alerter" sur la faiblesse de AUR (je ne crois pas à cette dernière).
Par contre, une chose est sur: si il y'a bien une communauté à même de retrouver le/les responsables, c'est bien celle de Arch. C'est prendre beaucoup de risque de s'attaquer à cette population de cette manière...
votre avatar
Je trouve ça plutôt logique au contraire. Les utilisateurs d'Arch sont souvent des gens qui ont des connaissances étendues en informatique au sens large et qui ont du coup souvent un metier et/ou des hobbys en rapport avec le développement logiciel et l'administration systèmes.
A mon sens, ce sont des cibles de choix pour pouvoir pivoter vers des systèmes d'entreprises ou de diffusions de logiciels (libres entre autre).
votre avatar
Il faut être sacrément débile (et je pèse mes mots) pour utiliser AUR sur une machine professionnel ou utilisé pour le travail.
votre avatar
AUR reste un repository utile pour gérer certains logiciels non disponibles dans ceux de l'OS dont l'installation serait moins managée (AppImage, archive à télécharger, etc.). Par exemple l'interface Compass pour MongoDB, VSCode et son cousin communiste VSCodium que j'utilise à titre perso, Bruno, etc., tout ça c'est dans AUR.

Comme toujours, la sécurité IT est un ensemble de pratiques à cumuler pour réduire la surface d'attaque. Personnellement, je ne conçois plus la possibilité d'avoir une station de travail sans un pare feu comme Opensnitch ou équivalent qui permet de contrôler qui veut accéder à quoi.

C'est une véritable orgie pour chaque logiciel avec parfois la création d'une dizaine de règles juste pour un exécutable...

D'autres pratiques en vrac : regarder la page sur AUR du package avant de l'installer pour la première fois histoire de voir son sérieux dans le maintient, s'il est toujours maintenu, les commentaires, etc. Un peu comme un repo GitHub/GitLab où l'on évitera d'aller pull et lancer un truc plus mis à jour depuis 8 ans.
votre avatar
Reste à savoir si d'autres types de distributions (DEB ou RPM based) pourraient être compromises de la sorte ...

D'ailleurs, quid de SteamOS qui est une distribution Arch based ?
votre avatar
D'ailleurs, quid de SteamOS qui est une distribution Arch based ?
Pas de AUR activé sur SteamOS à ma connaissance, et c'est quasi que du flatpak dessus.

La distrib a un filesystem immutable, d'ailleurs, à l'exception de la home utilisateur.
votre avatar
Bingo ! Infected avec le paquet Flashfocus le 12 juin :plantage: