1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Une attaque de la chaîne d’approvisionnement a visé l’AUR (Arch User Repository) avec l’insertion de nombreux commits malveillants, modifiés pour exécuter npm install atomic-lockfile pendant l’installation des paquets
  • Une recherche dans un miroir en lecture seule a confirmé la même commande malveillante dans les fichiers PKGBUILD, .install et .hook d’environ 408 paquets
  • Les commits malveillants utilisent une méthode de falsification de commit qui usurpe le nom et l’e-mail du commit précédent pour se faire passer pour le mainteneur légitime, indépendamment d’un éventuel piratage de compte
  • Côté Arch, des opérations de réinitialisation/suppression des commits malveillants et de blocage des comptes sont en cours, avec demande de signaler tout paquet malveillant supplémentaire dans un seul et même fil
  • Des membres de la communauté signalent successivement les commits de paquets concernés, dans le cadre d’une réponse collaborative à un incident majeur affectant l’ensemble de l’écosystème des paquets AUR

Vue d’ensemble de l’incident et appel à réaction

  • Des indices d’une insertion massive de commits malveillants dans l’AUR ont été partagés, et les opérations de réinitialisation/suppression des commits malveillants ainsi que de blocage des comptes sont en cours
  • En cas de découverte d’autres paquets malveillants, il est demandé de les signaler en répondant à cet e-mail afin de les regrouper dans le même fil
  • La personne chargée de la coordination a répondu avoir bien consulté tous les signalements reçus et a remercié les participants pour le temps consacré aux remontées

Schéma du code malveillant — atomic-lockfile

  • Les paquets altérés exécutent tous npm install atomic-lockfile, suivi de noms d’autres paquets npm comme ora, fast-glob, glob, minimist, axios, commander, execa, chalk, debug, entre autres
  • Types de fichiers où se trouvait la commande malveillante
    • scripts d’installation de type *-deps.install
    • scripts d’installation de paquet *.install
    • fichiers *.hook — par exemple sous la forme Exec = /bin/sh -c 'cd /tmp && npm install atomic-lockfile ... 2>/dev/null; exit 0', exécutée depuis /tmp puis terminée en masquant les erreurs
    • dans certains cas, incluse dans des fichiers associés comme install.sh
  • Un exemple de nouveau paquet malveillant, exodus-wallet-bin, a été signalé ; il s’agissait d’un paquet tout juste créé, apparu environ 4 heures plus tôt au moment du premier commit

Méthode de détection et étendue de l’impact

  • La détection a été effectuée en inspectant directement un miroir en lecture seule
    • après git clone https://github.com/archlinux/aur.git, parcours de toutes les refs puis exécution de git grep 'atomic-lockfile'
    • cela a permis d’obtenir une longue liste d’environ 408 paquets installant atomic-lockfile, exploitable pour un nettoyage automatisé
  • Exemples de paquets mentionnés comme affectés
    • runescape-launcher, oracle-bin, tesseract-gui, python-starsessions, bitcoin-core-git, apple-music-desktop, exodus-wallet-bin, anythingllm-appimage, arm-linux-gnueabihf-binutils, entre autres
    • y compris de vastes familles de paquets comme cutefish-*, python2-* et python-*
  • Face au grand nombre d’e-mails générés par les signalements individuels, il a été recommandé de regrouper plusieurs cas dans un seul message, et une liste consolidée des paquets a aussi été partagée séparément sur IRC

Méthode d’usurpation/falsification

  • Pour des paquets liés à un compte donné (arojas), des questions ont été soulevées sur un éventuel piratage de compte ou une falsification de commit
  • Il a été confirmé que les commits malveillants usurpaient le nom et l’adresse e-mail du commit précédent (impersonate) — autrement dit, une falsification des métadonnées du commit
  • Il a aussi été signalé que d’autres paquets du même utilisateur avaient déjà été corrigés

