AUR-Pakete mit Infostealer und Rootkit kompromittiert

 (discourse.ifin.network)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das AUR-Paket-Repository ist so aufgebaut, dass jeder verwaiste Pakete übernehmen und Änderungen an PKGBUILD sowie zugehörigen Dateien einreichen kann; in diesem Vorfall gibt es Hinweise darauf, dass mehr als 408 Pakete kompromittiert wurden
  • Ein neuer AUR-Paket-Maintainer gab sich als vertrauenswürdiger Maintainer aus, übernahm Pakete, und andere AUR-Maintainer arbeiten an der Entfernung der kompromittierten Pakete
  • Die zunächst kompromittierten Pakete wurden so verändert, dass sie über ein preinstall-Skript npm ausführen, um die bösartige Payload atomic-lockfile zu installieren
  • Spätere Kompromittierungen installierten das bösartige js-digest mit Bun; NPM hat dieses Paket entfernt
  • Die meisten Pakete werden selten genutzt, doch der Umfang ist groß, und besonders relevant ist, dass es sich um einen Supply-Chain-Angriff handelt, der zusätzlich zu Infostealer-Verhalten auch ein eBPF-Rootkit enthält

Aktueller Stand des Vorfalls

  • Was ist passiert?

    • Es gibt Hinweise darauf, dass ein neuer AUR-Paket-Maintainer sich als vertrauenswürdiger Maintainer ausgab, mehr als 408 Pakete übernahm und kompromittierte
    • Nachdem die Kompromittierung gemeldet wurde, begannen andere AUR-Maintainer damit, die infizierten Pakete zu entfernen
    • Mit Stand 2026-06-12T17:30:00Z berichten die AUR-Maintainer, dass sie alle bösartigen Commits entfernt haben
    • Die AUR-Maintainer wollen für einige Funktionen, darunter die Paketübernahme, Kontrollen und Beschränkungen einführen
    • Arch Linux veröffentlichte die Mitteilung Active AUR malicious packages incident

  • Bösartige Abhängigkeiten

    • Der Angriff umfasste mindestens zwei separate bösartige Abhängigkeiten
    • Die zuerst betroffenen Pakete wurden so angepasst, dass sie per preinstall-Skript mit npm das bösartige Payload-Paket atomic-lockfile installieren
    • Im Paket premake-git gibt es einen Beispiel-Commit für diese Änderung
    • Spätere Kompromittierungen nutzten Bun zur Installation des bösartigen js-digest; NPM hat js-digest entfernt
    • Eine detaillierte Analyse des Angriffs findet sich unter Preliminary analysis of AUR malware

