Arch Linux estime désormais l’incident de malware sous contrôle : plus de 1 500 paquets affectés

• Dans le dépôt AUR de contributions des utilisateurs d’Arch Linux, le nombre de paquets infectés par un malware, d’abord confirmé à plus de 400, est finalement monté à plus de 1 500
• Une mise à jour publiée il y a quelques heures estimait qu’environ 900 paquets avaient été infectés lors de l’incident de cette semaine
• Depuis, les développeurs d’Arch Linux ont supprimé tous les commits malveillants identifiés, et le nombre de paquets affectés a été comptabilisé à 1 579
• La liste des 1 579 est elle aussi présentée comme une liste importante mais non exhaustive des paquets affectés, ce qui laisse penser que l’ampleur réelle pourrait être plus grande
• De nombreux logiciels du dépôt maintenu par les utilisateurs ont été touchés par cet incident de sécurité, et une mise à jour séparée fait état d’une nouvelle vague d’attaques par malware plus sophistiquées

---

Aperçu de l’incident

• L’incident a commencé avec la découverte de plus de 400 paquets infectés par un malware dans le dépôt AUR de contributions des utilisateurs destiné aux utilisateurs d’Arch Linux
• À la fin de la journée, Arch Linux estimait que tous les commits affectés avaient été traités, mais le nombre de paquets touchés est monté à plus de 1 500
• Cet incident constituait un incident de sécurité ayant affecté de nombreux logiciels du dépôt Arch Linux maintenu par les utilisateurs

Évolution de l’ampleur

• Une mise à jour publiée quelques heures plus tôt indiquait qu’environ 900 paquets avaient été infectés par le malware lors de l’incident de cette semaine
• Ensuite, selon le dernier message du fil consacré à l’incident de sécurité, les développeurs d’Arch Linux ont supprimé tous les commits malveillants identifiés
• La liste citée indique 1 579 paquets affectés par le malware

Incertitudes restantes

• La liste affichant 1 579 paquets est elle aussi présentée comme « une liste importante mais non exhaustive des paquets affectés »
• Les chiffres publiés montrent donc une ampleur confirmée déjà considérable, mais la liste elle-même ne couvre pas nécessairement l’ensemble des paquets

Mises à jour ultérieures

• Une mise à jour séparée indique qu’Arch Linux AUR a subi une autre vague d’attaques par malware devenue plus sophistiquée

[GN⁺]

Avis sur Hacker News

