Das Arch User Repository (AUR) ist Ziel eines koordinierten Supply-Chain-Angriffs geworden. Innerhalb der letzten 24 Stunden wurden dabei offenbar insgesamt 446 Pakete (eigentlich sind es ja Paketbeschreibungen) mit Malware infiziert.
Bösartiges npm-Paket
Der Angreifer modifizierte dabei die Build-Schritte der betroffenen AUR-Pakete so, dass während des Build-Vorgangs ein bösartiges npm-Paket heruntergeladen und installiert wurde. Dieses tarnte sich als atomic-lockfile in Version 1.4.2 und enthielt einen Linux-ELF-Payload namens deps. Über einen Preinstall-Lifecycle-Hook wurde die Schaddatei als Nebeneffekt des normalen Build-Prozesses automatisch beim Ausführen von npm install gestartet.
Dependency Credential Stealer
Bei deps handelt es sich um einen Linux-Credential-Stealer mit optionalen eBPF-Rootkit-Fähigkeiten, der gezielt auf Entwickler-Workstations und Build-Umgebungen ausgerichtet ist. Er hat es unter anderem auf Browser- und Electron-App-Daten, Slack, Microsoft Teams, Discord, GitHub, NPM, Vault, Docker/Podman, SSH- und VPN-Material sowie Shell-Historien abgesehen. Die Kommunikation mit dem Angreifer läuft über einen Tor-Onion-Service.
Arch-Linux-Paketquellen nicht betroffen
Ausdrücklich nicht betroffen sind die offiziellen Arch-Linux-Paketquellen, der Angriff beschränkt sich auf das AUR. Die Community arbeitet bereits daran, die schadhaften Commits zu entfernen und betroffene Accounts zu sperren. Wer in den letzten Tagen AUR-Pakete installiert oder aktualisiert hat, sollte vorsichtig sein. Das CachyOS-Forum stellt ein Prüfskript bereit, mit dem sich feststellen lässt, ob eines der bekannten kompromittierten Pakete installiert ist. Grundsätzlich gilt wie immer: Vor der Installation eines AUR-Pakets lohnt sich ein Blick in das PKGBUILD. Auf der Webseite ioctl.fail findet ihr eine Analyse der verwendeten Malware.
Zu viele Windows-User unter den Arch-Usern 😉
Ne Spaß, aber im “Don’t Break Debian”-Guide steht schon seit Jahrzenten, dass man aus Gründen der Sicherheit und Systemstabilität eigentlich quasi nie Fremdpakete installieren soll, und zwar immer in der Reihenfolge “Alternative in den off. Repos suchen, Flatpak/Snap/Appimage/, dann selber bauen und als letztes nur vertrauenswürdige Fremdrepos einbinden, bei den man den Maintainer verifizieren kann; und dann auch bei jedem einzelnen Update aufpassen, was gepatched wird, weil jedes Fremdrepo das System mit einem Update kaputt machen kann.
Das AUR verstößt gegen alle best practices zugunsten der Verfügbarkeit von Software, unter vanilla Arch ist es imho ok, weil man da schon über ein paar Hürden springen muss, um die AUR benutzen zu können, aber die ganzen Derivaten mit vorinstallierten yay oder graphischen AUR Helper find ich super fahrlässig. Das wird von Linux/Arch Neulingen benutzt wie die die ganzen .exe oder .msi Installer unter Windows, ist aber nur noch unsicherer, weil der Softwareanbieter nicht der Maintainer ist, sondern ein random dude, der Skripte schreibt, die mit root rechten ausgeführt werden. Da schüttelt es mich einfach.
Das AUR verstößt nicht gegen die best practices.
Es entspricht dem Selbst-Bauen von Paketen, wobei mit dem PKGBUILD lediglich eine Bauanleitung zur Verfügung gestellt wird.
Ein Problem damit, ergibt sich erst dann, wenn alle Vorgänge automatisiert sind und niemand mehr prüft, was dort tatsächlich gebaut wird.
Die Online Magazine wie Pcgameshardware mit dem Sven Bauduin und Youtuber mit gefährlichen
Halbwissen tragen massiv dazu bei, dass das AUR immer mehr Ziel von Schadsoftware wird.
Sie bewerben CachyOS mit das einfachste und beste System für Gaming und wie einfach alles zu installieren ist. Seit immer mehr Arch Derivate wie CachyOS, Manjaro, Garuda beworben wird, nehmen die Problem im AUR überhand. Weil diese Systeme einen 1 Klick Installer bieten wie Pamac, Otcopi und andere. Was Magazine wie Pcgameshardware und Youtuber verschweigen ist, dass man keine Software aus dem AUR per Klick installieren sollte, ohne vorher den Paketbuild zu lesen. Dazu sind die ganzen Umsteiger aber gar nicht imstande. Ich behaupte auch die Redakteure wie Sven Bauduin haben keinen Plan davon. Hauptsache es gibt Klicks und Aufrufe. Unverantwortlich. Aber dasselbe Muster sieht man ja auch bei TikTok mit den Influencer.
Das sind aber durchaus Dinge, die auch einem nicht ganz unbedarften Nutzer durchrutschen können, einfach weil es ein großer Aufwand ist, das bis in die letzte Abhängigkeit zu prüfen.
Das Problem ist hier durchaus schon auch das AUR selber, das für solche Angriffe einfach zu anfällig ist.
Die Schwarze Piste ist auch nichts für den Skianfänger.
Aber vielleicht solle man besser die Berge planieren, damit keine Dummköpfe, die noch nicht einmal mehr ein Schild lesen können, nicht mehr auf die Nase fallen können.
Es ist wirklich nicht gut, wenn völlig unbedarfte User sich mit nur einem Klick aus den AUR bedienen können. Sie sind auch das Ziel solcher Angriffe.
https://wiki.archlinux.de/title/AUR_Sicherheitshinweise
Rein theoretisch ist der Disclaimer aber, dass man auch als (Ski)Profi eigentlich nie Pakete aus dem AUR installieren sollte, es sei denn, es gibt keine besseren Alternativen und man braucht die Software wirklichwirklich und prüft jedes Installscript per Hand, und auch dann nur mit größter Vorsicht, Backups und manuellen Prüfen jeden einzelnen Updates aus der AUR. Ich hab aber noch nie einen Arch User getroffen, der das wirklich macht. Sagen nur alle, dass man das so machen sollte.
Natürlich sollte man schauen, woher die Software kommt, die man sich installiert. Auf den zweiten Blick geht es hier aber schlichtweg um Vertrauen. Hat die Software eine gute Reputation? Wie alt ist das Repo? Gibt oder gab es bekannte Vorfälle? Manche AUR-Pakete werden auch von den Entwicklern selbst geschnürt.
Man könnte auch sagen, bevor man sich irgendwas installiert (egal ob offizielle oder sekundäre Paketquellen), sollte man den Source-Code studiert haben – völlig illusorisch. (Steile These: Solche Vertrauensketten werden in Zukunft, auch Abseits der Computerei, mehr denn je eine Rolle spielen – weil wir bspw. nicht mehr selbst wissen können, was ‘echte’ Berichterstattung ist und was AI-Slop).
Aber abgesehen davon, kommen mir AUR->AUR-Abhängigkeiten fast nie unter.
Mit den Vertrauensketten ist das aber halt so eine Sache, denn anscheinend waren das hier verwaiste Pakete, die von neuen Maintainern übernommen und dann manipuliert wurden. Das können also Pakete sein, denen Leute aus gutem Grund über einen längeren Zeitraum vertraut haben und die bei einer Internet-Recherche dann auch entsprechend oft empfohlen werden.
In anderen Repositories ist das mitunter auch möglich, die Frage ist dann aber eben, unter welchen Bedingungen und nach welchen Prüfprozessen die Kontrolle über ein bestehendes Paket mit aktiven Nutzern an einen neuen Maintainer übergeben wird.
Und ja, man muss Abhängigkeiten prüfen und damit meinte ich nicht AUR->AUR sondern generell alle. Die Malware wurde hier schließlich als npm-Paket installiert. Selbst wenn man das Pkgbuild liest, muss man sich dann also überlegen, ob die Nutzung von npm oder anderer Methoden zur Installation von Build-Dependencies plausibel ist und genau überprüfen, was da installiert wird und ob das vertrauenswürdig ist.
Aber ja doch. Der Arch Linux Nutzer macht das so bei jeder Neuinstallation aus den AUR. Bei den Updates kann dann ein geeigneter AUR-Helper das PKGBUID auf Änderungen überprüfen.
Richtig ist, dass diese Zielgruppe den Kreis der Anwender erhöht, die sich der Gefahren nicht bewusst sind. Tätsächlich habe ich keinen Artikel gefunden, in dem er auf die Gefahren hingewiesen hat. Die Verantwortung sehe ich an erster Stelle eher beim Kreis derer, die ein OS für diese Zielgruppe anbieten, dennoch hast Du schon recht, dass eine Warnung bei solchen Quellen angemessen wäre. Die Eigenverantwortung der Endanwender ggf. auch der Eltern besteht zwar, überfordert aber häufig die Beteiligten.
Das Thema der Prüfung wird in Zeiten von Vibe Coding noch kritischer. Da müssen sich auch versiertere Anwender überlegen, wem sie trauen. Das gilt für den Direktbezug aus Gits ebenso wie auf freien Repos. Ich denke in meinem Fall z.B. an die OpenRepos für SailfishOS. Daher werde ich künftig das künftig stärker hervorheben.
Jo und generell ein hausgemachtes Problem bei Cachy & Co klicki bunti Installer.