Mitte Juni 2026 wurden über 1500 AUR-Pakete kompromittiert (siehe auch den vorigen Blog-Beitrag zu diesem Thema). Es zeugt natürlich von großer Überheblichkeit, als Mitautor eines Hacking-Buches zu glauben, selbst immun gegen Angriffe zu sein. Ein Update zum falschen Zeitpunkt hat mich auf den Boden der Tatsachen zurückgeholt und mir — einen Tag vor Urlaubsantritt — eine Menge sinnloser Arbeit beschert. Ich habe Anthropic- und OpenAI-Keys widerrufen, die SSH-Keys des betroffenen Notebooks von diversen Servern und Dienstleistern gelöscht und unzählige Passwörter geändert. Sch***!
Heute habe ich, natürlich ohne das System neuerlich zu booten, eine Analyse gemacht. Im Prinzip:
pacman --root /mnt/arch --dbpath /mnt/arch/var/lib/pacman -Qm
Ich habe 60 AUR-Pakete gefunden. Nur eines davon (libgdata, eine veraltete GNOME-Bibliothek für den Zugriff auf Google-Dienste) wurde kompromittiert. Ich habe es nur Stunden nach der Manipulation, aber eben noch vor der Berichterstattung über den Hack installiert. Extremes Pech im Timing!
Dieser Blog-Beitrag ist der Versuch einer persönlichen Aufarbeitung. Was ist passiert? Warum ist es passiert? Und was kann ich daraus lernen?
Eines vorweg. Dieser Artikel ist keine Kritik am Arch-Linux-Projekt. Dieses hat immer klar kommuniziert, dass AUR-Pakete — wie der Name schon sagt (Arch User Repository) — von den Benutzern selbst gepflegt werden und keiner Kontrolle unterliegen. Wer solche Pakete installiert, ist selbst verantwortlich, mit allen — dieses Mal sehr unerfreulichen — Konsequenzen.
Auch Updates können gefährlich sein
Die Sicherheitsempfehlung schlechthin lautet: »Installieren Sie regelmäßig Updates.« Aber diese Regel gilt nur für Pakete aus offiziellen Quellen.
Für extern gepflegte Pakete wäre eine Cool-Down-Phase sinnvoll. Im Prinzip: »Mach ein Update aller offiziellen Pakete sowie eines aller extern gepflegten Pakete, sofern dieses Update zumindest 4 Tage alt ist«. (Über die genaue Zeitspanne kann man streiten.) Ich kenne allerdings keinen Paketmanager, der so eine Funktion bietet.
In die richtige Richtung gehen die Auto-Update-Funktionen von Debian und Ubuntu: Unter Debian werden per Default ausschließlich offizielle Debian-Sicherheitsupdates berücksichtigt (Datei /etc/apt/apt.conf.d/50unattended-upgrades). Sonstige Updates werden ignoriert und müssen manuell installiert werden. Ubuntu ist etwas liberaler und installiert alle Updates aus offiziellen Quellen (aber ebenfalls keine aus externen Quellen).
Kurz gesagt: Ein blindes Update über alle Pakete ist nur sinnvoll, wenn Sie sich über die Herkunft aller Pakete sicher sind. Vielleicht werde ich in zukünftigen Blog-Artikeln Tipps zusammenfassen, wie Updates feiner gesteuert werden können.
Wozu überhaupt nicht-offizielle Pakete?
Eine andere Sicherheitsempfehlung lautet: »Verwenden Sie nur offiziell gepflegte Pakete.« Dennoch hat praktisch jede Distribution zusätzliche Paketquellen:
- Arch Linux: AUR
- Debian: externe Debian-Repositories
- Fedora: externe YUM-Paketquellen, COPR
- RHEL + Klone: EPEL, Remi und andere externe YUM-Paketquellen
- Ubuntu: externe Debian-Repositories, PPAs
Wenn externe Quellen unsicher sind, warum gibt es sie dann überhaupt? Weil sie manchmal der einzige und viel öfter der bequemste Weg sind, um Software zu installieren, die in den offiziellen Quellen fehlt. Für mich als Autor ist es wichtig, neue, nicht so bekannte Programme unkompliziert auszuprobieren. Viele Entwickler nutzen externe Pakete zur Installation von Tools, die nicht oder nur in veralteten Versionen zur Verfügung stehen. Schließlich fehlen kostenlose Programme mit kommerziellem Ursprung (also keine reine Open-Source-Software) wie Google Chrome in den offiziellen Quellen. Für »große« Distributionen gibt es zumeist »halb-offizielle« Pakete, aber für kleinere Distributionen wie Arch Linux sind Sie auf AUR-Pakete angewiesen.
Insofern ist der Rat, auf externe Quellen zu verzichten, für fortgeschrittene Benutzer und Software-Entwicklerinnen nur schwer umzusetzen.
Alles, worüber ich hier im Kontext von Linux-Paketen schreibe, gilt im Übrigen auch für die Erweiterungen/Bibliotheken aller wichtigen Programmiersprachen, Editoren und anderer Tools: also für Python-Module, NPM-Pakete, VSCode-Plugins etc. Der Überbegriff für Angriffe auf derartige Zusatzpakete lautet Software Supply Chain Attack (Lieferkettenangriff).
Weniger ist mehr
Für mich persönlich ist das AUR-Debakel ein Grund, die Nutzung externer Pakete viel stärker zu hinterfragen. Vorgenommen habe ich mir folgende Regeln:
- So wenig externe Pakete wie möglich! (Gibt es geeignete Alternativen in den offiziellen Quellen?)
- Ungenutzte externe Pakete deinstallieren. (Welche Pakete habe ich zwei, drei Monate nicht mehr gebraucht? Weg damit!)
- Eine stärkere Differenzierung zwischen Test- und Work-Systemen.
Schadensminimierung
Der AUR-Angriff hat auf Authentifizierungsdaten abgezielt, also Keys, Tokens, Passwörter etc. aus allen erdenklichen Quellen (.ssh-Verzeichnis, Passwörter diverser Browser usw.) Eine sehr detaillierte Analyse der Malware finden Sie auf ioctl.fail.
In meinem Fall war das größte Problem die Passwortsynchronisation von Google Chrome. Ich speichere im Webbrowser viele Passwörter. Die Passwort-Synchronisation ist durch ein zusätzliches, persönliches Passwort geschützt. Bookmarks und Passwörter sollten also für Google unlesbar sein. Wenn ich ein neues System einrichte (Linux, Windows, macOS, iOS oder Android), installiere ich Google Chrome, melde mich bei Google an, gebe das Master-Passwort für Bookmarks und Passwörter ein und synchronisiere die Daten. Das geht blitzschnell und ist komfortabel. Aber es ist eben ein riesiger Single Point of Failure! Das Master-Passwort schützt mich vor einem Passwort-Hack bei Google, aber es hilft nicht, wenn der Angreifer die lokale Passwort-Datenbank (sqlite-Format) auslesen kann. Und genau das war beim AUR-Angriff der Fall.
Die Konsequenz: Ich werde in Zukunft die Anzahl der so synchronisierten Passwörter auf ein absolutes Minimum reduzieren und länger nicht benutzte Passwörter löschen bzw. woanders speichern. Der naheliegende Ort wäre natürlich ein Passwort-Manager. Ich muss aber gestehen, dass ich diesen Programmen gegenüber auch skeptisch bin. Sie ersetzen einen Single Point of Failure durch einen anderen. Wer mit plattformübergreifenden Tools positive Erfahrungen gemacht hat, darf seine/ihre Erfahrungen gerne in den Kommentaren teilen :-)
Einmal mehr die Distributionsfrage
Auf meinem Linux-Notebook werde ich die aktuelle Parallel-Installation von Arch Linux und CachyOS bei nächster Gelegenheit durch Fedora ersetzen. Ich habe das Notebook zuletzt fast nur noch unterwegs verwendet. Im Büro habe ich mit dem Framework Desktop eine attraktivere Alternative. Dort habe ich mich im Rahmen meiner KI-Arbeiten gut an Fedora gewöhnt.
Zu glauben, Fedora sei frei von den skizzierten Gefahren, wäre natürlich naiv. Aber vermutlich sind die Risiken bei großen, weit verbreiteten Distributionen mit kommerziellem Hintergrund (Fedora ist ja eine Art offizielle Spielwiese von Red Hat) doch geringer als bei kleineren Distributionen — auch, was weit verbreitete, aber eben inoffizielle Paketquellen für Zusatzpakete angeht. Alleine schon die Trennung über mehrere Einzel-Repos anstelle des zentralen AUR-Verzeichnisses ist schon ein Vorteil.
Der Abschied von Arch Linux fällt mir schwer. Ich empfinde das Rolling-Release-Modell äußerst attraktiv. Arch Linux hat über mehrere Jahre sehr gut für mich funktioniert. Aber ich werde auch in Zukunft nicht ganz ohne externe Pakete auskommen. Mit AUR habe ich mir die Finger einmal verbrannt. Diese Art der Verwaltung externer Pakete ist vielleicht doch zu liberal; Paketmanager wie yay oder paru verschleiern das Risiko zu sehr. Ein zweites Mal will ich dieses Risiko nicht eingehen.
Quellen, Links
- https://ioctl.fail/preliminary-analysis-of-aur-malware/
- https://github.com/lenucksi/aur-malware-check (Test-Scripts, ob Sie betroffen sind)
- https://kofler.info/infos-zur-arch-linux-attacke
Mir ist nicht ganz klar, wie du aus diesem Vorfall die Konsequenz ziehst, von Arch Linux zu Fedora zu wechseln (gemeint ist hier nicht Arch Linux vs. Fedora, sondern der Distributionswechsel überhaupt). In deinem Artikel argumentierst du, dass nicht Arch das Problem sei, sondern im Grunde die ungeprüfte Installation von Paketen aus dem AUR, und dass das Gleiche ja auch bei der Installation von Paketen aus dem COPR passieren könne. Die Konsequenz muss – neben den von dir genannten – sein, die Pakete vor Installation bzw. Update zu überprüfen, egal ob Archs AUR oder Fedoras COPR. Ein Wechsel der Distribution wird nichts daran ändern. Mein Eindruck ist, dass sich die „Distributionsfrage“ dir eher aus emotionalen anstelle von rationalen Gründen zu stellen scheint.
Mir geht es tatsächlich wie dem Autor des ersten Kommentars.
Als Konsequenz ein Distributionswechsel macht für mich irgendwie keinen Sinn.
Ich nutze auch schon sehr lange Arch Linux und habe für mich vor einigen Jahren schon die Entscheidung getroffen, die automatischen AUR-Updates aus dem Paketmanagertools zu deaktivieren.
Ich mache auch die Updates oder besser Builds der AUR-Pakete selbst und manuell.
Dabei schaue ich mir die PKGBUILD-Dateien immer genau an und führe dann das Paketbauen durch.
Dadurch hat sich für mich sogar ein großer Vorteil ergeben, denn ich muss nicht mehr auf ein Update der PKGBUILD-Dateien warten, wenn es eine neue Version gibt, sondern ich kann direkt in meiner lokalen Kopie die Version anpassen und das Paket für mich selber bauen.
Auch sehe ich so sehr schnell, wenn im AUR bei einer PKGBUILD-Datei was angepasst wird, was bei meiner lokalen Version bis jetzt nicht der Fall ist, und kann dies hinterfragen.
Das Ganze ist bei Arch Linux auch wirklich angenehm einfach, im Vergleich z.B. zum RPM-Bauen.
Wenn man sich einmal den Arch-Linux-Wiki-Artikel dazu angesehen hat, dann kann man das wirklich sehr schnell für sich selber anpassen und durchführen.
Natürlich gilt trotz allem, dass man nie vor Problemen hundertprozentig geschützt ist, denn immerhin lade ich ja trotzdem den Source-Code von Software herunter, und der kann immer auch was enthalten, was ich vielleicht nicht möchte, und das kann ich mit meinem Laienwissen nicht prüfen.
Außerdem halte ich mich auch ganz strickt daran, wirklich nur das absolut Notwendige für mein IT-Leben darüber zu beziehen. Aktuell sind es 7 Pakete bei mir.
Übrigens waren es schon mal mehr, aber vieles habe ich in den letzten Jahren auch durch AppImage oder Flatpaks ersetzt.
Was ein externes Paket betrifft, ist das Risiko unabhängig von der Distribution gleich. Es wird sich nie ganz ausschließen lassen, dass ein Angreifer zuerst mithilft, später die Kontrolle über das Paket übernimmt und diese schließlich missbraucht. Solche Fälle hat es ja in der Vergangenheit schon gegeben. Ich denke speziell an das XZ Utils Backdoor (CVE-2024-3094) — und das war nicht einmal ein externes Paket.
Das AUR-System unterscheidet sich insofern von anderen externen Repositories für einzelne/wenige Zusatzpakete, als es ein zentrales Repository für alle externe Pakete darstellt. Das macht einen Angriff auf das Gesamtsystem so viel einfacher und konnte dazu führen, dass Hunderte von Paketen auf einmal kompromittiert wurden.
Insofern glaube ich also, dass der Umgang mit externen Repositories je nach Distribution doch merklich unterschiedlich ist. Dementsprechend bewerte ich das Risiko eines derartigen Angriffs je nach Distribution unterschiedlich.
Ich denke, man merkt meinem Text an, dass ich Arch Linux prinzipiell mag und auch den sehr einfachen, flexiblen Zugang zu AUR schätze. Aber es bleibt bei meiner (sicher sehr persönlichen) Einschätzung, dass ich Arch Linux in Kombination mit AUR-Paketen auf einem Arbeitsrechner nicht mehr nutzen mag.
Das Argument mit der manuellen Kontrolle der PKGBUILD-Dateien ist valide, aber selbst mit einem Blick auf diese Datei hätte ich das Problem und seine Auswirkungen nicht korrekt erkannt. Mag sein, dass andere Arch-Linux-Nutzer da einen schärferen Blick haben.
Vielen Dank für Deine Antwort.
Ich kenne mich mit anderen Distributionen und deren User-Paketsystem überhaupt nicht gut aus, daher vielleicht eine Bitte.
Wenn Du Dich damit schon so beschäftigt hast. Könntest Du eventuell mal den Workflow und die grundsätzlichen Release-Prozesse darstellen?
Also zum Beispiel von AUR vs. COPR, weil Du das angesprochen hattest.
Ich würde mich darüber freuen und würde dann vielleicht auch besser verstehen, was den Unterschied ausmacht.
Denn das einzige andere, was ich kenne, sind PPAs, und da ist es eigentlich genau wie bei AUR, nur dass es keinen einheitlichen Ort dafür gibt. Aber es wird auch absolut nichts kontrolliert.
Der Umgang mit externen Paketen/Repos je nach Distribution wäre in der Tat ein gutes Thema für einen weiteren Blog-Beitrag. Aber ich kann nicht versprechen, wann/ob ich dazu Zeit finde.
Da ich immer wieder Distributionhopping auf einem meiner Notebooks betreibe bin ich seit gut einem Monat wieder zurück in der Arch-Linux Welt und habe festgestellt das einige meiner Standard-Programme z.B. im Gegensatz zu Fedora oder TuxedoOS (ubuntu) nicht in den offiziellen Repos auftauchen und leider nur im AUR. Zum Glück war davon nichts betroffen. Das ein oder andere habe ich auch schonmal beim Hersteller per rpm oder deb Paket geladen und muss es sowieso manuell aktualisieren.
Da die KI-Workstation schon auf Fedora läuft kann ich die Bequemlichkeit für die daily driver auf jeden Fall nachvollziehen. Im Büro bin ich daher beim TuxedoOS von meinem Tuxedo Book geblieben. Privat teste ich da mehr, aber da ist es auch nicht schlimm wenn ich mir mein System mal lahmlege ;)
Ich habe seit ich denken kann eine kdbx Datei welche ich von Windows, Linux, MacOS, Android und iOS aus nutzen kann. Liegt in meiner Nextcloud. Die mobilen Keepass Ableger können auch ohne Sync direkt darauf zugreifen so das der Weg zu meiner Nextcloud immer der erste Weg auf einem neuen System ist. Zwischendurch wenn möglich kann man auch die kdbx immer wieder auf den aktuellen Stand bringen. Wir hosten bei uns im Büro eine eigene Passbolt Instanz als Gruppenlösung, auch dort kann man sich einzelne Pfade als kdbx exportieren wenn man Gefahr läuft einmal offline Zugriff zu benötigen. Passbolt ist auch OTP fähig, wenn der Algorithmus nicht zu schlecht ist wie beim Sophos Partnerportal.
Alles in einen Topf zu werfen war noch nie eine gute Idee. Der openSUSE Build Service meidet diese Schnapsidee und erlaubt jedem Benutzer eigene Repositories. Für die Übersicht gibt es opi:
OBS Package Installer (CLI)
Search and install almost all packages available for openSUSE and SLE:
- openSUSE Build Service
- Packman
- Popular packages for 3rd party vendors
Ich würde deswegen nicht gleich Arch Linux aufgeben wollen. In jedem System gibt es diese „Gefahr“. Ich meine, dass das AUR noch stärker gefährdet ist als PPAs oder Konzepte anderer Distributionen. Trotzdem wird sehr oft die Installation von Paketen aus dem AUR als Möglichkeit genannt und zu wenig auf die Gefahr hingewiesen. Beispiel: Druckertreiber. Ich weiß nicht, warum ich meinen Canon Treiber nicht selbst kompiliert kriege, aber die AUR-Version läuft sauber durch.
Inzwischen mache ich es so, dass ich kein AUR mehr verwende. Ja, das war bequem. Von manchen Apps muss ich mir nun selbst AppImages etc. suchen (Flatpaks kann ich nicht leiden).
Ich glaube auch, dass das AUR ein gewachsenes Problem hat: „Früher“ wurden die meisten Programme mit typischen Sprachen wie C, C++, Python etc. erstellt und kompiliert. Die Basis dafür war da und etabliert und sauber. Heutzutage gibt es jede Menge Programmiersprachen (wo ich mich öfter über den Sinn der Existenz frage). Jetzt mal eben ein Programm selbst kompilieren artet dann darin aus, dass ich auf einem gut genutzten System nahezu alles zum Compilieren installiert habe, aber selbst nicht gezielt brauche. Das empfinde ich als gewissen Overhead.
Vermutlich wird es bald darauf hinauslaufen, dass wir auch unter Linux mehr Sicherheitstools brauchen, die auch gewisse Zugriffe prüfen. Alles in meinem HOME-Verzeichnis kann von jedem Tool manipuliert werden, was im Prinzip nicht ganz ohne ist.
Zurück zur Ursprungsthematik: Ich würde bei Arch bleiben. Das war jetzt ein einmaliger Vorfall. Das Systemkonzept ist daran nicht schuld. Man hätte sich ja auch bei einem Dateisystembefehl vertippen können…
Ein Detail zum Webbrowser und zur Passwortverwaltung. Ich benutze Firefox seit Version 1.0 vor über 20 Jahren. Und seit einigen Jahren verwende ich KeePassXC mit dem dazu passenden Firefox-Plugin. Die *.kdbx-Datei hab ich in meinem OwnCloud-Dateiserver drin um sie auf Workstation und Laptop zu synchronisieren. Chrome hab ich zwar installiert, verwende ich aber nur für ein oder zwei Webseiten, die auf Firefox nicht funktionieren. Dass Chrome neuerdings ungefragt eine KI installiert und uBlock-Origin blockiert, wäre ja überhaupt ein Grund, dieses Stück Software endgültig rauszuwerfen.