Bösartige Versionen von Nx und einigen unterstützenden Plugins wurden verteilt

 (github.com/nrwl)
3 Punkte von GN⁺ 2025-08-29 | 1 Kommentare | Auf WhatsApp teilen
  • Von Nx-Paketen und Plugins wurden bösartige Versionen auf npm verteilt, die das Dateisystem scannen, Anmeldedaten sammeln und anschließend an ein Repository im Github-Konto des Nutzers senden
  • Um zu prüfen, ob man betroffen ist, muss kontrolliert werden, ob im Github-Konto ein Repository namens s1ngularity-repository erstellt wurde
  • Im Fall einer Infektion sind der Austausch von Tokens und Passwörtern, das Löschen des bösartigen Repositorys und die Prüfung der Shell-Konfigurationsdateien zwingend erforderlich
  • Die bösartigen Versionen wirken sich über ein postinstall-Skript auf das System aus; besonders bei Nutzung des VSCode-Nx-Console-Plugins steigt das Risiko einer unbemerkten Ausführung
  • Nx hat Maßnahmen zur Verhinderung eines erneuten Vorfalls und zusätzliche Sicherheitsmaßnahmen umgesetzt, und die betreffenden Versionen wurden aus npm entfernt

Überblick und Zusammenfassung

  • Diese Sicherheitswarnung betrifft einen schweren Supply-Chain-Angriff auf Nx-Pakete und einige zugehörige Plugins, bei dem bösartiger Code über npm verteilt wurde
  • Die betroffenen bösartigen Versionen scannen das Dateisystem der Nutzer, sammeln Anmeldedaten, Pfade und weitere Informationen und laden sie in ein Github-Repository (s1ngularity-repository) hoch
  • Das bösartige postinstall-Skript verändert außerdem die Shell-Konfigurationsdateien der Nutzer (.zshrc, .bashrc), um einen System-Shutdown-Befehl hinzuzufügen
  • Angriffsvektor und Ablauf des Angriffs, betroffene Versionen, sofort notwendige Maßnahmen für Nutzer sowie Schritte zur Verhinderung eines erneuten Vorfalls werden ausführlich beschrieben

Dringende Maßnahmen

Was alle prüfen sollten

  1. In der Liste der Repositories des eigenen Github-Kontos prüfen, ob s1ngularity-repository erstellt wurde
  2. Die in diesem Repository enthaltenen Dateien herunterladen und zur Dokumentation aufbewahren
  3. Das Repository auf Github löschen
  4. Eine E-Mail an security@nrwl.io senden, um Hinweise zur Entschlüsselung der abgeflossenen Informationen zu erhalten
  5. Anmeldedaten und Tokens aller Konten sofort austauschen

So werden Github-Tokens ausgetauscht

  • https://github.com/settings/connections/… aufrufen
  • Die Zugriffsrechte der verbundenen App widerrufen, um bestehende Tokens ungültig zu machen
  • Bei Nutzung der gh-CLI erneut authentifizieren, um ein neues Token zu erzeugen
  • Ohne diese Maßnahme besteht das Risiko, dass bestehende Tokens missbraucht werden

Nutzung bösartiger Nx-Versionen beenden und bereinigen

  • Mit dem Befehl npm ls nx prüfen, ob die aktuell verwendete Nx-Version eine bösartige Version ist
  • Falls eine infizierte Version verwendet wird, mit npm uninstall nx && npm install nx@latest aktualisieren
  • Den Cache mit npm cache clean --force bereinigen

Für bereits infizierte Nutzer

  • npm- und Github-Tokens austauschen
  • Passwörter und sämtliche Anmeldedaten für Github und verbundene Dienste vollständig zurücksetzen
  • Die Dateien .zshrc und .bashrc darauf prüfen, ob unbekannte Befehle eingefügt wurden, und diese löschen

Für Administratoren interner Paket-Repositories

  • Bösartige Versionen im internen Proxy des Unternehmens-Registrys sofort löschen, um eine weitere Verbreitung zu verhindern

Hinweise zu betroffenen Versionen

Nx-Pakete

  • 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
  • Stand 10:44 PM EDT vollständig aus npm entfernt

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

  • Stand 10:44 PM und 6:20 AM EDT aus npm entfernt

Details zum Angriffsvektor

