Arch Linux hält Malware-Vorfall nun für eingedämmt: Mehr als 1.500 Pakete betroffen

 (phoronix.com/news)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Im AUR-Repository mit Benutzerbeiträgen von Arch Linux wurden zunächst mehr als 400 mit Malware infizierte Pakete festgestellt, die endgültige Zahl stieg dann auf mehr als 1.500
  • In einem Update vor einigen Stunden war noch von rund 900 Paketen die Rede, die durch den Vorfall in dieser Woche infiziert wurden
  • Danach entfernten die Arch-Linux-Entwickler alle bekannten bösartigen Commits; die Zahl der betroffenen Pakete wurde auf 1.579 beziffert
  • Die Liste mit 1.579 Einträgen ist ebenfalls als umfangreiche, aber nicht vollständige Liste der betroffenen Pakete gekennzeichnet, sodass das tatsächliche Ausmaß größer sein könnte
  • Viele Softwarepakete im von Nutzern gepflegten Repository waren von diesem Sicherheitsvorfall betroffen; in einem separaten Update wurde zudem von einer weiteren, ausgefeilteren Malware-Angriffswelle berichtet

Überblick über den Vorfall

  • Der Vorfall begann, als im AUR-Repository mit Benutzerbeiträgen für Arch-Linux-Nutzer mehr als 400 mit Malware infizierte Pakete entdeckt wurden
  • Gegen Ende des Tages ging Arch Linux davon aus, dass alle betroffenen Commits bearbeitet worden waren, doch die Zahl der betroffenen Pakete stieg auf mehr als 1.500
  • Es handelte sich um einen Sicherheitsvorfall, der viele Softwarepakete im von Nutzern gepflegten Arch-Linux-Repository betraf

Veränderung des Ausmaßes

  • In einem Update vor einigen Stunden war festgestellt worden, dass durch den Vorfall in dieser Woche etwa 900 Pakete mit Malware infiziert worden waren
  • Laut der letzten Nachricht im Thread zum Sicherheitsvorfall entfernten die Arch-Linux-Entwickler anschließend alle ihnen bekannten bösartigen Commits
  • Die zitierte Liste weist die Zahl der von der Malware betroffenen Pakete mit 1.579 aus

Verbleibende Unsicherheit

  • Auch die Liste mit 1.579 Paketen ist als „umfangreiche, aber nicht vollständige Liste der betroffenen Pakete“ gekennzeichnet
  • Die veröffentlichte Zahl zeigt daher zwar ein bestätigtes großes Ausmaß, doch die Liste selbst deckt nicht alle betroffenen Pakete ab

