AUR Compromised - 400+ packages affected - 20260611 (Übernommen aus CachyOS Forum)

[_Oskar_]

Kann es sein das es größtenteils verweiste pakete sind ?

Verwaiste Pakete anzeigen und löschen:

sudo pacman -Qtdq

Und löschen mit:

sudo pacman -Rns Paketname

Aber auch hier, vorher nach kontrollieren und sich sicher sein, was man löscht.

 

[Capucius]

Es sind sogar ausschließlich verwaiste Pakete, sonst hätten die Maintainer das ja nicht aus der Hand gegeben bzw. etwas bemerkt. Das ist typisch bei solchen Supply Chain Attacks. Peer review funktioniert ja schon, aber halt nur, wenn genug peers reviewen und irgendeine obskure mini-lib schaut sich halt nicht unbedingt jemand an. Das muss man dann halt selbst machen, wenn man irgendeinen abstrusen Kram ausprobieren will.

 

[Tekkla]

Naja, inwiefern? Es gibt bereits kuratierte sichere Repos, wenn man nur die benutzt ist man sicher. Wenn man irgendwelchen Kram von irgendwelchen Entwicklern installieren möchte bevor es durch einen zuverlässigen Reviewprozess von anderen gegangen ist, dann muss man es entweder selbst anschauen oder dem Entwickler vertrauen. Das lässt sich nicht ändern.

Dafür fehlen mir die Project-Insights. Dennoch wirft es kein gutes Licht auf das AUR, wenn so einfach scheint aberhunderte von Packages mit Malware zu infizieren. Dabei spielt es auch keine Rolle, ob die Projekte nun verwaist sind, oder nicht.

Vielleicht würde es helfen, wenn man die beim AUR hinterlegten Kontakte regelmäßig anmorst und um ein Lebenszeichen bittet. Oder Änderungen am veröffentlichten Paket trackt. Wenn sich da nichts tut , dann eine 90 Tage Vorwarnzeit einräumen und danach ggf. in ein AUR-ABANDONED Repository verschieben. Mit dem Setzen des Warnflags werden dann alle davon abhängigen Projekte ebenfalls über den hinterlegten Kontakt informiert und mit einem Dependency-Warnflag markiert. Das treibt man so lange, wie Dependencies bestehen. Reagieren die Leute darauf nicht, dann ist das halt so. Man sollte danach auch weiterhin Pakete aus dem ABANDONED Repository installieren können, doch die Installer müssen dann zweimal nachfragen, ob man sich des Risikos bewusst ist und das wirklich installieren will?

Ist jetzt nur mal so aus der Hüfte geschossen, aber so wie jetzt ist's halt auch totaler Bockmist.

Verwaiste Pakete anzeigen und löschen:

sudo pacman -Qtdq

Und löschen mit:

sudo pacman -Rns "Paketname"

Aber auch hier, vorher nach kontrollieren und sich sicher sein, was man löscht.

Oder noch einfach in einem Rutsch mit

sudo pacman -Rns $(pacman -Qdtq)

 

[Capucius]

Ich sage es jetzt mal ganz hart und ohne Rücksicht auf soziale Konventionen: es heißt nicht umsonst Arch _USER_ Repository. Es wurde schon immer darauf hingewiesen, dass das einfach irgendwelcher Kram von irgendwelchen Usern ist und man den PKGBUILD anschauen soll bevor man es lokal hinzufügt. Es wurde sogar darauf hingewiesen, dass man der aur-general Mailingliste folgt um dann frühzeitig Hinweise auf solche Ereignisse zu bekommen.

Und um die Diskussion gleich zu unterbinden, das ist nichts, was Gelegenheitsuser und Zocker unbedingt brauchen. Pakete zu erstellen und zu installieren ist advanced. Unter Windows entspricht das grob dem Compilen von DLLs, die man dann ins Systemverzeichnis kopiert. Wenn man das macht liefert man sich auch dem Ersteller der Sourcen aus.

Wenn man AUR benutzt, dann sollte man ein wenig nachlesen, was man da gerade macht und überlegen, ob das sinnvoll ist. In vielen Fällen gibt es Flatpaks, die ich Anfängern sehr viel mehr empfehlen würde. Weniger aus Sicherheitsgründen (obwohl die immerhin gesandboxt sind) sondern mehr weil man da auch wieder einigermaßen sicher ist wenn man die beobachteten Pakete von flathub benutzt.

 

[Flatline00]

Ich für meinen teil habe schon öfter wenn etwas nicht in den offiziellen repos ist und nur flatpak oder aur auswählbar ist, mich für aur entschieden. Flatpak hat mir schon zu oft Probleme durch das sandboxing gebracht.
Und öfters ist auch von den Erstellern der Software die empfohlene Art zu installieren auf Arch basierenden distros das AUR.
Außerdem es gibt auch immer wieder Sachen wie zb Snapraid und input-remapper wo ich nicht wüsste wo ich die gleichen Funktionen außerhalb des AUR kriegen kann.

Es ist immer leicht gesagt das man das AUR besser nicht nutzen soll, das einzige was ich unterschreibe ist das man sich der potentiellen Probleme bewusst sein muss und neben dem aufpassen was man installiert auch immer halbwegs aktuelle Sicherungen hat ( was eigentlich auch abseits davon vorhanden sein sollte ... )

 

[_Oskar_]

sudo pacman -Rns $(pacman -Qdtq)