État de la réponse

  • Les commits de paquets signalés ont été traités progressivement, et certains éléments ont reçu une réponse corrigé (Done)
  • À mesure que de nouveaux signalements arrivaient, la personne chargée de la coordination a vérifié l’ensemble des remontées, en parallèle des opérations de blocage et de réinitialisation en cours
  • De nombreux participants ont signalé des paquets individuels avec des liens vers les commits, dans le cadre d’une réponse collaborative pilotée par la communauté

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Lobste.rs
  • J’ai l’impression que cet incident va presque achever la confiance qui subsistait encore dans les contributions anonymes et non vérifiées de la communauté
    On a l’impression de voir la confiance se faire grignoter en temps réel

    • Franchement, c’est une bonne chose, et ça arrive déjà trop tard. Notre secteur doit enfin se ressaisir
      Nous confions beaucoup trop de données personnelles et sensibles à nos ordinateurs, qui sont devenus le centre de la vie moderne. Quand un ordinateur personnel est infecté, c’est un événement vraiment catastrophique, et au mieux il ne reste qu’à espérer que je ne sois pas assez intéressant pour qu’un hacker veuille s’acharner spécifiquement sur moi
      Et pourtant, pour une raison ou une autre, nous avons normalisé le fait d’exécuter n’importe quel programme aléatoire avec les pleins pouvoirs[1], puis nous faisons semblant d’être surpris chaque fois que cela se révèle être une mauvaise idée
      [1] Du point de vue des privilèges de l’utilisateur actuel. Dans la plupart des configurations, root est pratiquement dénué de sens
    • KDE a retiré AUR de son propre pipeline de build il y a une semaine, probablement en réponse à une version antérieure de cette attaque
    • Il serait intéressant d’appliquer un modèle de toile de confiance à la revue des paquets AUR, combiné à une période de refroidissement pour les mises à jour récentes
      J’imagine un système qui proposerait ce type d’options lors de l’installation ou de la mise à jour d’un paquet AUR : attendre une semaine pour qu’un paquet récemment mis à jour « refroidisse », prendre soi-même quelques minutes pour examiner le paquet et laisser une revue signée liée à sa réputation, ou s’appuyer sur des revues signées d’autres personnes en qui l’on a suffisamment confiance
      Une période de refroidissement n’est peut-être pas techniquement compatible avec la politique d’Arch consistant à garder tous les paquets à jour ensemble. Mais les paquets AUR ne relèvent de toute façon pas du support officiel
  • Plusieurs heures ont passé, et le paquet NPM n’a toujours pas été retiré : https://www.npmjs.com/package/atomic-lockfile

  • Pour vérifier si des paquets installés sont affectés, vous pouvez utiliser ce petit script avec le fichier aur_pkg_list.txt

    installed_pkgs="$(yay -Qq)";  
    grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' \  
    | while read -r pkg; do \  
        echo "$installed_pkgs" | grep "^$pkg\$"; \  
    done  
    

    J’ai mis des points-virgules, donc c’est facile à transformer en commande sur une seule ligne :-)

    • On dirait que ça attrape aussi les sous-chaînes. Par exemple, ktea correspond aussi à kteatime
      Cette version semble fonctionner

      grep refs aur_pkg_list.txt | awk -F/ '{print $4}' | tr -d ')' | while read -r pkg; do  
         echo "$installed_pkgs" | grep "^$pkg\$";  
      done  
      
  • Il est possible que cela dure depuis assez longtemps. Cet e-mail d’il y a 18 jours semble montrer qu’une charge utile malveillante similaire a été utilisée, mais le commit malveillant semble avoir été entièrement supprimé du dépôt

  • À ce sujet, existe-t-il une bonne comparaison de la posture de sécurité de la chaîne d’approvisionnement des distributions Linux populaires ? Jusqu’ici, la plupart des articles que j’ai trouvés ressemblaient soit à du marketing déguisé, soit à des textes bâclés générés par IA. Je vais peut-être devoir faire les recherches moi-même
    Ce qui est déprimant, c’est que tout en appréciant l’idéal du développement communautaire, les inquiétudes liées à la chaîne d’approvisionnement me poussent à regarder de plus près des options fermées, voire des logiciels propriétaires