Connexion Premium

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

Mon seignaur, il 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 (6)

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?

Peux tu m'affirmer à 100% qu'il n'y a rien de malicieux dans le paquet cuda cité?
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 ?