Das funktioniert so nicht. ^^

 

[LongBananico]

Man kann ja mal damit anfangen zu schauen, ob man überhaupt betroffen ist.
grep -r 'atomic-lockfile' ~/.cache/yay
ggf. sudo.

 

[inhuman_nature]

Verwaiste Pakete anzeigen und löschen:

sudo pacman -Qtdq

Und löschen mit:

sudo pacman -Rns "Paketname"

Aber auch hier, vorher nach kontrollieren und sich sicher sein, was man löscht.

Für die DAUs, Noobs, faulen ... wie mich:
Das kann mensch unter CachyOS auch per Klicki-klicki machen unter dem Tool CachyOS Hello. Das mache ich seit einer Weile regelmäßig.

Das ist kein Befehl, damit läd man ein Bash Script runter und führt es aus... etwas, das man niemals einfach so machen sollte. Wenn dann macht man erstmal curl | less und schaut sich an, was das ist. Dann kann man es meinetwegen ausführen. So richtig lustig ist das eigentlich, weil das ganze Problem mit AUR ist, dass es ein usergefülltes Repo ist, und Leute Zeug ausführen, dass sie nicht gereviewed haben - und dann führen sie ein curl | bash aus, um zu schauen ob sie betroffen sind. Wie im verlinkten Thread auch betont, wer AUR benutzt sollte das Zeug schon reviewen, sonst ist es nicht sicher.

Auf meinem Schleppi im CachyOS sind laut dem Ausgabe-Befehl von @_Oskar_ 3 Pakete aus dem AUR installiert. Ich wüsste nicht, dass ich die (extra) installiert hätte. Ich meine, ich habe nicht mal AUR verwendet sondern wenn die Repo über die CachyOS-App-Install-GUI.
Mittels des von Oskar empfohlenen Befehls/Skripts ließ sich keine Infektion feststellen ... Okay, das stand ja auch im CachyOS-Forum.


Danke an Alle! Auch für Vorsichtshinweise und Kritik. Bleibt aber bitte nett zu einander!


Noch eine Noob-Frage:
Wäre Flatpak-Programm-Installationen eigentlich sicherer als bspw. AUR aufgrund deren Container-Struktur? Also, dass die quasi abgeschottet wären? Habe ich das richtig verstanden?

 

[Unfaced]

Ich hab kein betroffenes Paket aus dem AUR gehabt, zum Glück. Hoffe ihr auch. Phoronix.com gibt mittlerweile Entwarnung, dass alle gefährlichen commits entfernt wurden.

 

[_Oskar_]

Noch eine Noob-Frage:
Wäre Flatpak-Programm-Installationen eigentlich sicherer als bspw. AUR aufgrund deren Container-Struktur? Also, dass die quasi abgeschottet wären?

Teilweise ja, aber “sicherer” ist nicht pauschal korrekt Kollega.

Flatpak Apps laufen ja in einer Sandbox Umgebung mit eingeschränktem Zugriff auf einem System, wie wir ja wissen.

Wenn eine Flatpak App z.B kompromittiert ist, ist der mögliche Schaden oft begrenzter Natur, weil die App nicht einfach ein ganzes System “sehen” kann, eigentlich sind die Apps vom Rest des Systems weitgehend isoliert.

Papperlerpapp: Unter dem Strich kann man natürlich Argumentieren, dass Flatpak sicherer sein "kann bzw. ist."

(Ja ich weis, es gibt keine 100% Security, nur in einem Märchen.)

U.a wäre es auch mehr als sinnvoll, die Berechtigungen, die einzelne Flatpak Apps vorraussetzen, einmal nach zu kontrollieren, am besten schon „VOR EINER INSTALLATION", um dann gut zu überlegen, ob man zu einer Installation bereit ist.

Edit: So sind nun meine Gedanken dazu.

 

[Capucius]

Das ist korrekt, es ist ein bisschen wie bei Android. Eine Flatpak App kann auch breite Berechtigungen anfordern und wenn man die dann lässt hat sie vollen Zugriff. Man kann ihn aber auch einschränken.

Anschauen geht zum Beispiel mit

flatpak info --show-permissions <app-id>

Oder man benutzt flatseal zum Anschauen und Ändern der Rechte, das ist ein grafisches UI.

 

[_Oskar_]

Edit: Ich habe meinen Beitrag #3 auf Seite 1 richtiggestellt und editiert, damit es zu keinen Unstimmigkeiten kommt.

 

[Defenz0r]

Es gibt schon lange Security Tools fuer das AUR https://github.com/KiefStudioMA/ks-aur-scanner

Nicht zu verwechseln mit aurscan-git

 

[Capucius]

Es gibt schon lange Security Tools fuer das AUR https://github.com/KiefStudioMA/ks-aur-scanner

Nicht zu verwechseln mit aurscan-git

Wie praktisch, da hab ich ja dann die RegExp um die ich meinen Schadcode herumobfuscaten muss.

 

[Tekkla]

Das Desaster scheint noch größer zu sein, bzw. gibt es wohl noch eine andere Form von manipulierten Paketen im AUR.

Arch Linux AUR Hit By Another Wave Of Now More Sophisticated Malware Attack - Phoronix

www.phoronix.com

At this stage it's a bit surprising they don't completely shutdown AUR until they can better verify the security and safety of this user-supplied repository or at least implement new safeguards on changes.