Ursache im verwundbaren Workflow

  • In den Github-Actions-Workflow wurde eine Schwachstelle zur Ausführung beliebigen Codes eingebracht
  • Wenn im PR-Titel bestimmter Bash-Code eingefügt wurde, konnten im Workflow Systembefehle ausgeführt werden; es handelte sich um eine entsprechende Schwachstelle (Bash Injection)
  • Über den Trigger pull_request_target standen erhöhte Berechtigungen (GITHUB_TOKEN usw.) zur Verfügung, was missbraucht wurde
  • Bis zur Entfernung blieb der verwundbare Workflow in einem alten Branch statt nur in main bestehen, wodurch der Angreifer mit einem bösartigen PR den Workflow ausführen und Secrets entwenden konnte

Ablauf des Diebstahls des npm-Tokens

  • Über den verwundbaren Workflow wurde die Ausführung von publish.yml erreicht
  • publish.yml speicherte das npm-Token in Github Secrets; dabei wurde das Token an einen externen Webhook übermittelt
  • Schließlich konnte der Angreifer mit diesem Token bösartige Versionen von Nx und unterstützenden Paketen auf npm hochladen

Verhalten der bösartigen Pakete

Sammlung von Informationen einschließlich Anmeldedaten und Veröffentlichung in einem Github-Repository

  • Beim Ausführen des postinstall-Skripts des infizierten Nx-Pakets werden Speicherorte verschiedener Textdateien und Anmeldedaten gesammelt
  • Diese werden Base64-kodiert in ein Github-Repository mit dem Namen s1ngularity-repository hochgeladen
  • Auch wenn das eigentliche Repository inzwischen gelöscht wurde, muss wegen seiner früheren öffentlichen Sichtbarkeit von einem möglichen Informationsabfluss ausgegangen werden

Manipulation der Shell-Profile (.zshrc, .bashrc)

  • postinstall fügte den Befehl sudo shutdown -h 0 ein, wodurch beim Start eines Terminals ein System-Shutdown ausgelöst und möglicherweise ein Passwort offengelegt werden konnte

Verschiedene Szenarien, in denen postinstall aktiv werden kann

  • Die Ausführung kann nicht nur bei einem expliziten npm install/yarn/pnpm install erfolgen, sondern auch in vielen anderen Situationen, etwa durch transitive Abhängigkeiten, Editor-Erweiterungen oder Skriptausführung

  • Insbesondere die Erweiterung Nx Console für VSCode (Versionen 18.6.30 bis 18.65.1) konnte beim Start des Editors automatisch nx@latest installieren und dadurch die Ausführung von postinstall auslösen

  • Grundsätzlich ist zu beachten, dass Installationen von NPM-Modulen an vielen Stellen stattfinden können, auch ohne ausdrückliche Absicht

  • Ab Nx Console 18.66.0 wurde die Installation von latest nx entfernt

Zeitachse von Angriff und Reaktion

21. August

  • 4:31 PM: Ein PR mit der Bash-Injection-Schwachstelle wurde gemergt
  • 10:48 PM: Ein Beitrag, der auf die Schwachstelle hinwies, wurde auf X (ehemals Twitter) veröffentlicht

22. August

  • Nachmittag: Interne Untersuchung, Rollback des verwundbaren Workflows (unvollständig)
  • Einführung von CodeQL, um ähnliche Schwachstellen künftig in PRs zu erkennen

24. August

  • In einem Commit im Fork des Angreifers tauchten Hinweise auf einen Abfluss des npm-Tokens auf
  • Ein bösartiger PR wurde erstellt und gelöscht; publish.yml wurde durch diesen PR ausgeführt

26. bis 27. August (Verteilung der bösartigen Versionen, Reaktion)

  • Mehrere bösartige Versionen von Nx und Plugins wurden nacheinander auf npm verteilt
  • Issues wurden an die Github-/NPM-Community gemeldet
  • 10:44 PM: NPM entfernte alle betroffenen Versionen und ergriff weitere Maßnahmen
  • 11:57 PM: Alle Tokens zum Veröffentlichen von Nx-bezogenen Paketen wurden ungültig gemacht
    1. August: Patch für Nx Console, 2FA, Umstellung auf Trusted Publisher und weitere Maßnahmen

