Des paquets AUR compromis par un infostealer et un rootkit

 (discourse.ifin.network)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Le dépôt de paquets AUR est conçu de façon à ce que n’importe qui puisse adopter des paquets non maintenus et soumettre des modifications au PKGBUILD et aux fichiers associés, et dans cet incident, plus de 408 paquets semblent avoir été compromis
  • Un nouveau maintainer de paquets AUR a adopté des paquets en se faisant passer pour un maintainer de confiance, et d’autres maintainers AUR ont lancé des opérations pour supprimer les paquets infectés
  • Les premiers paquets infectés ont été modifiés pour exécuter npm via un script preinstall afin d’installer la charge malveillante atomic-lockfile
  • Par la suite, l’infection a installé le composant malveillant js-digest avec Bun, et NPM a supprimé ce paquet
  • La plupart des paquets sont rarement utilisés, mais l’ampleur de l’attaque est importante et il s’agit surtout d’une attaque de la supply chain incluant, en plus du vol d’informations, un rootkit eBPF

État de l’incident

  • Que s’est-il passé ?

    • Un nouveau maintainer de paquets AUR semble avoir adopté et compromis plus de 408 paquets en se faisant passer pour un maintainer de confiance
    • Après le signalement de la compromission, d’autres maintainers AUR ont entrepris de supprimer les paquets infectés
    • Au 2026-06-12T17:30:00Z, les maintainers AUR indiquent avoir supprimé tous les commits malveillants
    • Les maintainers AUR ont décidé d’appliquer des contrôles et des restrictions à certaines fonctionnalités, dont l’adoption de paquets
    • Arch Linux a publié l’avis Active AUR malicious packages incident

  • Dépendances malveillantes

    • L’attaque comprenait au moins deux dépendances malveillantes distinctes
    • Les premiers paquets touchés ont été modifiés pour utiliser npm dans un script preinstall afin d’installer la charge malveillante, le paquet atomic-lockfile
    • Le paquet premake-git contient un commit d’exemple de cette modification
    • Les infections ultérieures ont utilisé Bun pour installer le composant malveillant js-digest, et NPM a supprimé js-digest
    • Une analyse détaillée de l’attaque est disponible dans Preliminary analysis of AUR malware

