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
Anmelden
Canonical erweitert seinen Livepatch Dienst nun auch auf ARM64 Systeme und ermöglicht damit sicherheitsrelevante Kernel Updates ohne Neustart auf performanter ARM-Hardware. Die neue Unterstützung richtet sich vor allem an Betreiber großer Serverlandschaften. Livepatch hält kritische Kernel Lücken geschlossen, während Dienste weiterlaufen. Das senkt Ausfallzeiten und schützt sensible Systeme an entfernten Standorten. Besonders ARM-Server und Edge-Geräte […]