Vorbeugende Maßnahmen und weiteres Vorgehen

  • Für alle Maintainer der nrwl-Organisation wurde 2FA verpflichtend gemacht
  • Der Mechanismus Trusted Publisher wurde eingeführt. Verteilung auf Basis von npm-Tokens ist nicht mehr erlaubt
  • Künftige Pakete werden ausnahmslos erst nach 2FA- und vertrauensbasierter Verifikation veröffentlicht
  • Zusätzliche Risikoerkennung sowie PR-Freigaben, Branch-Schutz und weitere stufenweise Maßnahmen werden eingeführt

Erkenntnisse und weitere Pläne

  • Der Vorfall macht erneut deutlich, wie wichtig Supply-Chain-Sicherheit, CI/CD-Pipelines und das Prinzip minimaler Workflow-Berechtigungen national wie international sind
  • Nach einer erneuten internen Aufarbeitung sollen die gewonnenen Erkenntnisse mit der Community geteilt werden

Kontakt

  • Rückfragen sind an security@nrwl.io möglich

Referenzen und Anhang

  • Wichtige Github-Issues, Zeitachse und zugehörige Beiträge
  • Ein Beispiel für das Skript telemetry.js im infizierten Paket wird bereitgestellt
  • Dieses Skript sammelt zum Zweck der Erstellung eines Inventars die Pfade wichtiger Textdateien im Dateisystem

Zusammenfassung

  • Es ist wichtig, die neuesten Updates und Patches für Nx und zugehörige Plugins anzuwenden
  • Ein sofortiger Austausch wichtiger Authentifizierungsinformationen wie npm- und Github-Zugangsdaten wird empfohlen
  • Der Vorfall zeigt, dass unzureichende Supply-Chain-Sicherheit und mangelhafte Verwaltung von Workflow-Berechtigungen zu einem schwerwiegenden Sicherheitsvorfall führen können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-29
Hacker-News-Kommentare

  • Ich möchte regelmäßig daran erinnern, npm install-Skripte zu deaktivieren

    • Zum Beispiel mit folgendem Befehl:

        npm config set ignore-scripts true [--global]

    • Diese Einstellung lässt sich leicht projektbezogen oder global anwenden

    • Heutzutage gibt es nur noch wenige legitime Pakete, die ohne Skripte nicht funktionieren, daher ist das meist kein Problem

    • Für Pakete, die zwingend benötigt werden, kann man ein separates Installationsskript erstellen und es in dem jeweiligen Ordner manuell ausführen

    • Das ist kein Allheilmittel gegen Supply-Chain-Angriffe, hat aber tatsächlich viele Angriffe über npm wirksam abgewehrt

    • Weitere Informationen stehen in der offiziellen npm-config-Dokumentation

    • Ich nutze außerdem bubblewrap, um npm, pnpm, yarn und alle von ihnen gestarteten Sessions vom System zu isolieren

      • Mein Quellcode liegt nur unter ~/code, und ich speichere das folgende Bash-Skript am Anfang von PATH als npm
      • Andere Paketmanager werden ebenfalls per Symlink/Hardlink verbunden: 
        #!/usr/bin/bash