Reaktion und Kompromittierungsindikatoren

  • Empfohlene Maßnahmen

    • Wer Arch nicht verwendet, ist nicht direkt von dieser AUR-Paket-Kompromittierung betroffen
    • Arch-Nutzer sollten die Liste der betroffenen Pakete prüfen und ihr System mit einem Skript zur Überprüfung möglicher Exposition untersuchen
    • Das im Original verlinkte aur_check.sh ist eine veraltete Version; für die aktuelle Prüfung sollte den Hinweisen in dem betreffenden Gist gefolgt werden
    • Werden Kompromittierungsindikatoren gefunden, sollte das System für eine angemessene forensische Untersuchung erhalten bleiben
    • Werden infizierte Pakete festgestellt, sollten die üblichen Incident-Response-Verfahren befolgt, alle Zugangsdaten ausgetauscht und eine Neuinstallation von Arch in Betracht gezogen werden
    • Wegen der möglichen Rootkit-Komponente kann die Vertrauenswürdigkeit des Systems nicht mehr garantiert werden
    • Alle Nutzer sollten Maßnahmen ergreifen, um ausgehenden Tor-Traffic im Netzwerk zu blockieren

  • Kompromittierungsindikatoren

    • Die SHA256 der in js-digest eingebetteten bösartigen Linux-Executable lautet 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
    • Mit bpftool map list lassen sich verdächtige eBPF Maps erkennen
    • Verdächtige Map-Namen sind unter anderem hidden_pids, hidden_names, hidden_inodes

  • Weitere bestätigte Punkte

    • Nicht bestehende Maintainer-Konten führten die bösartigen Commits aus; vielmehr wurden bekannte Maintainer-Konten nachgeahmt
    • Die meisten Pakete werden selten genutzt, doch der Umfang der Kompromittierung mit mehr als 408 Paketen ist groß
    • Ein Supply-Chain-Angriff, der zusätzlich zu Infostealer-Verhalten auch noch ein eBPF-Rootkit enthält, ist ein seltener Fall
    • Die Socket.dev-Seite zu atomic-lockfile zeigt 134 Downloads des bösartigen NPM-Pakets an
    • Das NPM-Paket wird vom Nutzer herbsobering gepflegt
    • Bei einer Suche nach dem GitHub-Benutzernamen herbsobering findet sich das einzelne Container-Image herbsobering430, das wie ein Reverse-Shell-/Proxy-Tool wirkt
    • Im AUR-Paket-Repository kann jeder ein Paket übernehmen und Änderungen an PKGBUILD sowie zugehörigen Dateien einreichen, wenn das Paket als unbetreut markiert ist
    • Verwaiste Pakete automatisch zu finden und zu übernehmen, ist nicht ungewöhnlich; Hintergrund dazu gibt es im Mastodon-Thread

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Man muss akzeptieren, dass das AUR nur eine Sammlung von von Nutzern erstellten PKGBUILDs ist.
    Man sollte den Quelltext jedes PKGBUILDs, das man aus dem AUR installiert, unbedingt prüfen, und Updates sind keine Ausnahme. Das ist seit über zehn Jahren eine immer wieder diskutierte Grundannahme, und genau deshalb gibt es auch keinen offiziellen AUR-Helper wie yay.
    Es gibt viele Klagen darüber, dass Arch Linux elitär sei, aber realistisch betrachtet ist es eine Distribution für Menschen, die wissen, was sie tun, und nicht wollen, dass man sie bei jedem Schritt an die Hand nimmt. Das bedeutet auch: Wenn man zufällige AUR-Pakete installiert und sich damit das System kaputtmacht oder kompromittieren lässt, ist man selbst verantwortlich.
    Allerdings könnte die Zeit vorbei sein, in der jeder AUR-Pakete übernehmen kann. Allein die Kosten dafür, betroffene Pakete jedes Mal zurückzusetzen, sind zu hoch. Als Alternative jede Übernahmeanfrage zu prüfen, wäre zu aufwendig und hilft vermutlich auch nicht immer.

    • Wenn man bei jeder Installation aus dem AUR den Quelltext aller PKGBUILDs prüfen soll, müsste das dann nicht genauso für Browser-Erweiterungen, VSCode-Erweiterungen, NuGet-Pakete, Cargo-Crates, Python-Pakete, npm-Pakete usw. gelten?
      Ich denke schon, außer man führt sie nur an Orten aus, die keinen Internetzugang haben oder nur auf Dinge zugreifen können, die auch öffentlich sein dürfen.
      Vielleicht nicht beim AUR, aber in anderen Ökosystemen ließe sich das theoretisch über Berechtigungsmodelle oder Sandboxing verbessern. Bei Browser-Erweiterungen gibt es diese Möglichkeit bereits, aber „normale“ Nutzer verwenden sie kaum.
      Leider können 99,99 % der Menschen nicht alles prüfen oder haben keine Zeit dafür. Am sichersten wirken Distribution-Pakete mit vertrauenswürdigen Maintainer:innen oder Orte wie der iOS App Store, wo es Berechtigungen und zumindest ein gewisses Maß an Prüfung gibt.
    • Ich glaube kaum, dass das eine echte Lösung ist. Der übliche Ablauf solcher Angriffe war bisher, die Payload irgendwo in den Abhängigkeiten zu verstecken.
      Dieser Fall ist etwas ungewöhnlich, weil hier im PKGBUILD ziemlich schlampig einfach npm install ausgeführt wird. Inzwischen haben aber fast alle Paket-Repositories außerhalb des AUR dasselbe Problem, und die komplette Abhängigkeitskette manuell zu auditieren, ist unrealistisch.
      Eine Lösung habe ich allerdings auch nicht.
    • Zu glauben, dass auch nur ein kleiner Teil der Nutzer das tatsächlich macht, ist extrem realitätsfern.
    • Ich frage mich, wie sehr sich das AUR als Sammlung nutzergenerierter PKGBUILDs wirklich vom gesamten PyPI-Ökosystem, npm oder Docker Hub unterscheidet.
      Leute schalten SELinux ab, --privileged deaktiviert seccomp und AppArmor, und es gibt auch Sandbox-Escape-CVEs.
    • Dass jeder AUR-Pakete übernehmen konnte, hätte es von Anfang an nicht geben dürfen.
      Letztlich wäre eine Struktur wie username/packagename-bin|git wünschenswert. Dann wäre viel klarer, was genau und von wem die Leute tatsächlich installieren.

  • Diese Kampagne läuft noch immer. Ich habe gerade eine E-Mail bekommen, dass eines meiner alten Pakete übernommen wurde; es funktionierte seit Jahren nicht mehr und war schon längere Zeit ein verwaistes Paket. Direkt nach der Übernahme wurde ein bösartiger Commit eingespielt.
    Offenbar wird jetzt statt npm bun verwendet, daher sind npm-basierte Workarounds möglicherweise wirkungslos.
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • An diesem Punkt frage ich mich, ob das Konzept der Übernahme verwaister Pakete nicht grundsätzlich kaputt ist und vielleicht ganz abgeschafft werden sollte.
      Das wäre zwar unbequem, aber vielleicht wäre es besser, wenn das AUR stattdessen eine Neueinreichung erzwingt, statt dass jemand ein von anderen aufgegebenes Paket übernimmt, und verwaiste Pakete nach einer gewissen Zeit regelmäßig gelöscht werden.
    • Ich habe gerade ebenfalls eine Benachrichtigung bekommen, dass eines der AUR-Pakete, die ich beobachte, an eine mir unbekannte Person übergegangen ist, weil es ein verwaistes Paket war.

  • Dass man vorsichtig sein muss, wenn man etwas aus dem AUR installiert, ist selbstverständlich, und auch früher gab es immer wieder fragwürdige Pakete, also solche, die falsch gebaut oder falsch paketiert waren, aber aktive böswillige Einschleusungen zu sehen, ist beunruhigend.
    Ich denke, das AUR hat zwei große Probleme. Erstens ist es ein Überbleibsel aus einer etwas egalitäreren Open-Source-Zeit, in der man Drittanbieter-Code meist vertrauen konnte. Zweitens kann jeder verwaiste Pakete übernehmen, wobei die bisherige Historie und der Prüfverlauf erhalten bleiben.
    Die erste Ära ist längst vorbei, und das zweite Problem ließe sich durch strengere Kontrollen für AUR-Konten oder zusätzliche Schutzmechanismen in AUR-Helpern abmildern. Zum Beispiel könnte bei Paketen mit kürzlich gewechseltem Eigentümer eine große, furchteinflößende Warnung angezeigt werden. Manche würden dann zwar trotzdem einfach y drücken und weitermachen, aber das ist immer noch besser als gar nichts.
    Oder man vermeidet AUR-Helper ganz und prüft und baut die benötigten Pakete direkt aus dem PKGBUILD.

    • Die Richtlinie zur Paketübernahme war zu keinem Zeitpunkt wirklich sinnvoll.
    • Ich finde eher, dass AUR-Helper es leichter machen, den Prüfschritt in den Workflow zu integrieren.
      Sie fordern aktiv zur Prüfung auf und zeigen zuletzt auch an, ob es Änderungen gab, nachdem man das Risiko akzeptiert hat.
      Allerdings ist die Sichtweise „Das AUR ist schädlich“ nicht neu. Wer das AUR nutzt, sollte die Risiken verstehen; letztlich ist es nur eine Stufe besser, als etwas von StackOverflow zu nehmen und per curl | bash auszuführen.

  • Mehr als 7 Stunden später gibt es auf archlinux.org oder aur.archlinux.org immer noch keinen Hinweis dazu. Ich verstehe nicht, warum. Die AUR hätte gesperrt werden müssen, bis Maßnahmen ergriffen wurden, die belegen, dass Nutzer von dem Vorfall wissen.
    Man hätte zum Beispiel die AUR-API-URL leicht ändern können, damit yay-/yaourt-Nutzer nachsehen müssen, was los ist. Die neue API sollte eine Infrastruktur haben, die Nutzer informiert und vor dem Fortfahren bestätigt, dass sie die Nachricht gelesen haben. Das ist umso nötiger, wenn nicht einmal sicher ist, ob sämtliche Malware gefunden wurde.
    Außerdem sollte es eine Datenbank mit zurückgezogenen oder kompromittierten AUR-Commits geben sowie einen Mechanismus, der Nutzer warnt, wenn sie das betreffende Paket installiert haben.

    • Ob gut oder schlecht, in der AUR gibt es diesen Warnhinweis schon immer.
      Er steckt bereits im Namen, und auch in den Wiki-Unterlagen wird klar darauf hingewiesen, dass die AUR ein Nutzer-Repository ist und nicht blind vertraut werden darf.
      Es steht wörtlich im großen roten Kasten ganz oben: https://wiki.archlinux.org/title/Arch_User_Repository
      Es gibt viele Dinge in der AUR, die ich niemals installieren würde, und ich halte es nicht für die beste Lösung, all das über die Mailingliste zu verteilen.
      Die Idee, Nutzer zu warnen, die ein bösartiges Paket installiert haben, finde ich an sich nicht schlecht, aber sie ist schwer umsetzbar. In der AUR gibt es kein Installations-Tracking wie in kommerziellen Tools. Woher sollte man wissen, wer welches Paket installiert hat? Die AUR ist im Grunde eher ein Verzeichnis von Paketstandorten und verlangt weder Login noch Anmeldedaten.
      Warnungen müssen daher aus Tools kommen, die Nutzer bewusst einsetzen können, und sie setzen tatsächlich voraus, dass man aufmerksam ist. Zum Beispiel: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • Das sollte nicht so sein. Nur weil manche Leute grundlegende Sicherheitshinweise nicht ernst nehmen, darf man nicht den Workflow aller kaputtmachen.
      Und wie genau soll eine neue API Nutzer informieren und sie bestätigen lassen, dass sie es gelesen haben? AUR-Pakete sind einfach git-Repositories, und was AUR-Helper tun oder nicht tun, können die Arch-Maintainer nicht kontrollieren.
    • Ich finde, auf der Startseite der AUR sollte ein Hinweis stehen. Persönlich denke ich, dass auch eine kurze Mitteilung auf der Arch-Homepage plus ein Link auf den Hinweis auf der AUR-Seite hilfreich wäre.
      Wenn man nicht alle bekannten betroffenen Pakete auflisten will, sollte man zumindest die offizielle Position empfehlen, dass Leute, die AUR-Pakete verwenden, jede Datei aller von ihnen genutzten Pakete lesen müssen.
    • Inzwischen gibt es einen Hinweis: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • Wenn man den Zahlen von Socket.dev trauen kann, scheint der Schaden glücklicherweise ziemlich begrenzt zu sein.
      Das ergibt auch irgendwo Sinn. Ich kenne einige der Pakete auf der Betroffenenliste; sie sind stark veraltet, und ihre Upstream-Projekte werden nicht mehr gepflegt.
      Ich weiß nicht, wie viele Opfer es insgesamt gibt, aber das AUR-Team hat wahrscheinlich genaue Zahlen. Ich gehe davon aus, dass sie ihr Bestes tun und verhältnismäßig zum Ausmaß reagieren.

  • So etwas war letztlich unvermeidlich, und ohne Veränderungen wird es wahrscheinlich häufiger passieren. Das AUR-PKGBUILD-System gefällt mir sehr, und ich nutze es oft auch selbst beim Schreiben.
    Das gravierendste und zugleich am leichtesten zu behebende Problem ist, dass verwaiste Pakete von jedem übernommen werden können, ohne dass Endnutzer überhaupt darüber informiert werden.
    Ein Paket löschen zu lassen bringt im Verhältnis zum Aufwand wenig, daher ist es der bequemste Weg, die Kontrolle abzugeben, es einfach verwaisen zu lassen. Ich finde, das sollte genau andersherum sein. Zumindest sollten Nutzer klar erkennen können, dass ein Paket verwaist ist.
    Diese Last könnte eher bei AUR-Helpern wie paru oder yay liegen, und ich würde solche Änderungen begrüßen.

  • Es gibt ein einfaches Skript zum Scannen nach kompromittierten Paketen.
    https://cscs.pastes.sh/aurvulntest20260611.sh
    Es ist nicht mein Skript, aber es ist leicht zu lesen und zu verstehen. Man sollte Skripte niemals direkt in bash pipen.

    • Es gibt auch eine schnellere Alternative.
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      Es ist nie ein schlechter Zeitpunkt, comm(1) zu lernen.
    • Das prüft nur, ob das Paket installiert wurde, nicht ob die installierte Version infiziert war.
      Vermutlich bin ich also sicher, wenn ich wie ich eine ganze Weile, mehrere Monate lang, yay -Syu nicht ausgeführt habe? …oder?
      Verdammt, bitte zwing mich nicht dazu, Arch neu zu installieren. Letztes Mal hat das eine Woche gedauert.
      Update: archinstall ist gut. Ich war in etwa 15 Minuten wiederhergestellt.
    • Es gibt keine Garantie, dass diese Liste vollständig ist.
      Man sollte immer PKGBUILD und die Quellen prüfen. Der AUR ist generell nichts, dem man vertrauen sollte. Eher überraschend ist, dass so eine Kompromittierung nicht schon früher passiert ist.
    • pacman unterstützt Datums-Lokalisierung, daher funktioniert die Suche nach 9 Jun nur mit englischer Locale oder einer Locale mit ähnlichem Format.
      Nachdem ich es an meine Umgebung angepasst hatte, wurde jd-gui erkannt, aber tatsächlich hatte ich jd-gui-bin etwa zwei Stunden vor der Kompromittierung installiert. Offenbar hatte ich Glück, weil ich an dem Abend zu faul war, auf das Kompilieren aus dem Quellcode zu warten, und deshalb das -bin-Paket gewählt habe.

  • Die Arch-Community veröffentlicht schnell Skripte und Tools.
    Das aktuellste integrierte Utility, um eine mögliche Infektion zu prüfen, ist dieses hier:
    https://github.com/lenucksi/aur-malware-check
    Außerdem gibt es auf der Mailingliste aur-requests viele Anträge auf Löschung und Verwaisung, um bösartige Commits zurückzusetzen:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • Anfängerfrage: Wie kann man wissen, ob das vertrauenswürdig ist, wenn das nicht von Arch oder einer offiziellen Quelle kommt?
      In dem Skript gibt es viele schwer verständliche Stellen, daher lässt sich nicht leicht allein durchs Lesen des Codes beurteilen, ob es sicher ist.
      Man erwartet eher eine Reaktion oder Lösung von offizieller Arch-Entwicklerseite.
    • Mir gefällt das Sternendiagramm unten im README des Repositories.
      Es vermittelt gut die Dringlichkeit und Bedeutung, die mit so einem großen Malware-Angriff verbunden sind.

  • Ich erinnere mich, vor etwa 10 Jahren auf Arch Linux den Emulator Mednafen installiert zu haben. Das Programm lief nicht, weil es gegen eine Bibliothek gelinkt war, die auf meinem System nicht vorhanden war.
    Wie sich herausstellte, hatte der Maintainer die Software auf seinem eigenen System gebaut, und dabei wurde eine dort vorhandene Bibliothek verwendet, die aber nicht in den Abhängigkeiten aufgeführt war.
    Es war ein offiziell gepflegtes Paket, und ich hatte immer gedacht, so etwas werde auf dedizierten Build-Servern erstellt, nicht von beliebigen Freiwilligen oder auf Heimcomputern. Ich weiß nicht, ob Arch heute noch auf dieselbe Weise baut, aber das war beängstigend genug, dass ich die Distribution gewechselt habe.

    • So etwas kann auch mit pkgctl build passieren. Dann hat makedepends= transitiv eine Shared Library in die Build-Umgebung gezogen, die in depends= fehlt.
      Wenn .so-Abhängigkeiten erkannt werden, gibt es zwar eine Warnung, aber es ist Sache des Maintainers, sie zu sehen und zu beheben.
      In Bezug auf Zuverlässigkeit und Sicherheit war Arch Linux eine der treibenden Kräfte hinter dem Projekt für reproduzierbare Builds, und ein erheblicher Teil des Betriebssystems kann unabhängig darauf geprüft werden, ob die Binärdateien tatsächlich aus dem Quellcode gebaut wurden. Das Auditsystem für offizielle Pakete ist stärker als bei NixOS und in etwa auf dem Niveau von Debian:
      https://reproducible.archlinux.org/
      Das alles ist allerdings völlig getrennt vom aktuellen AUR-Vorfall.
    • Es gibt Tools, mit denen man Pakete aus einem sauberen Image heraus bauen und installieren kann, um so etwas abzufangen. Zum Beispiel pkgctl.
      Maintainer sollten solche Tools vor der Veröffentlichung unbedingt verwenden.
    • Bis vor vergleichsweise kurzer Zeit war dieses Vorgehen ganz normal. Debian hat ebenfalls lange so gearbeitet und es erst 2019 vollständig verboten.

  • Was ist die Lösung für dieses Problem? Sollte man solche Pakete in einem Docker-Container ohne Netzwerkzugriff installieren? Ich glaube nicht, dass man davon ausgehen sollte, dass das nur auf AUR beschränkt ist.
    2026 muss man jeder Softwarequelle misstrauen. Besonders jetzt, wo sich Vibe Coding ausbreitet, und geschlossene Software ist als Blackbox noch chaotischer als Open Source.

    • Nicht vertrauenswürdige „App Stores“ sollten, einschließlich AUR und Flatpak, in einer Sandbox laufen. Als Standard oder Option scheint mindestens eine virtuelle Maschine nötig zu sein.
    • Ich sage es ungern, aber die Leute von Qubes OS hatten recht. Die Lösung ist, Apps aggressiv in virtuellen Maschinen zu isolieren.
      Weiß jemand, wie sehr die Akkulaufzeit leidet, wenn man konsequent umsteigt?
    • SLSA einführen
    • Flatpak

  • Es gibt weitere Berichte dazu.
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    Ich habe schon einmal über die Idee nachgedacht, ein Canary-Binary zu bauen, das beim Ausführen einfach eine E-Mail schickt oder eine Benachrichtigung anzeigt, und es npm zu nennen.
    An diesem Punkt ist es ein großes Risiko, den Namen der npm-Binärdatei nicht zu ändern.