• Je me demande si l’équipe AUR a déjà publié une analyse post-mortem
  La réponse a été impressionnamment rapide cette fois, mais honnêtement il semble nécessaire de faire évoluer soit la politique d’AUR, soit les wrappers
  Il devrait être possible de définir un âge minimal des paquets comme avec pnpm, et n’importe qui ne devrait pas pouvoir adopter des paquets orphelins
  On pourrait aussi imposer une limitation globale du rythme des adoptions pour s’en servir comme signal d’attaque, et il faudrait également un scan de vulnérabilités au moment de la publication, comme le font plusieurs entreprises sur NPM
  Cela dit, la plupart de ces changements relèvent davantage des assistants de packaging et de tiers que des mainteneurs AUR eux-mêmes

  • Il vaudrait mieux répartir les paquets AUR par espaces de noms
    Ainsi, la propriété ne disparaîtrait pas et il n’y aurait plus besoin de mise en orphelin
  • Il n’existe pas d’outil officiel pour télécharger le dépôt AUR, donc sur ce point chacun dépend de sa propre méthode
  • En m’inspirant de pnpm, j’ai récemment créé pour pakku un patch ajoutant un âge minimal AUR [1]
    [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
    [2] https://github.com/zqqw/pakku
  • Si on bloque trop l’adoption des paquets orphelins, certains qui pourraient être correctement maintenus risquent aussi d’être abandonnés
    Des limites sont nécessaires, mais quelque chose comme 1 adoption par mois pour les utilisateurs inscrits avant une certaine date semblerait raisonnable
    De toute façon, personne n’applique de mises à jour automatiques et non vérifiées aux paquets AUR installés localement, donc la surface d’attaque est déjà assez réduite
  • Un simple scan de vulnérabilités n’aurait probablement pas suffi à l’arrêter
    Le cœur du ver miasma, c’est justement que les signatures et les méthodes des assistants changent beaucoup trop vite
    L’implant malveillant chiffré déchiffre sa charge utile avec une clé AES-128-GCM différente selon l’emplacement GitHub où elle est uploadée, les noms de méthodes du code changent aussi dynamiquement, et des offsets de symboles chiffrés sont réutilisés après mélange
    C’est un malware polymorphe, donc un cauchemar pour les outils fondés sur des signatures
    APT28/29 semble dépendre en partie du fait que Microsoft bloque trop lentement les utilisateurs et dépôts GitHub utilisés comme infrastructure C2
    Il faut réfléchir à ce que cela implique pour la stratégie de sécurité
    Quand on peut enfin scanner des signatures ou des chaînes, on en est déjà au stade d’un jeu du chat et de la souris contre un botnet entièrement automatisé, et c’est perdu d’avance
    La semaine dernière, socket.dev a été à peu près le seul outil de supply chain à suivre l’évolution de cet implant ; les autres outils ont redécouvert Miasma comme s’il s’agissait d’une nouvelle campagne sans même savoir ce que c’était
    Il manquait les effectifs et la toolchain nécessaires pour rétroconcevoir la charge utile assez vite afin de suivre le rythme de nouveaux adaptateurs d’écosystème qui sortaient toutes les 24 heures
    Ici, “entièrement automatisé” signifie que des identifiants volés étaient déjà utilisés dans d’autres écosystèmes de paquets en moins de 48 heures
    Des adresses e-mail et des noms reviennent sans cesse, et ils semblent appartenir à des personnes qui n’ont probablement pas compris l’impact de ce ver auto-propageant
    Par exemple, rechercher comme indicateur de compromission des paquets dépendant de bun n’aide pas beaucoup
    Le malware n’a qu’à se retélécharger par un moyen externe
    Lors de la deuxième campagne PyPI, après que la première vague de droppers malveillants de la campagne RedHat a été signalée aux mainteneurs PyPI, le mécanisme a changé pour télécharger le dropper via des fichiers WHL compressés et un fichier setup.pth exécuté automatiquement
    Tant que les gestionnaires de paquets de ces écosystèmes ne seront pas réécrits de zéro en partant du principe d’un chroot, d’un sandboxing, de journaux réseau et de domaines, et de listes d’autorisation par élément, les stratégies de diffusion de malware via des attaques de supply chain resteront viables
    Le dépôt des outils de mitigation est [1], et les détails techniques figurent dans le billet de blog [2]
    Composer, Rubygems, NPM, PyPI et Go sont également touchés : c’est un problème transversal à tous les gestionnaires de paquets
    Il faudrait discuter bien plus ouvertement du niveau de négligence et de confiance externe empilé sur l’ensemble des gestionnaires de paquets, car cela doit vraiment changer
    [1] https://github.com/cookiengineer/antimiasma
    [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

• Quand les wrappers pacman installables directement depuis AUR ont commencé à apparaître, ça m’a vraiment mis mal à l’aise
  Il m’est arrivé d’installer des choses depuis AUR, mais la plupart du temps je préfère sauter l’étape intermédiaire et aller directement sur le site du projet
  Un PKGBUILD préfabriqué n’est pas assez pratique pour justifier le risque de typosquatting ou d’abus des dépendances npm·pip

  • Des wrappers comme yay affichent les différences du PKGBUILD à chaque mise à jour
    Lors de la première installation, on peut vérifier l’URL, voir si le script d’installation semble raisonnable, puis lors des mises à jour suivantes, seuls le numéro de version et la somme de contrôle changent en général
    Une attaque de typosquatting serait assez évidente
    La première installation est un peu vulnérable, mais cliquer sur “download” sur le site du projet ne vaut pas beaucoup mieux
  • Arch est souvent critiqué comme élitiste ou hostile aux utilisateurs ordinaires, mais il y a clairement un avantage à ne pas rendre les choses dangereuses faciles à faire
    C’est vrai dans bien d’autres aspects de la vie
    Après être passé sur Void Linux, j’ai aussi adopté aurutils sur Arch pour obtenir une séparation similaire
    On peut compiler soi-même, maintenir facilement un dépôt AUR local, puis installer et gérer le tout avec pacman, ce qui améliore l’ensemble du processus de mise à niveau
  • Ce compromis n’a aucune valeur pour moi
    Si je suis passé à Linux, ce n’était pas pour perdre du temps comme un utilisateur Windows à aller sur des sites web et cliquer sur “download” pour mettre à jour des programmes
    Cela dit, les wrappers pacman mentionnés paraissent risqués
  • AUR et les dépôts similaires d’autres distributions me font vraiment peur
    Les tutoriels qui utilisent ces dépôts sont tellement répandus qu’on finit presque par avoir l’impression d’être bizarre si on ne veut pas donner indéfiniment des droits root à un inconnu, sans presque aucune revue par les pairs
    Tout ça pour installer une version d’un paquet qui n’a pas besoin de mises à jour, ou très rarement

• À première vue, il semble qu’ils aient installé atomic-lockfile, js-digest et lockfile-js depuis npm
  La liste des paquets affectés se trouve en [1]
  Comme je n’ai pas tout de suite trouvé comment vérifier le système, j’ai lancé pacman -Qmi pour chercher des informations sur les paquets externes et les dates
  Il suffit ensuite de comparer la sortie avec la liste des paquets affectés
  On peut aussi rechercher des fichiers comme ceci à plusieurs endroits
  grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
  Je ne sais pas si le paquet se supprime lui-même après exécution
  Les autres informations n’aidaient pas beaucoup, donc je voulais au moins partager les commandes de base
  [1] https://md.archlinux.org/s/SxbqukK6IA

  • Voilà comment j’ai procédé
    J’ai obtenu avec yay la liste des paquets installés venant de l’AUR : yay -Qam > packages_aur.last
    J’ai récupéré la liste depuis https://md.archlinux.org/s/SxbqukK6IA# : curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
    Ensuite, en lançant grep -wFf compromised.txt packages_aur.last, on devrait obtenir les paquets présents dans les deux fichiers, donc ceux qui ont été compromis à un moment donné
  • L’attaquant a utilisé au moins trois dépendances Node, donc vérifier uniquement atomic-lockfile ne suffit pas
    js-digest et lockfile-js ont aussi été utilisés, et à un moment ils sont passés de npm à bun
  • Ceci peut aussi être utile : https://github.com/lenucksi/aur-malware-check
  • Ce qui est amusant, c’est que même dans une tentative d’injecter un malware dans l’AUR d’Arch Linux, le malware est quand même distribué via NPM
    Une plateforme légendaire
  • Je ne comprends pas comment emacs-magit a pu être affecté
    À ma connaissance, il n’y a pas du tout de JavaScript

• C’est, comme toujours, un rappel tout à fait juste qu’il ne faut pas installer sans vérification des paquets, bibliothèques ou applications tierces au hasard
  Heureusement, cette fois l’incident était limité à l’AUR, qui est en pratique un dépôt de paquets où presque tout le monde peut publier, et il a été rappelé à de nombreuses reprises que, contrairement aux dépôts officiels, une vérification avant installation y est indispensable
  Des outils en ligne de commande comme rua facilitent l’examen des paquets avant installation depuis l’AUR
  Si vous faites des opérations bancaires sur cette même machine, vous n’avez aucune excuse pour ne pas vérifier les logiciels dont vous dépendez
  Garder peu de paquets et n’utiliser que le nécessaire rend aussi les mises à jour bien plus simples

  • Comment est-on censé faire cette “vérification”
    Cela veut dire lire chaque ligne de code avant d’installer
    Et s’il s’agit d’un paquet binaire
    Faut-il produire des builds reproductibles pour tout ce qu’on installe, ou migrer vers une distribution basée sur les sources
    Rejeter cette responsabilité sur l’utilisateur n’est pas une solution durable
    Il y a une place pour le bon sens, mais faire porter la faute à l’utilisateur n’a aucun sens
  • Ça semble raisonnable, mais au final c’est un conseil impossible à appliquer, donc au-delà d’être inutile, c’est nuisible
    Il existe bien plus de code dans le monde qu’une personne ne pourra en lire durant toute sa vie
    Il est très probable que vous n’ayez pas lu ne serait-ce que 1 % du code source actuellement exécuté sur votre machine
    Avez-vous arrêté d’utiliser un ordinateur pour autant
    Comment pouvez-vous faire confiance à ce qui s’y passe
  • Je pense qu’il faut réévaluer la position consistant à dire “il faut absolument tout vérifier avant installation”
    Les développeurs d’Arch Linux font un excellent travail et je leur en suis personnellement reconnaissant, mais aujourd’hui, avec la multiplication des attaques de la chaîne d’approvisionnement, j’ai le sentiment que les avertissements aux utilisateurs ont atteint leurs limites depuis longtemps
    Je ne vois pas de solution simple, mais des mécanismes de contrôle comme une revue par les pairs avant publication ou une période de latence pourraient atténuer le problème dans une certaine mesure
  • L’AUR est depuis longtemps considéré comme l’un des grands atouts d’Arch, mais cette commodité a toujours eu un prix
    Le fait qu’il suffise de marquer un paquet comme abandonné, d’attendre deux semaines, puis, si le mainteneur d’origine est en vacances et ne peut pas répondre, qu’un attaquant puisse être désigné comme mainteneur et diffuser une mise à jour malveillante, c’est aberrant
  • Je pense que c’est un bon argument en faveur d’une combinaison de fichiers système immuables, d’installations locales utilisateur par défaut, et d’un minimum de privilèges accordés aux composants et aux programmes
    Les distributions immuables, Wayland et Flatpak apportent déjà une partie des briques, mais il reste des failles importantes
    Le plus gros problème, c’est que le sandboxing est lié au format de paquet, et je pense que c’est une erreur
    Le sandboxing et les permissions d’accès devraient être des fonctionnalités au niveau du système, afin que même des binaires arbitraires ne puissent pas facilement s’échapper
    Cela ne résoudra pas complètement le problème, mais cela peut fortement réduire l’ampleur des dégâts et rendre les utilisateurs de la distribution moins attractifs comme cibles

• Pour les personnes inquiètes, j’ai trouvé un dépôt qui rassemble les derniers scripts et la liste des paquets pour aider à vérifier s’il y a eu infection : https://github.com/lenucksi/aur-malware-check

  • J’ai aussi donné la même liste (https://md.archlinux.org/s/SxbqukK6IA) à Claude pour faire une vérification de malware, et il a effectué en substance les mêmes vérifications que ce script
    L’un comme l’autre devrait suffire

• Je n’utilise pas Arch Linux, mais j’utilise beaucoup NodeJS, et on voit aussi souvent ce genre d’attaques là-bas.
  Je me demande ces temps-ci où l’on fait encore une gestion des paquets correcte et sûre.

  • AUR repose sur les contributions des utilisateurs, donc des malwares se retrouvent parfois mêlés aux paquets.
    Ce n’était pas d’une telle ampleur cette fois-ci, mais il était clair dès le départ que ce n’était pas sûr, et il y avait des avertissements de risque un peu partout.
  • Les distributions Linux font bien le travail.
    Elles ont toutes des mainteneurs qui examinent les paquets et en assument la responsabilité.
    C’est aussi le cas d’Arch Linux.
    Le caractère fondamentalement non fiable d’AUR a toujours été explicitement indiqué dans l’Arch Wiki et dans la culture qui l’entoure, et c’est différent des gestionnaires de paquets de langages de programmation comme npm ou pip.
  • Si on n’utilise pas AUR, Arch est correct.
    Si on utilise AUR, il faut tout vérifier.
    La plupart des distributions sont aussi correctes, et les grandes distributions ont un historique plutôt bon.
  • Il semble y avoir quelque chose dans l’écosystème Node qui le rend particulièrement vulnérable.
    C’est peut-être à cause d’une culture DRY excessive, ou pour une autre raison.
    Parmi tout ce que j’ai utilisé, je n’ai rien vu d’aussi cauchemardesque en matière d’arbre de dépendances.

• Il y a 15 000 paquets orphelins sur AUR.
  Ce matin, j’en ai trié par popularité et j’en ai adopté puis compilé trois qui étaient à peine mis à jour.
  Si vous utilisez des paquets orphelins, cela peut valoir la peine d’envisager de les adopter vous-même avant que des gens mal intentionnés ne le fassent.

• Je me trompe peut-être, mais la situation actuelle ressemble à un signe de hausse de l’adoption de Linux sur le desktop.

• Je n’ai jamais eu besoin d’AUR.
  Si j’ai besoin d’un paquet qui n’est pas dans les dépôts officiels, je le compile moi-même ou, s’il existe une version binaire, je la télécharge.
  De cette façon, il n’est pas nécessaire d’utiliser root pendant la compilation, et on peut installer le programme localement pour un seul utilisateur, ce qui convient même mieux à la plupart des usages desktop.
  Au minimum, cela supprime une étape de possibilité d’injection de code malveillant par rapport au chemin développeur → utilisateur, en passant à développeur → mainteneur → utilisateur.

  • makepkg refuse activement de s’exécuter en root.
    À moins de le contourner délibérément avec quelque chose comme env EUID=123 makepkg ..., il ne tournera pas en root.
    Cela dit, ce serait bien que pacman prenne en charge les installations au niveau utilisateur.
    Actuellement, il refuse d’installer sans root, même s’il est possible de contourner cela en utilisant un espace de noms utilisateur pour se mapper soi-même sur root.

• Je comprends que, cette fois, il s’agissait d’AUR.
  Indépendamment d’AUR ou non, ce serait bien que vous partagiez les étapes que vous suivez quand vous installez un paquet, ainsi que la manière dont vous garantissez que le paquet et ses dépendances ne contiennent pas de malware.
  Une fois qu’un mauvais paquet est installé, cela semble vraiment très difficile à annuler.