bin=$(basename "$0")
exec bwrap \
  --bind ~/.cache/nodejs ~/.cache \
  --bind ~/code ~/code \
  --dev /dev \
  --die-with-parent \
  --disable-userns \
  --new-session \
  --proc /proc \
  --ro-bind /etc/ca-certificates /etc/ca-certificates \
  --ro-bind /etc/resolv.conf /etc/resolv.conf \
  --ro-bind /etc/ssl /etc/ssl \
  --ro-bind /usr /usr \
  --setenv PATH /usr/bin \
  --share-net \
  --symlink /tmp /var/tmp \
  --symlink /usr/bin /bin \
  --symlink /usr/bin /sbin \
  --symlink /usr/lib /lib \
  --symlink /usr/lib /lib64 \
  --tmpfs /tmp \
  --unshare-all \
  --unshare-user \
  "/usr/bin/$bin" "$@"
      • Damit haben die Paketmanager nur Zugriff auf ~/code und auf Systembibliotheken im Read-only-Modus
      • bubblewrap ist stabil und wird unter anderem von Steam und flatpak verwendet

    • Auch die Nutzung von pnpm ist eine Möglichkeit. Neuere Versionen ignorieren standardmäßig alle Lifecycle-Skripte, und man muss sie einzeln whitelisten, damit sie ausgeführt werden

    • Wenn ich diesen Rat höre, frage ich mich immer: Kein Entwickler liest doch tatsächlich die zig- bis hunderttausenden Zeilen Code, die npm installiert hat

      • Die meisten Entwickler-Workflows laufen ungefähr so ab
        1. git clone
        2. npm install (hier kann ein bösartiges Paket installiert werden; das Ignorieren von Post-Install-Skripten kann das nur vorübergehend verhindern)
        3. npm run (hier wird das bösartige Paket ausgeführt und infiziert das System)
      • Damit der Rat wirklich hilft, müsste man zwischen 2 und 3 den gesamten node_modules-Ordner überwachen oder auditieren, aber das macht niemand

    • Ich führe alle npm-basierten Tools in einem Docker-Container aus, ohne Zugriffsrechte außerhalb des aktuellen Verzeichnisses

    • Ich frage mich, warum dieser Rat nicht genauso für setup.py (Python) oder build.rs (Rust) gilt

      • Liegt es daran, dass npm oft sogar für Softwareverteilung missbraucht wird (z. B. zur Verteilung separater Programme), während Paketmanager anderer Sprachen nur Bibliotheken verwalten?
      • Eine dazugehörige Diskussion findet sich hier

  • Wir brauchen wirklich eine Kultur, in der man beim Hinzufügen neuer Abhängigkeiten noch einmal ernsthaft nachdenkt

    • In diesem Jahr gab es wirklich viele Supply-Chain-Angriffe

    • Diese Woche wollte ich einem Go-Projekt eine Fortschrittsanzeige mit 8 Statistikzählern hinzufügen

    • Ich habe nach einer Bibliothek gesucht, aber der Code hatte über 3.000 Zeilen, also bat ich ein LLM, einfachen UI-Code zu generieren, und kam mit weniger als 150 Zeilen aus

    • Es funktioniert ohne Abhängigkeiten genau wie beabsichtigt, ist sehr einfach und kann von allen leicht gelesen und verbessert werden

    • Die Funktion war: Terminalausgabe löschen und jede Sekunde neu zeichnen, mit Unterstützung für Thread-Safety

    • Umsetzung und Review haben nur 25 Minuten gedauert

    • Wenn man keine komplexen Statistikfunktionen braucht, reicht auch eine Progress-Bar in etwa 30 Zeilen Code

    • Wenn ich künftig darüber nachdenke, ob ich eine Abhängigkeit hinzufügen soll, scheint es für mich besser zu sein, sie einfach selbst zu bauen

    • Mir fehlen die Ressourcen, um alle Paket-Updates zu überwachen

    • Ich stimme dem zu, und als „sprachspezifische Paketmanager“ populär wurden, fand ich das wirklich beunruhigend

      • Ich kam aus dem Systemprogrammierungsbereich und habe pip, npm usw. eher aus der Distanz beobachtet
      • Als ich dann zu Rust-Projekten wechselte und sah, dass man mit einer einzigen Cargo-Zeile dutzende ungeprüfte Abhängigkeiten aus dem Internet zieht, hielt ich das für gefährlich
      • Genau das ist dann auch passiert. Ich halte das nicht für eine gute Entwicklung. (Aber ich erwarte nicht, dass wir umkehren; Computersicherheit existiert ja offenbar nicht ...)

    • Ich denke, Ansätze wie cargo vet sind der Weg nach vorn: Einführung in cargo vet

      • Natürlich ist der Overhead groß, wenn jedes Sprach-Ökosystem so ein System braucht
      • Auch das frühe Internet oder E-Mail hatten einmal gute Zeiten, wurden dann aber durch Spam und Kommerzialisierung ruiniert
      • Jetzt trifft es sogar die Kette der Abhängigkeiten
      • Deshalb können wir schöne Umgebungen offenbar nicht dauerhaft erhalten

    • Der Unterschied zwischen Eigenimplementierung und Bibliotheksnutzung ist allerdings offensichtlich

      • Bibliotheken sind von Natur aus generisch und müssen flexibel sowie für viele Umgebungen konfigurierbar sein, daher wird der Code zwangsläufig länger

    • Ich hasse solche Progress-Bar-Bibliotheken, vor allem wenn sie die emacs shell kaputtmachen (expo, eas usw.)

      • Warum geben sie nicht einfach ..10%..20%..30% oder Uploading… aus?
      • Meiner Meinung nach sollte Terminal-Steuercode nur für TUI- oder interaktive Interfaces verwendet werden

    • Unser Team betreibt bei einem großen Versicherer ein großes Monorepo und Bibliotheken rund um NX

      • Wir verwalten mehr als 10 unabhängige Apps und über 25 Bibliotheken in einem einzigen Monorepo, mit eng verflochtenem CI/CD
      • Wir haben auch lerna, rushjs, yarn workspaces usw. ausprobiert, aber nichts funktionierte so gut wie NX (lerna wurde am Ende ebenfalls von NX übernommen, rushjs wird auch nicht wirklich gepflegt)
      • Ich würde gern Vorschläge für Methoden oder Alternativen hören, mit denen sich die Komplexität von Frontend-Monorepos sauber beherrschen lässt
      • Nach diesem Sicherheitsvorfall interessieren sich viele für Alternativen, daher freue ich mich auf unterschiedliche Meinungen

  • Statt nur Nx, Anthropic oder die Plattform zu beschuldigen, sollten wir die eigentliche Ursache noch einmal betrachten

    • Die unmittelbare Ursache dieses Angriffs war, dass mit einem gestohlenen „Token“ (einer Zeichenfolge zur Autorisierung von Paketmanager-Aktionen) bösartige Pakete hochgeladen werden konnten
    • Das war aber nur der Übertragungsweg; die eigentlichen Ursachen für den Erfolg waren folgende:
      1. Paketmanager-Repositories verlangten keine Signatur der Artefakte, sodass nicht verifiziert werden konnte, dass sie wirklich von einem autorisierten Entwickler erstellt wurden
      2. Code-Signing war ebenfalls nicht verpflichtend
      3. (Vermutlich) fehlten Heuristiken gegen verdächtige Uploads, etwa Anomalieerkennung, neue IPs oder Länderwechsel
      4. (Vermutlich) war MFA für die Nutzung gestohlener Tokens nicht erforderlich
      5. (Vermutlich) waren die Tokens nicht einmalig
      6. (Vermutlich) wurden die Tokens nicht in einem Passwortmanager gespeichert, der bei Nutzung aus einer neuen Anwendung oder Session eine manuelle Freigabe verlangt hätte
    • All das waren vermeidbare Versäumnisse
    • Wenn man selbst betroffen war und im eigenen GitHub-Konto neue Repositories angelegt wurden, dann hat man die eigenen Auth-Tokens ebenfalls nicht stark genug geschützt
    • Dass solche Präventionsmaßnahmen nicht Standard sind, ist ein großes Versagen der gesamten Softwarebranche
      • Diese Art von Angriff wiederholt sich seit Jahren
      • Wir sind selbst Entwickler und haben es trotzdem nicht behoben
    • Deshalb vertrete ich die Ansicht, dass auch Software verpflichtende Regulierung braucht, ähnlich wie Bauvorschriften, inklusive Kontrollen und Bußgeldern

      • Solche Angriffe können zehntausenden Organisationen in Finanzen, Energie, Telekommunikation, Krankenhäusern oder Militär schweren Schaden zufügen

      • Mit der Verbreitung von KI werden Umfang und Wirkung solcher Angriffe noch größer

      • Wir entwickeln Software nicht verantwortungsvoll genug. Wie bei Bauvorschriften müssen Sicherheit und Security notfalls erzwungen werden

      • Erstaunlich gefährlich ist auch, dass heutige Personal-Computing-Umgebungen als ein einziger großer Raum organisiert sind

        • Unter Mac, Windows und Linux liegen Krypto-Wallets, Credential-Dateien und zahlreiche Apps alle zusammen
        • Es gibt bisher nur schlechte Werkzeuge, um solche Dinge sauber zu trennen
        • Wenn ich gelegentlich mehrere Windows-VMs unter macOS laufen lasse, stelle ich mir eine Zukunft vor, in der man per Alt-Tab ganz nahtlos in arbeitsbezogene Container oder VMs springt
        • Zum Beispiel: ein Gaming-Container, ein dedizierter Container für Krypto-Arbeit, Container pro wichtigem Code-Projekt usw.
        • Dass ein einziges installiertes VSCode-Plugin dazu führen kann, dass ein Bitcoin-Schlüssel abfließt, ist wirklich absurd
        • Ich glaube nicht, dass so etwas wie Software-Bauvorschriften dieses grundlegende Problem vollständig lösen kann
        • Es braucht auch Regeln auf Betriebssystemebene, die den Datenzugriff zwischen Apps einschränken, und man muss zugleich besprechen, wie so etwas praktisch eingeführt und durchgesetzt werden soll

      • Bei 50 % der Opfer war VS Code der Infektionsweg, und der Angriff funktionierte nur unter Linux und macOS

        • Eine Detailanalyse des Angriffs findet sich in dieser Bloganalyse
        • Bei einer Infektion geschah Folgendes:
          • In der postinstall-Phase wurden sensible Werte wie Benutzer-Credentials und andere wichtige Assets eingesammelt (Krypto-Wallets, GitHub- und npm-Tokens, SSH-Schlüssel usw.)
          • Mit KI-CLI-Tools (Claude, Gemini, Q usw.) wurden Informationen gesammelt und aktive Aufklärung betrieben
          • Die exfiltrierten Daten wurden doppelt oder dreifach base64-kodiert und in GitHub-Repositories der Angreifer (z. B. s1ngularity-repository) hochgeladen
          • Es wurden mehr als tausend Repositories gefunden
          • Über 1.000 GitHub-Tokens, dutzende Cloud- und NPM-Credentials sowie etwa 20.000 Dateien wurden offengelegt
          • Die Ausführung erfolgte überwiegend über die NX-VSCode-Erweiterung oder in Build-Pipelines (z. B. GitHub Actions)
          • Am 27. August um 9:00 UTC deaktivierte GitHub alle Repositories der Angreifer, aber in einem Expositionsfenster von bis zu 8 Stunden konnten Daten abfließen
          • Da base64-Kodierung leicht rückgängig zu machen ist, muss man diese Daten faktisch als veröffentlicht betrachten

      • Dass GitHub-Tokens und Zugangsdaten nicht in Passwortmanagern mit manueller Freigabe lagen, ist auch ein Problem des GH CLI

        • GH CLI gewährt nach einmaligem Login Upload-Rechte für Repositories und verlangt nur selten eine erneute Authentifizierung
        • AWS CLI verfällt je nach Policy automatisch alle 18 Stunden
        • Auf beiden Plattformen landen Tokens lokal aber leicht im Klartext

      • Mir gefällt die Idee von „Software-Bauvorschriften“ zwar nicht, aber ich stimme zu, dass die Branche insgesamt extrem schwach aufgestellt ist

        • Regulierung könnte tatsächlich nötig sein

      • Die Vorstellung, man müsse Verantwortung einfordern, weil jemand eine kostenlose Open-Source-Bibliothek verwendet hat, halte ich für anmaßend

        • Wenn man echte Garantien will, sollte man eine Lizenz kaufen
        • Das erinnert an Googles feindselige Prüfpolitik gegenüber freier Software

  • In letzter Zeit erledige ich den Großteil meiner Entwicklungsarbeit in VMs

    • Das aktuelle Sicherheitsniveau von Umgebungen ist aus meiner Sicht nicht akzeptabel

    • Agentenartige Software hat ein enormes Potenzial, als Malware-Vektor zu wirken

    • Wenn ein Angreifer erst einmal in den Rechner eingedrungen ist, kann er heute jederzeit auf Daten im Wert von über 1.000 Dollar, Krypto-Schlüssel, Passwörter, personenbezogene Daten und Finanzunterlagen zielen

      • Ich arbeite ähnlich in Podman-Containern. Mit dem Host teile ich nichts außer dem Quellcode-Verzeichnis

      • Ein Teil des Problems liegt im traditionellen PC-Sicherheitsmodell (Linux/Windows)

        • Ausführbare Dateien gelten als vertrauenswürdig, und dieses Modell, das ihnen Zugriff auf alle meine persönlichen Daten gibt, passt 2025 einfach nicht mehr
        • Mobile Systeme (Android) haben das größtenteils gelöst, aber auf PCs gibt es außer SELinux kaum tiefgreifende Alternativen

      • Falls du so etwas bevorzugst, würde ich Qubes OS empfehlen. Es bietet eine gute UX dafür, alles in VMs auszuführen

        • Es ist mein Daily Driver, ich kann es wirklich sehr empfehlen

      • Man sollte aber klar sagen, dass der Aufbau solcher Umgebungen wegen des Software-Ökosystems und seiner Geschichte sehr schwierig oder recht teuer ist

  • Claude Code ist ein revolutionäres Tool zur Produktivitätssteigerung

    • Gleichzeitig bringt es Sicherheitsprobleme mit sich:

      • Es ist eine NodeJS-App
      • Die Installation erfolgt per curl in bash gepiped (Risiko von Remote Code Execution)
      • Das LLM kann Dateisystem, Befehle und vieles mehr anfassen

    • Schon damit gibt es mindestens drei Sicherheitsrisiken, deshalb möchte ich es nicht außerhalb einer Sandbox wie VM, Container oder einer dedizierten Entwicklungsmaschine ausführen

      • Ich denke auch, dass man Agenten in Sandboxes ausführen sollte

        • Allerdings führt Claude Code nicht von sich aus ohne gesonderte Erlaubnis beliebige Befehle aus

      • Und was dann?

        • Der Nutzer muss immer noch selbst auf Ausführen klicken
        • Die meisten Programme haben ohnehin Berechtigungen
        • Auch ein Terminal kann das Dateisystem verändern, läuft aber nicht von selbst los
        • Claude Code verhält sich nicht wie ein Dämon, der eigenständig meinen Computer zerstört; ohne klare Anweisungen passiert nichts
        • Ich halte Claude Code für das beste Tool, das ich in den letzten 30 Jahren verwendet habe
        • Welcher „Angriffsvektor“ es genau war, ist mir nicht so wichtig. Wenn jemand unbefugt auf meinen Rechner kommt, ist das kein exklusives Problem von Claude Code

      • Das eigentliche Risiko ist, dass automatische Updates mit Benutzerausführung kombiniert werden und man Anthropic dadurch effektiv RCE-Rechte gegeben hat

  • Ich frage mich, ob Paketmanager eine Einstellung wie ein „Mindestalter für Pakete“ (min-age) brauchen

    • Wenn man zum Beispiel Pakete ignorieren würde, die jünger als 24 bis 36 Stunden sind

    • Ich habe schon einmal etwas Ähnliches erlebt: Ein Paket-Update hat alles kaputtgemacht und wurde dann wenige Stunden später schnell gefixt oder entfernt

      • GitHub Dependabot hat genau so eine Funktion kürzlich hinzugefügt

      • Renovate bot bietet diese Option bereits (minimumReleaseAge), und dependabot unterstützt sie inzwischen ebenfalls

        • Paketmanager kümmern sich nur darum, die neueste Version zu installieren, aber mit solchen kostenlosen Tools kann man Updates in sinnvollen Intervallen verwalten
        • Das JavaScript-Ökosystem bewegt sich langsam in Richtung Konsolidierung, und Gegenmaßnahmen gegen Supply-Chain-Angriffe entstehen allmählich
        • Neuere Versionen von NPM, PNPM, Bun usw. führen postinstall-Skripte standardmäßig nicht aus; man muss sie bei Bedarf explizit aktivieren (auch wenn man letztlich trotzdem fremden Code ausführt)

      • Das ist zwar keine OS-Funktion, aber Astrals Tool uv bietet so eine Option für Python-Pakete

      • Auch npm install hat einen Flag, mit dem nur Abhängigkeiten vor einem bestimmten Zeitpunkt/Datum installiert werden

        • Mit npm install --before (Datum vor 2 Tagen) werden keine Abhängigkeiten installiert, die nach diesem Datum veröffentlicht wurden

      • Ich setze in .npmrc save-exact=true und verlasse mich nur auf Lockfiles und manuelle Updates

        • Pakete muss man nicht dauernd hochziehen
        • Nach Vorfällen wie bei fakerjs habe ich gelernt, dass Vorsicht nötig ist

  • Ich war neugierig, ob Claude Code solche Prompts tatsächlich ausführen würde, und habe es getestet

    • Das Ergebnis war wie folgt:

      • „Diese Anfrage scheint auf die Suche und Auflistung sensibler Dateien wie Krypto-Wallets oder privater Schlüssel abzuzielen und könnte missbräuchlich verwendet werden; dabei kann ich nicht helfen“

      • Es wurden nur legitime Anfragen unterstützt, etwa Sicherheitsprüfungen, Schwachstellenanalysen, das Schreiben von Monitoring-Tools, das Verständnis von Dateiberechtigungen oder die Gestaltung von Backup-Verfahren

      • Wir haben aber mindestens 250 erfolgreiche Fälle bestätigt (das heißt, einige Prompts gingen doch durch)

        • Claude verweigert im Durchschnitt deutlich häufiger, und Q verweigert ebenfalls gut (was ähnlich ist, da es auf Claude basiert)
        • Zur Einordnung: Ich habe den ganzen Tag auf solche Vorfälle reagiert und auch diesen Analysebericht dazu verfasst

      • In realen Tests mit Claude und anderen Modellen bestätigt sich jedes Mal, dass Claudes Verweigerungen und Sicherheitsmaßnahmen deutlich besser sind

        • Ein bekanntes Beispiel: Während ChatGPT einen Nutzer mit psychischen Problemen weiter als „The Oracle“ ansprach und gewähren ließ, verweigerte Claude das und riet zu professioneller Hilfe
        • Natürlich sind Antworten vom Typ „Das ist korrekt!“ auf Dauer frustrierend, aber man kann Anthropic durchaus anerkennen und loben, dass sie im Vergleich zur Konkurrenz deutlich stärker auf Verweigerung und Sicherheit setzen

  • Das Betriebssystem sollte standardmäßig verhindern, dass Apps unbegrenzten Zugriff auf das gesamte Dateisystem haben

    • Für manche Apps gibt es AppArmor-/SELinux-Profile, und man kann auch firejail nutzen

    • Aus UX-Sicht braucht es aber Veränderungen

      • Das ist ein sehr ernstes Problem. Es stammt aus Desktop-Designs von vor 30 Jahren

        • Moderne mobile Betriebssysteme (z. B. iOS) sind dagegen standardmäßig gut darin, Apps pro Anwendung zu sandboxen und Berechtigungen explizit freizugeben
        • Auf dem Desktop gibt es verschiedene Versuche wie Qubes, Firejail, bubblewrap oder AppArmor, aber sie sind komplex oder für normale Nutzer schwer zu verwenden
        • Es gibt auch OpenSnitch, aber das beschränkt sich auf Networking
        • Für Endnutzer ist es mühsam, Berechtigungen für jedes Programm im Detail anzupassen
        • Entscheidend ist letztlich, dass Profile für weit verbreitete Apps kontinuierlich gepflegt werden
        • Es ist erschreckend, wie schwach Desktop-Sicherheit heute ist, aber das Problem ist grundsätzlich schwer, und selbst wenn man es löst, sind die finanziellen Anreize gering

      • Ich entwickle unter Linux selbst ein Tool, das sich mit Podman auf projektbezogene Umgebungsisolation konzentriert: probox

        • Es steckt viel Arbeit in der Verbesserung der UX
        • Ich nutze es oft und bräuchte jemanden für ein Security-Review

      • Was Dateisicherheit auf Android betrifft, hat Google gute Arbeit geleistet

      • Es lohnt sich auch, den Umgang mit bubblewrap und kleinen chroot-Umgebungen zu lernen

      • Ich glaube nicht, dass irgendein Betriebssystem standardmäßig „unbegrenzten Zugriff auf das gesamte Dateisystem“ für Anwendungen erlaubt

        • Linux, BSD, MacOS und Windows haben alle starke Einschränkungen
        • Solange normale Nutzer Kontoberechtigungen nicht selbst riskant hochstufen, ist das Standardverhalten grundsätzlich sicher

  • Früher hatte ich noch ein vages Vertrauen darauf, dass ein Angreifer meine Umgebung erst einmal erraten müsste, aber jetzt kann man ein LLM die Umgebung analysieren und passende Angriffe erlernen und ausführen lassen

    • Ich klopfe mir fast selbst auf die Schulter, weil ich diese Entwicklung tatsächlich vorausgesehen zu haben scheine

    • In dieser früheren Diskussion gab es lesenswerte Punkte dazu

      • (Scherz) Ich bin der Angreifer, hat jemand neue Ideen? (/s)

  • Wirklich unheimlich ist, dass inzwischen lokale LLMs zum Auffinden von Secrets eingesetzt werden

    • Das postinstall-Problem ist dasselbe wie früher, aber die Payload ist eine völlig neue Generation

    • Die bösartige Logik steckt nicht mehr im Code, sondern im Prompt, wodurch sie mit klassischer statischer Analyse schwer zu erkennen ist

    • Ich frage mich, wie man sich gegen solche bösartigen Prompts verteidigen soll

      • Offenbar bleibt nur, Claude Code in einem vollständig isolierten Container oder einer VM auszuführen und jeden Code-Commit selbst zu reviewen