Réponse et indicateurs de compromission

  • Mesures recommandées

    • Si vous n’utilisez pas Arch, vous n’êtes pas directement concerné par cette compromission des paquets AUR
    • Les utilisateurs d’Arch doivent examiner la liste des paquets affectés et vérifier leur système avec un script de détection d’exposition
    • Le aur_check.sh lié dans le texte d’origine est une ancienne version, et il faut suivre les indications du Gist correspondant pour la vérification la plus récente
    • Si des indicateurs de compromission sont découverts, le système doit être préservé pour permettre une investigation forensique appropriée
    • Si des paquets infectés sont trouvés, il faut suivre la procédure habituelle de réponse à incident, remplacer tous les identifiants et envisager une réinstallation d’Arch
    • En raison du risque de rootkit, la fiabilité du système ne peut plus être garantie
    • Tous les utilisateurs doivent prendre des mesures pour bloquer le trafic Tor sortant sur leur réseau

  • Indicateurs de compromission

    • Le SHA256 de l’exécutable Linux malveillant embarqué dans js-digest est 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • bpftool map list permet de détecter des maps eBPF suspectes
    • Les noms de map suspects incluent hidden_pids, hidden_names, hidden_inodes

  • Éléments complémentaires à vérifier

    • Ce ne sont pas les comptes des maintainers existants qui ont effectué les commits malveillants ; ce sont des maintainers connus qui ont été usurpés
    • La plupart des paquets sont rarement utilisés, mais l’étendue de l’infection, avec plus de 408 paquets, est importante
    • Une attaque de la supply chain combinant vol d’informations et rootkit eBPF reste un cas rare
    • La page Socket.dev de atomic-lockfile affiche 134 téléchargements pour ce paquet NPM malveillant
    • Le paquet NPM est maintenu par l’utilisateur herbsobering
    • En recherchant le nom d’utilisateur herbsobering sur GitHub, on trouve une image conteneur unique qui semble être un outil de reverse shell/proxy, herbsobering430
    • Le dépôt de paquets AUR permet à n’importe qui d’adopter un paquet lorsqu’il est marqué comme non maintenu, puis de soumettre des modifications au PKGBUILD et aux fichiers associés
    • Chercher automatiquement des paquets abandonnés pour les adopter n’est pas rare, et davantage de contexte est disponible dans ce fil Mastodon

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • Il faut accepter que l’AUR n’est qu’une collection de PKGBUILD créés par les utilisateurs
    Il faut absolument vérifier le source de chaque PKGBUILD installé depuis l’AUR, et les mises à jour ne font pas exception. C’est un principe débattu depuis plus de dix ans, et c’est aussi pour cela qu’il n’existe pas de helper AUR officiel comme yay
    Beaucoup se plaignent du côté élitiste d’Arch Linux, mais en pratique c’est une distribution destinée à des gens qui savent ce qu’ils font et qui ne veulent pas qu’on leur tienne la main à chaque étape. Cela veut aussi dire que si vous installez des paquets AUR au hasard et que vous cassez votre système ou vous le faites compromettre, c’est votre responsabilité
    En revanche, l’époque où n’importe qui peut reprendre un paquet AUR touche peut-être à sa fin. Rien que le coût de revenir en arrière sur les paquets affectés à chaque fois est trop élevé. Examiner toutes les demandes de reprise serait trop lourd comme alternative, sans garantie que cela aide à chaque fois

    • Si l’on doit vérifier le code source de chaque PKGBUILD installé depuis l’AUR, ne faut-il pas appliquer exactement la même règle aux extensions de navigateur, extensions VSCode, paquets NuGet, crates Cargo, paquets Python, paquets npm, etc. ?
      À moins de ne les exécuter que dans des endroits sans accès à Internet ou n’accédant qu’à des choses publiques ou sans importance, oui
      Peut-être pas pour l’AUR, mais d’autres écosystèmes peuvent au moins théoriquement être améliorés via un modèle de permissions ou du sandboxing. Les extensions de navigateur ont déjà cette possibilité, mais les utilisateurs « ordinaires » ne l’utilisent presque jamais
      Malheureusement, 99,99 % des gens ne peuvent pas tout auditer ou n’en ont pas le temps. Les options les plus sûres semblent être les paquets de distribution maintenus par des mainteneurs de confiance, ou des endroits comme l’App Store iOS avec des permissions et un certain niveau de revue
    • Je ne pense pas que ce soit une vraie solution. Le schéma habituel de ce type d’attaque consiste à cacher la charge utile quelque part dans les dépendances
      Ce cas est un peu particulier parce qu’il s’agit d’un npm install très grossier dans le PKGBUILD. À ce stade, presque tous les dépôts de paquets hors AUR ont désormais le même problème, et auditer manuellement toute la chaîne de dépendances n’est pas réaliste
      Bien sûr, je n’ai pas non plus de solution
    • Croire qu’une fraction significative des utilisateurs fait réellement cela est complètement déconnecté du réel
    • Je me demande à quel point le fait que l’AUR soit une collection de PKGBUILD créés par les utilisateurs est vraiment différent de l’écosystème PyPI, de npm ou de l’ensemble de Docker Hub
      Les gens désactivent SELinux, --privileged désactive seccomp et AppArmor, et il existe aussi des CVE d’évasion de sandbox
    • Le fait que n’importe qui puisse reprendre un paquet AUR n’aurait jamais dû exister
      Au final, j’aimerais qu’on arrive à une structure du type username/packagename-bin|git. Ce serait alors beaucoup plus clair pour les gens de savoir exactement quoi ils installent et de qui

  • Cette campagne est toujours en cours. Je viens de recevoir un mail indiquant qu’un de mes anciens paquets a été repris ; il ne fonctionnait plus depuis des années et était orphelin depuis un moment. Juste après la reprise, un commit malveillant a été poussé
    Il semble qu’ils utilisent maintenant bun au lieu de npm, donc les contournements basés sur npm risquent de ne plus fonctionner
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • À ce stade, je me demande si le concept même de reprise de paquet orphelin n’est pas cassé, et s’il ne faudrait pas simplement le supprimer
      Ce serait moins pratique, mais au lieu de permettre à quelqu’un de reprendre un paquet abandonné par un autre, il vaudrait peut-être mieux que l’AUR impose une nouvelle soumission, et supprime régulièrement les paquets orphelins après un certain délai
    • Je viens moi aussi de recevoir une alerte indiquant qu’un paquet AUR que je surveillais a été transféré à quelqu’un que je ne connais pas sous prétexte qu’il était orphelin

  • Il est évidemment normal d’être prudent quand on installe quelque chose depuis l’AUR, et il y a toujours eu par le passé des paquets douteux, c’est-à-dire mal construits ou mal empaquetés, mais voir une injection malveillante active est inquiétant
    À mes yeux, l’AUR a deux gros problèmes. D’abord, c’est un vestige d’une époque un peu plus égalitaire de l’open source, où l’on pouvait globalement faire confiance au code tiers. Ensuite, n’importe qui peut reprendre un paquet orphelin en conservant tout son historique et son parcours de vérification
    La première époque est déjà révolue, et le second problème peut être atténué par un contrôle plus strict des comptes AUR ou par des protections supplémentaires côté helpers AUR. Par exemple, afficher un énorme avertissement effrayant si le propriétaire a changé récemment. Certains appuieront quand même simplement sur y, mais c’est toujours mieux que rien
    On peut aussi éviter complètement les helpers AUR et examiner puis construire soi-même les paquets nécessaires à partir du PKGBUILD

    • La politique de reprise de paquets n’a jamais été raisonnable, à aucune époque
    • Au contraire, les helpers AUR facilitent l’intégration de l’étape de revue dans le flux de travail
      Ils vous demandent activement de vérifier, puis vous signalent aussi s’il y a eu des changements après la dernière acceptation du risque
      Cela dit, l’idée que « l’AUR est nocif » n’a rien de nouveau. Les gens qui utilisent l’AUR doivent comprendre les risques ici, et au fond ce n’est guère plus qu’un cran au-dessus de faire un curl | bash trouvé sur StackOverflow

  • Plus de 7 heures se sont écoulées, et pourtant il n’y a encore aucune mention sur archlinux.org ni aur.archlinux.org. Je ne comprends pas pourquoi. Il aurait fallu bloquer l’AUR jusqu’à ce qu’une mesure prouve que les utilisateurs sont au courant de ce qu’il s’est passé
    Par exemple, on pourrait légèrement modifier l’URL de l’API AUR pour pousser les utilisateurs de yay/yaourt à aller voir ce qui se passe. La nouvelle API devrait disposer d’une infrastructure pour informer l’utilisateur et vérifier qu’il a lu le message avant de continuer. C’est d’autant plus nécessaire qu’on n’est même pas sûr d’avoir trouvé tous les malwares
    Il devrait aussi exister une base de données des commits AUR retirés ou compromis, ainsi qu’un mécanisme d’alerte si un utilisateur a déjà installé l’un de ces paquets

    • Pour le meilleur comme pour le pire, cet avertissement est toujours présent sur l’AUR
      Il est dans le nom même, et la documentation du wiki indique clairement que l’AUR est un dépôt géré par les utilisateurs et qu’il ne faut pas lui faire aveuglément confiance
      C’est écrit noir sur blanc dans le grand encadré rouge juste au-dessus : https://wiki.archlinux.org/title/Arch_User_Repository
      Il y a beaucoup de choses que je n’installerais jamais depuis l’AUR, et je ne pense pas qu’envoyer tout cela sur la mailing list soit la meilleure solution
      Je n’ai rien contre l’idée d’avertir les utilisateurs qui ont installé des paquets malveillants, mais la faisabilité paraît faible. L’AUR n’a pas de suivi d’installation comme les outils commerciaux. Comment savoir qui a installé quels paquets ? L’AUR est fondamentalement plus proche d’un annuaire d’emplacements de paquets, et ne demande ni connexion ni informations d’authentification
      Donc l’avertissement doit venir d’outils que les utilisateurs peuvent exécuter s’ils y prêtent attention, et qui exigent justement cette attention. Par exemple : https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • Il ne faut pas faire ça. Ce n’est pas parce que certaines personnes ne prennent pas au sérieux les conseils de sécurité élémentaires qu’il faut casser le workflow de tout le monde
      Et au juste, comment une nouvelle API est-elle censée informer l’utilisateur et vérifier qu’il a lu le message ? Les paquets AUR ne sont que des dépôts git, et les mainteneurs Arch n’ont aucun contrôle sur ce que font ou non les helpers AUR
    • Je pense qu’un avis sur la page d’accueil de l’AUR serait approprié. Personnellement, je pense aussi qu’un court message sur la page d’accueil d’Arch avec un lien vers l’avis sur la page AUR serait utile
      Si l’on ne veut pas lister tous les paquets connus comme affectés, il faudrait au minimum recommander officiellement que toute personne utilisant des paquets AUR lise tous les fichiers de tous les paquets qu’elle utilise
    • L’avis est maintenant publié : https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Si l’on peut se fier aux chiffres de Socket.dev, l’impact semble heureusement assez limité
      C’est cohérent. Je connais certains paquets de la liste des paquets touchés : ils sont très anciens et leur projet amont n’est plus maintenu
      Je ne sais pas combien il y a eu de victimes au total, mais il est probable que l’équipe AUR ait les chiffres exacts. J’imagine qu’ils font de leur mieux pour traiter l’incident à hauteur de son impact

  • Ce genre d’incident était inévitable à terme, et il risque de se produire plus souvent si rien ne change. J’aime beaucoup le système PKGBUILD de l’AUR, et je m’en sers souvent aussi quand j’écris mes propres paquets
    Le problème le plus grave, et pourtant l’un des plus faciles à corriger, c’est que n’importe qui peut reprendre un paquet orphelin sans que l’utilisateur final n’en soit informé d’aucune manière
    Faire supprimer un paquet rapporte peu au regard de l’effort, donc la meilleure façon d’abandonner le contrôle consiste à le rendre orphelin. À mon avis, ce devrait être l’inverse. À minima, l’utilisateur devrait être clairement averti qu’un paquet est devenu orphelin
    Cette responsabilité relève peut-être davantage des helpers AUR comme paru ou yay, et j’aimerais qu’ils mettent en place ce type de changement

  • Il existe un script simple pour scanner les paquets compromis
    https://cscs.pastes.sh/aurvulntest20260611.sh
    Ce n’est pas mon script, mais il est facile à lire et à comprendre. Il ne faut jamais envoyer un script directement dans bash par un pipe

    • Il existe aussi une alternative plus rapide
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      Ce n’est jamais un mauvais moment pour apprendre comm(1)
    • Cela vérifie seulement si le paquet a été installé, pas si la version installée était infectée
      Donc si, comme moi, vous n’avez pas lancé yay -Syu depuis un bon moment, peut-être même depuis des mois, alors ça va sans doute, non ? …n’est-ce pas ?
      Bon sang, ne me forcez pas à réinstaller Arch. La dernière fois, ça m’a pris une semaine
      Mise à jour : archinstall est bien. J’ai tout restauré en une quinzaine de minutes
    • Rien ne garantit que cette liste soit complète
      Il faut toujours vérifier le PKGBUILD et les sources. L’AUR n’est pas vraiment quelque chose à qui faire confiance. En fait, il est presque plus surprenant qu’une compromission de ce type ne soit pas arrivée plus tôt
    • pacman prend en charge la locale pour les dates, donc chercher 9 Jun ne fonctionne que dans une locale anglaise ou une locale utilisant un format similaire
      Après l’avoir adapté à mon environnement, jd-gui est ressorti, mais en réalité j’avais installé jd-gui-bin environ deux heures avant la compromission. J’ai eu de la chance ce soir-là : par flemme d’attendre la compilation depuis les sources, j’avais choisi le paquet -bin

  • La communauté Arch publie rapidement des scripts et des outils.
    À l’heure actuelle, l’utilitaire intégré le plus récent pour vérifier si l’on est infecté est celui-ci :
    https://github.com/lenucksi/aur-malware-check
    De plus, la mailing list aur-request voit affluer de nombreuses demandes de suppression et d’orphelinage pour annuler les commits malveillants :
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Question de débutant : comme cela ne vient ni d’Arch ni d’une source officielle, comment savoir si c’est fiable ?
      Il y a beaucoup de choses difficiles à comprendre dans ce script, donc il n’est pas simple de juger s’il est sûr rien qu’en lisant le code.
      On en vient à attendre une réaction ou une solution du côté des développeurs officiels d’Arch.
    • J’aime bien le graphe des étoiles en bas du README du dépôt.
      Il transmet bien le sentiment d’urgence et l’importance liés à une attaque de malware de cette ampleur.

  • Je me souviens avoir installé Mednafen, un émulateur, sur Arch Linux il y a une dizaine d’années. Le programme ne se lançait pas, car il était lié à une bibliothèque absente de mon système.
    Il s’est avéré que le mainteneur avait compilé le logiciel sur son propre système, et qu’une bibliothèque présente sur cette machine avait été utilisée sans être indiquée dans les dépendances.
    C’était un paquet maintenu officiellement, et j’avais toujours pensé que ce genre de chose était construit sur des serveurs de build dédiés, pas par un bénévole quelconque ou sur un ordinateur personnel. Je ne sais pas si Arch compile encore de cette manière, mais cet épisode m’a suffisamment effrayé pour me faire changer de distribution.

    • Cela peut arriver même avec pkgctl build. Le cas typique est qu’un makedepends= fait remonter transitivement une bibliothèque partagée dans l’environnement de build, mais qu’elle manque dans depends=.
      Il y a bien un avertissement lorsqu’une dépendance .so est détectée, mais c’est au mainteneur de le voir et de corriger le problème.
      Du point de vue de la sûreté et de la sécurité, Arch Linux est l’un des moteurs du projet des builds reproductibles, et une grande partie du système d’exploitation peut être vérifiée indépendamment pour confirmer que ces binaires ont bien été construits à partir du code source. Le dispositif d’audit des paquets officiels est plus solide que celui de NixOS et à peu près au niveau de Debian :
      https://reproducible.archlinux.org/
      Mais tout cela n’a absolument rien à voir avec cet incident AUR.
    • Il existe des outils pour compiler et installer un paquet à partir d’une image propre afin de repérer ce genre de problème. pkgctl, par exemple.
      Un mainteneur devrait absolument utiliser ce type d’outil avant publication.
    • Jusqu’à une date relativement récente, cette façon de faire était courante. Debian aussi a longtemps fonctionné ainsi, et ne l’a totalement interdite qu’en 2019.

  • Quelle est la solution à ce problème ? Faut-il installer ce genre de paquets dans un conteneur Docker sans accès réseau ? Je ne pense pas qu’on puisse supposer que cela se limite à l’AUR.
    En 2026, il faut se méfier de toutes les sources logicielles. C’est encore plus vrai avec la généralisation du vibe coding, et les logiciels fermés sont des boîtes noires, donc un chaos encore pire que l’open source.

    • Les « app stores » non fiables, y compris l’AUR, Flatpak et autres, devraient être contenus dans un bac à sable. Au minimum, il faudrait une machine virtuelle, comme configuration par défaut ou comme option.
    • Je n’aime pas le dire, mais les gens de Qubes OS avaient raison. La solution consiste à isoler agressivement les applications dans des machines virtuelles.
      Si on s’y met sérieusement, quelqu’un sait à quel point l’autonomie de la batterie se dégrade ?
    • Il faut adopter SLSA.
    • Flatpak

  • D’autres informations arrivent.
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    J’ai déjà pensé à l’idée de créer un binaire canari qui, lorsqu’il est exécuté, se contente d’envoyer un e-mail ou d’afficher une notification, et de l’appeler npm.
    À ce stade, ne pas renommer le binaire npm est un risque majeur.