Folge-Update

  • In einem separaten Update wurde anschließend berichtet, dass das Arch Linux AUR von einer weiteren Welle ausgefeilterer Malware-Angriffe getroffen wurde

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Ich frage mich, ob das AUR-Team schon einmal eine Post-Mortem-Analyse veröffentlicht hat
    Die Reaktion diesmal war beeindruckend schnell, aber ehrlich gesagt wirken Änderungen an den AUR-Richtlinien oder den Wrappern nötig
    So wie bei pnpm sollte man ein Mindestalter für Pakete festlegen können, und verwaiste Pakete sollten nicht von beliebigen Personen adoptiert werden dürfen
    Für Adoptionen könnte es ein globales Rate-Limit geben, das zugleich als Angriffssignal dient, und wie bei mehreren Unternehmen im NPM-Ökosystem wären auch Schwachstellen-Scans beim Veröffentlichen nötig
    Die meisten dieser Änderungen liegen allerdings eher bei Packaging-Helpern und Dritten als bei den AUR-Maintainern selbst

    • Es wäre besser, AUR-Pakete nach Namespaces aufzuteilen
      Dann würde Eigentümerschaft nicht verloren gehen, und ein Verwaisen wäre gar nicht erst nötig
    • Es gibt kein offizielles Tool zum Herunterladen von AUR-Repositories, daher hängt dieser Teil von der jeweils genutzten Vorgehensweise ab
    • Ich habe mich von pnpm inspirieren lassen und vor Kurzem einen Patch [1] für pakku erstellt, der ein Mindestalter für AUR-Pakete einführt
      [1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...
      [2] https://github.com/zqqw/pakku
    • Wenn man die Adoption verwaister Pakete zu stark einschränkt, können auch Pakete liegen bleiben, die eigentlich ordentlich gewartet werden könnten
      Beschränkungen sind nötig, aber etwa eine Adoption pro Monat für Nutzer, deren Konto seit einer gewissen Zeit besteht, erscheint angemessen
      Ohnehin wird kaum jemand auf lokal installierte AUR-Pakete automatische und ungeprüfte Updates anwenden, daher ist die Angriffsfläche bereits recht klein
    • Ein bloßer Schwachstellen-Scan hätte das vermutlich nicht erkannt
      Der Kern des Miasma-Wurms ist gerade, dass sich Signaturen und Helper-Ansätze zu schnell ändern
      Das verschlüsselte bösartige Implantat entschlüsselt seine Payload mit einem AES-128-GCM-Schlüssel, der je nach hochgeladenem GitHub-Speicherort unterschiedlich ist; außerdem ändern sich Methodennamen im Code dynamisch, und auch verschlüsselte Symbol-Offsets werden vermischt und wiederverwendet
      Als polymorphe Malware ist das ein Albtraum für signaturbasierte Werkzeuge
      APT28/29 scheinen sich bis zu einem gewissen Grad darauf zu verlassen, dass Microsoft Nutzer und Repositories auf GitHub, die als C2-Infrastruktur dienen, nicht schnell genug automatisch sperrt
      Man sollte darüber nachdenken, was das für die Sicherheitsstrategie bedeutet
      Sobald man Signaturen oder Strings scannen kann, befindet man sich bereits in einem Katz-und-Maus-Spiel mit einem vollautomatisierten Botnetz, und das kann man nicht gewinnen
      In der vergangenen Woche hat im Grunde nur socket.dev diese Implantat-Änderungen mitverfolgt; andere Tools kannten Miasma nicht einmal und haben es lediglich als neue Kampagne erneut entdeckt
      Es fehlte an Personal und Toolchains, um die Payload schnell genug rückzuentwickeln, um mit der Geschwindigkeit neuer Adapter für weitere Ökosysteme im 24-Stunden-Takt Schritt zu halten
      Vollautomatisierung bedeutet hier, dass in anderen Paket-Ökosystemen bereits nach weniger als 48 Stunden gestohlene Zugangsdaten verwendet wurden
      E-Mail-Adressen und Namen tauchen immer wieder auf, offenbar von Personen, die die Auswirkungen dieses sich selbst verbreitenden Wurms wahrscheinlich nicht verstanden haben
      Selbst Kompromittierungsindikatoren, die nach Paketen mit Abhängigkeit von bun suchen, helfen kaum weiter
      Die Malware kann einfach über andere Wege erneut heruntergeladen werden
      In der zweiten PyPI-Kampagne wurde, nachdem die erste Welle bösartiger Dropper aus der RedHat-Kampagne den PyPI-Maintainern aufgefallen war, auf komprimierte WHL-Dateien und automatisch ausgeführte setup.pth-Dateien umgestellt, die den Dropper nachladen
      Solange die Paketmanager dieser Ökosysteme nicht von Grund auf neu geschrieben werden mit chroot, Sandbox, Netzwerk- und Domain-Logs sowie per-Eintrag-Allowlists als Voraussetzung, bleibt die Verteilung von Malware über Supply-Chain-Angriffe eine realistische Strategie
      Das Repository mit den Mitigation-Tools ist [1], die technischen Details stehen im Blogbeitrag [2]
      Composer, Rubygems, NPM, PyPI und Go sind ebenfalls betroffen; das ist also ein Problem quer durch alle Paketmanager
      Es sollte viel offener darüber gesprochen werden, wie viel Sorglosigkeit und externes Vertrauen wir allen Paketmanagern aufbürden, denn das muss sich wirklich ändern
      [1] https://github.com/cookiengineer/antimiasma
      [2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • Als pacman-Wrapper, die direkt aus dem AUR installieren, aufkamen, fand ich das wirklich unangenehm
    Ich habe schon Dinge aus dem AUR installiert, bevorzuge aber meist den Weg über die Projektwebsite, statt Zwischenschritte zu überspringen
    Ein vorgefertigtes PKGBUILD ist den Komfort nicht wert, wenn man dafür das Risiko von Typosquatting oder dem Missbrauch von npm-/pip-Abhängigkeiten in Kauf nimmt

    • Wrapper wie yay zeigen bei jedem Update die PKGBUILD-Diffs an
      Bei der Erstinstallation prüft man die URL und ob Installationsskripte usw. plausibel sind; bei späteren Updates ändern sich meist nur Versionsnummer und Prüfsumme
      Ein Typosquatting-Angriff würde ziemlich deutlich auffallen
      Die Erstinstallation ist etwas anfällig, aber das gilt genauso, wenn man auf die Projektwebsite geht und auf Download klickt
    • Arch wird ständig vorgeworfen, elitär zu sein oder normale Nutzer abzuschrecken, aber es hat eindeutig Vorteile, gefährliche Dinge nicht zu leicht zu machen
      Das gilt auch in vielen anderen Bereichen des Lebens
      Nachdem ich Void Linux genutzt hatte, bin ich auch unter Arch auf aurutils umgestiegen, um eine ähnliche Trennung zu haben
      Man kann damit leicht selbst bauen, ein lokales AUR-Repository pflegen und dann per pacman installieren und verwalten, was den gesamten Upgrade-Prozess verbessert
    • Dieser Kompromiss ist für mich nichts wert
      Ich bin nicht zu Linux gewechselt, um wie ein Windows-Nutzer Websites aufzurufen, auf „download“ zu klicken und Zeit mit Programm-Updates zu verschwenden
      Die erwähnten pacman-Wrapper wirken auf mich allerdings riskant
    • Das AUR und ähnliche Repositories anderer Distributionen wirken auf mich wirklich beängstigend
      Es gibt so viele Tutorials, die deren Nutzung propagieren, dass ich mich schon fast wie der Merkwürdige fühle, nur weil ich nicht auf unbestimmte Zeit root-Rechte an Fremde ohne nennenswerte Peer-Review vergeben möchte
      Für die Installation einer einzelnen Paketversion, die gar keine oder nur selten Updates braucht, nimmt man damit ein solches Risiko in Kauf

  • Beim schnellen Überfliegen sieht es so aus, als wäre aus npm atomic-lockfile, js-digest und lockfile-js installiert worden.
    Die Liste der betroffenen Pakete steht unter [1].
    Ich habe nicht sofort herausgefunden, wie man das System prüft, also habe ich pacman -Qmi ausgeführt, um Informationen zu externen Paketen und Datumsangaben zu finden.
    Man muss die Ausgabe dann nur mit der Liste der betroffenen Pakete abgleichen.
    Außerdem kann man an mehreren Stellen nach Dateien wie den folgenden suchen:
    grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
    grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
    grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
    Ich weiß nicht, ob sich das Paket nach der Ausführung selbst löscht.
    Die anderen Informationen waren nicht besonders hilfreich, deshalb wollte ich wenigstens die grundlegenden Befehle teilen.
    [1] https://md.archlinux.org/s/SxbqukK6IA

    • So bin ich vorgegangen:
      Mit yay die Liste der aus dem AUR stammenden installierten Pakete holen: yay -Qam > packages_aur.last
      Von https://md.archlinux.org/s/SxbqukK6IA# die Liste herunterladen: curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
      Danach grep -wFf compromised.txt packages_aur.last ausführen; dann sollten die Pakete erscheinen, die in beiden Dateien vorkommen, also Pakete, die irgendwann kompromittiert waren.
    • Die Angreifer haben mindestens drei Node-Abhängigkeiten verwendet, daher reicht es nicht, nur nach atomic-lockfile zu schauen.
      Auch js-digest und lockfile-js wurden verwendet, und zeitweise wurde von npm auf bun umgestellt.
    • Das hier ist ebenfalls einen Blick wert: https://github.com/lenucksi/aur-malware-check
    • Es ist schon witzig, dass selbst in einem Szenario, in dem Malware in die Arch Linux AUR eingeschleust werden soll, die Malware immer noch über NPM verteilt wird.
      Eine legendäre Plattform.
    • Ich verstehe nicht, wie emacs-magit betroffen sein konnte.
      Soweit ich weiß, gibt es dort überhaupt kein JavaScript.

  • Wieder einmal eine berechtigte Erinnerung daran, keine beliebigen Drittanbieter-Pakete, -Bibliotheken oder -Anwendungen ohne Prüfung zu installieren.
    Zum Glück war dieser Vorfall auf das AUR beschränkt, und das AUR ist faktisch ein Paket-Repository, in das praktisch jeder etwas hochladen kann; anders als bei den offiziellen Repositories wird seit Langem immer wieder darauf hingewiesen, dass eine Prüfung vor der Installation nötig ist.
    Kommandozeilen-Tools wie rua erleichtern es, Pakete vor der Installation aus dem AUR zu prüfen.
    Wenn man auf demselben Rechner Bankgeschäfte erledigt, gibt es keine Ausrede dafür, die Software, von der man abhängt, nicht zu prüfen.
    Hält man die Zahl der Pakete niedrig und nutzt nur, was man braucht, wird auch das Upgrade deutlich einfacher.

    • Wie genau soll diese „Prüfung“ aussehen?
      Soll man vor der Installation jede einzelne Zeile Code vollständig lesen?
      Und was ist bei Binärpaketen?
      Soll man für alles, was man installiert, reproduzierbare Builds erstellen, oder auf eine quellbasierte Distribution umsteigen?
      Diese Verantwortung auf die Nutzer abzuwälzen, ist keine nachhaltige Lösung.
      Ein gewisser gesunder Menschenverstand hat hier seinen Platz, aber das den Nutzern anzulasten, ergibt keinen Sinn.
    • Das klingt zwar plausibel, ist am Ende aber ein nicht umsetzbarer Ratschlag und damit nicht nur nutzlos, sondern sogar schädlich.
      Es gibt auf der Welt weit mehr Code, als ein einzelner Mensch in seinem ganzen Leben lesen könnte.
      Wahrscheinlich hast du nicht einmal 1 % des Quellcodes gelesen, der gerade jetzt auf deinem Rechner läuft.
      Hast du deshalb aufgehört, Computer zu benutzen?
      Wie kann man dem vertrauen, was darin vor sich geht?
    • Ich finde, die Haltung „vor der Installation unbedingt prüfen“ sollte neu bewertet werden.
      Die Arch-Linux-Entwickler leisten hervorragende Arbeit, und ich bin ihnen persönlich dankbar, aber in einer Zeit, in der Supply-Chain-Angriffe so stark zunehmen, fühlt es sich an, als hätten Nutzerwarnungen allein ihre Grenzen schon vor langer Zeit erreicht.
      Eine einfache Lösung ist nicht in Sicht, aber Kontrollen wie Peer-Review vor der Veröffentlichung oder eine Karenzzeit könnten das Problem zumindest teilweise abmildern.
    • Das AUR wurde seit Langem als großer Vorteil von Arch geschätzt, aber diese Bequemlichkeit hatte ihren Preis.
      Dass ein Paket als verwaist markiert werden kann, man dann zwei Wochen wartet und, wenn der bisherige Maintainer im Urlaub ist und nicht antwortet, ein Angreifer als Maintainer eingetragen werden und ein bösartiges Update verteilen kann, ist absurd.
    • Ich sehe darin einen starken Beleg für die Kombination aus unveränderlichen Systemdateien, standardmäßigen benutzerlokalen Installationen und minimalen Rechten für Komponenten und Programme.
      Unveränderliche Distributionen, Wayland und Flatpak liefern zwar einige Bausteine, aber es bleiben wichtige Lücken.
      Das größte Problem ist, dass Sandboxing an Paketformate gebunden ist, und ich halte das für einen Fehler.
      Sandboxing und Zugriffsrechte sollten Funktionen auf Systemebene sein, sodass auch beliebige Binärdateien nicht so leicht ausbrechen können.
      Das löst das Problem zwar nicht vollständig, könnte aber den Schadensradius stark verkleinern und Nutzer von Distributionen zu weniger attraktiven Zielen machen.

  • Für alle, die sich Sorgen machen: Ich habe ein Repository gefunden, das aktuelle Skripte und Paketlisten sammelt, um bei der Prüfung auf eine Infektion zu helfen: https://github.com/lenucksi/aur-malware-check

    • Ich habe Claude dieselbe Liste (https://md.archlinux.org/s/SxbqukK6IA) gegeben und eine Malware-Prüfung durchführen lassen; dabei wurde im Wesentlichen dieselbe Prüfung vorgenommen wie in diesem Skript.
      Beides dürfte ausreichen.

  • Ich nutze zwar kein Arch Linux, aber viel NodeJS, und dort gibt es ähnliche Angriffe ebenfalls häufig.
    Ich frage mich in letzter Zeit, wo Paketmanagement eigentlich noch richtig und sicher betrieben wird.

    • AUR basiert auf Community-Unterstützung, daher gelangt Malware immer wieder in Pakete.
      Nicht in diesem Ausmaß wie diesmal, aber dass es von Grund auf nicht sicher ist, war klar, und überall gab es entsprechende Warnhinweise.
    • Linux-Distributionen machen das im Allgemeinen gut.
      Überall gibt es Maintainer, die Pakete prüfen und Verantwortung dafür übernehmen.
      Das gilt auch für Arch Linux.
      Die inhärente Unzuverlässigkeit von AUR wurde im Arch Wiki und in der umgebenden Kultur immer klar benannt und unterscheidet sich von Paketmanagern für Programmiersprachen wie npm oder pip.
    • Wenn man AUR nicht nutzt, ist Arch in Ordnung.
      Wenn man AUR nutzt, muss man alles überprüfen.
      Die meisten Distributionen sind ebenfalls in Ordnung, und die großen Distributionen haben eine ziemlich gute Bilanz.
    • Im Node-Ökosystem scheint es etwas zu geben, das es besonders anfällig macht.
      Vielleicht liegt es an einer überzogenen DRY-Kultur, vielleicht an etwas anderem.
      Ich habe jedenfalls noch nichts anderes benutzt, das einen ähnlich schlimmen Albtraum an Abhängigkeitsbäumen hatte.

  • Im AUR gibt es 15.000 verwaiste Pakete.
    Ich habe heute Morgen nach Popularität sortiert und drei kaum aktualisierte Pakete übernommen und gebaut.
    Wenn ihr verwaiste Pakete nutzt, könnte es sich lohnen, sie selbst zu übernehmen, bevor schlechte Akteure es tun.

  • Ich kann mich irren, aber diese Situation wirkt auf mich wie ein Signal für die zunehmende Verbreitung von Desktop-Linux.

  • Ich hatte nie einen Grund, AUR zu brauchen.
    Wenn ich ein Paket brauche, das nicht in den offiziellen Repositories ist, baue ich es selbst oder lade mir einen Binary-Release herunter, falls es einen gibt.
    So muss man beim Bauen kein root verwenden, und man kann Programme lokal für einen einzelnen Benutzer installieren, was für die meisten Desktop-Anwendungsfälle sogar besser passt.
    Zumindest entfällt im Vergleich zum Pfad Entwickler → Nutzer ein zusätzlicher Schritt Entwickler → Maintainer → Nutzer als mögliche Stelle für das Einschleusen von Malware.

    • makepkg verweigert die Ausführung als root ausdrücklich.
      Es läuft nicht als root, außer man umgeht das absichtlich etwa mit env EUID=123 makepkg ....
      Allerdings wäre es gut, wenn pacman Installationen auf Benutzerebene unterstützen würde.
      Derzeit verweigert es die Installation ohne root; umgehen kann man das, indem man sich über einen User-Namespace selbst auf root abbildet.

  • Ich verstehe, dass es diesmal um AUR ging.
    Unabhängig davon, ob es AUR ist oder nicht, wäre es hilfreich, wenn ihr teilen könntet, welche Schritte ihr bei der Paketinstallation durchgeht und wie ihr sicherstellt, dass das Paket und seine Abhängigkeiten keine Malware enthalten.
    Wenn man einmal ein bösartiges Paket installiert hat, scheint es wirklich schwer zu sein, das wieder rückgängig zu machen.