Comment vérifier les PKGBUILDs d’Arch Linux

Ces derniers temps, plusieurs logiciels malicieux ont fait leur apparition sur l’AUR (Arch User Repository) d’Arch Linux. Des versions vérolées de Librewolf. Firefox, Zen Browser et Chrome ont été uploadées dans l’espoir que les personnes les plus négligentes qui ne vérifient pas les PKGBUILDs installent ces joli RAT.

Les utilisateurs et contributeurs d’Arch Linux ont souvent la réputation d’être élitistes, mais il n’en est rien. réussir à installer Arch est une chose, mais une fois installé, il reste déjà quelques étapes de base à ne pas oublier. Mais ces exemples d’attaques montrent surtout qu’il est préférable d’avoir un minimum de connaissance en programnation Shell pour vérifier ce qu’on installe. Piocher à l’aveugle dans les repo AUR revient à se ballader à poil devant un essaim d’abeilles (On peut toujours utiliser Arch sans AUR mais on limite fortement le nombre de packages disponibles).

Si besoin, pour pouvoir mieux profiter de Arch, explorez le monde merveilleux du shell et de la structure de Linux. Voici quelques exemples de tutos:

Pour débuter en Bash script:
Introduction au script Bash sous Linux : créer son premier script !

La documentation officielle pour PKGBUILD:
PKGBUILD

Pour aller plus loin en Bash:
La programmation « Shell »

Pour découvrir l’archtecture d’un système Linux et l’analyser:
Comment investiguer une machine sous Linux

Pourquoi vérifier ?

• Les PKGBUILD sont des scripts shell exécutés avec vos droits utilisateur.
• Ils peuvent télécharger et exécuter n’importe quel code.
• Un PKGBUILD malveillant peut compromettre votre système.
• Même des PKGBUILDs bien intentionnés peuvent contenir des erreurs.

Processus de revue basique

1. Lire le fichier PKGBUILD
   Après avoir cloné depuis l’AUR : git clone https://aur.archlinux.org/nom-du-paquet.git cd nom-du-paquet cat PKGBUILD # ou utilisez votre éditeur préféré
2. Vérifier ce qui est téléchargé
   • Regardez le tableau source : grep "^source=" PKGBUILD
   • Vérifiez la présence de sommes de contrôle (évitez SKIP) : grep "sha256sums=" PKGBUILD
3. Inspecter les fichiers additionnels
   • Lister pour trouver des scripts .install ou des patchs : ls -la cat *.install # pour voir les scripts d’installation/mise à jour

Les red flags

Patterns dangereux :

• curl | sh (pipe vers le shell)
• wget -O- | bash
• rm -rf / ou $HOME (suppression destructrice)
• chmod 777 (droits excessifs)
• sudo dans build() (jamais nécessaire)
• eval $(curl ...) (exécution à distance)

Comportements suspects

• source=() contenant des URLs non fiables ou du HTTP non sécurisé
• Sommes de contrôle manquantes ou en SKIP
• Code obfusqué ou commandes encodées en base64
• Téléchargements depuis pastebin ou raccourcisseurs d’URL
• Activité réseau sortant du cadre du téléchargement de sources
• Écriture vers des répertoires système dans build()

Signes positifs

• Code clair, lisible
• Sources HTTPS provenant de dépôts officiels
• Présence de sommes sha256/sha512
• Mainteneur reconnu ou contributeur officiel
• Mises à jour récentes
• Populaire/voté sur l’AUR

Outils de revue

1. namcap : vérifier le PKGBUILD namcap PKGBUILD
2. Vérifier la page AUR
   • Lire les commentaires
   • Regarder le nombre de votes/popularité
   • Observer l’historique du mainteneur, l’âge et la dernière mise à jour du paquet
3. Comparer avec les paquets officiels
   • Si un équivalent existe : asp export paquet-officiel diff -u paquet-officiel/PKGBUILD votre-paquet/PKGBUILD
4. Voir l’historique git : git log --all --oneline git show <commit>

Checklist revue étape par étape

1. Examiner les métadonnées : head -n 20 PKGBUILD
2. Vérifier les sources : grep -A 5 "^source=" PKGBUILD
3. Vérifier que les sommes de contrôle ne sont pas en SKIP : grep "sums=" PKGBUILD
4. Revoir la fonction build() : sed -n '/^build()/,/^}/p' PKGBUILD
5. Revoir la fonction package() : sed -n '/^package()/,/^}/p' PKGBUILD
6. Vérifier la présence de scripts install : cat *.install 2>/dev/null
7. Vérifier avec namcap : namcap PKGBUILD
8. Lire les commentaires sur l’AUR.

Tester dans un environnement isolé (avancé)

• Chroot propre : extra-x86_64-build
• Avec Docker/Podman : docker run -it archlinux bash # installer et tester le paquet à l’intérieur

Problèmes courants à repérer

• Dépendances manquantes (depends=())
• pkgver incorrect
• Chemins codés en dur au lieu de variables ($pkgdir, $srcdir)
• Licence absente
• Spécification d’architecture incorrecte (arch=())

Exemple de revue

1. Cloner et se placer dans le dossier : git clone https://aur.archlinux.org/spotify.git cd spotify
2. Aperçu rapide : cat PKGBUILD | head -20
3. Vérifier sources et checksums : grep -E "(source|sums)=" PKGBUILD
4. Chercher les patterns dangereux : grep -i "curl.*sh\|wget.*bash\|rm -rf\|sudo" PKGBUILD
5. Vérifier avec namcap : namcap PKGBUILD
6. Si c’est bon, compiler : makepkg -si

Avec ces quelques vérifications en tête, vous voyez maintenant qu’il est assez facile de détecter la tentative d’attaque de « google-chrome-stable » dont on parlait en intro:

Bonnes pratiques

• Ne jamais faire confiance aveuglément, même aux paquets populaires
• Mettre à jour régulièrement, et revoir les changements (git diff)
• Signaler les problèmes (laisser des commentaires sur l’AUR)
• Utiliser les helpers AUR (yay, paru…) avec prudence et toujours afficher le PKGBUILD pour contrôle
• En cas de doute, demander conseil sur le forum Arch ou IRC

Astuce AUR helpers

Avec yay, paru, etc…

yay:

yay -S nom-du-paquet  # Affiche le PKGBUILD pour revue avant installation
yay -Gp nom-du-paquet  # Affiche seulement le PKGBUILD sans installer

Et paru l’affiche par défaut.

Règle d’or : si vous ne comprenez pas le contenu d’un PKGBUILD, ne l’exécutez pas tant que vous n’avez pas compris ou qu’une personne de confiance (donc pas un mec random sur jeuxvideo.com) ne l’a pas validé.