„Es gibt keine Möglichkeit, das zu verhindern“, sagt der einzige Paketmanager, bei dem so etwas regelmäßig passiert

 (kevinpatel.xyz)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Durch einen Supply-Chain-Angriff auf das npm-Registry wurden Millionen von Unternehmensanwendungen kompromittiert und Datensätze von Milliarden Nutzern offengelegt, doch das Ökosystem nimmt dies hin, als sei es unvermeidlich
  • Senior Frontend Engineer Mark Vance kritisiert die Realität, sich selbst für die Umwandlung eines einzelnen Strings in Großbuchstaben auf eine 40 Ebenen tiefe, verschachtelte Abhängigkeitskette ungeprüfter Pakete zu verlassen
  • Dass ein lange vernachlässigtes Utility-Paket übernommen und ein Crypto-Miner in Produktions-Builds weltweit eingeschleust wird, wird wie eine Naturkatastrophe behandelt
  • Das Node.js-Ökosystem nimmt bösartige Remote Code Execution wie eine unvorhersehbare Tragödie hin, während DevOps-Teams damit beschäftigt sind, AWS-Schlüssel auszutauschen
  • Go-, Rust- und native-Web-API-Ökosysteme bilden mit starken Standardbibliotheken und kryptografischer Verifikation einen Kontrast, der die Abhängigkeit von Drittanbieter-Code reduziert

Satire auf Supply-Chain-Angriffe bei npm

  • Durch einen Supply-Chain-Angriff auf das npm-Registry wurden Millionen Unternehmensanwendungen kompromittiert und Datensätze von Milliarden Nutzern offengelegt, doch Entwickler im JavaScript-Ökosystem nehmen dies so hin, als sei es „völlig unvermeidbar“ gewesen
  • Senior Frontend Engineer Mark Vance sieht in der Realität, sich für das Konvertieren eines einzelnen Strings in Großbuchstaben auf einen 40-stufigen, verschachtelten Abhängigkeitsbaum ungeprüfter Pakete zu verlassen, den Preis moderner Web-App-Entwicklung
  • Dass ein lange vernachlässigtes Utility-Paket übernommen und ein Crypto-Miner in Produktions-Builds weltweit eingeschleust wird, wird wie eine Naturkatastrophe behandelt
  • Das Node.js-Ökosystem nimmt bösartige Remote Code Execution als unvorhersehbare Tragödie hin und sendet „Gedanken und Gebete“ an DevOps-Teams, die mit dem Rotieren von AWS-Schlüsseln beschäftigt sind

Kontrast zwischen anderen Ökosystemen und npm

  • Go-, Rust- und native-Web-API-Ökosysteme reduzieren mit starken Standardbibliotheken die Abhängigkeit von Drittanbieter-Code erheblich und enthalten in ihren zentralen Toolchains strenge kryptografische Verifikation
  • In diesen Ökosystemen wird dem entgegengesetzt, dass es heute 0 Fälle gegeben habe, in denen ein „Wochenendprojekt eines Studienabbrechers“ die globale Logistikinfrastruktur lahmgelegt hat
  • Ein npm-Sprecher stellt klar, dass man dies in einer Welt mit böswilligen Akteuren akzeptieren müsse und dass es keine Registry-Richtlinien oder Guardrails für Build-Sandboxes gebe, die dies verhindern könnten
  • Das npm-Registry wird als Open-Source-Registry gezeichnet, die standardmäßig beliebige Installationsskripte auf lokalen Maschinen ausführt, wodurch die Aussage des Sprechers und das strukturelle Risiko zusammenfallen
  • Zum Schluss wird den Betroffenen Mitgefühl ausgesprochen, verbunden mit dem Hinweis, bis zum „nächsten unvermeidlichen Einbruch“ morgen früh resilient zu bleiben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Zu Cooldowns kann man unterschiedliche Meinungen haben, aber ein erheblicher Teil der jüngsten npm-Supply-Chain-Angriffe, darunter axios und tanstack, hätte sich wohl mit einem Cooldown vermeiden lassen
    Wer Artifactory / Nexus nutzt, hat wahrscheinlich bereits einen Cooldown, und falls nicht, ist er leicht einzurichten
    npm- oder PyPI-Kompromittierungen wurden meist innerhalb weniger Stunden wieder entfernt, daher bedeutet Cooldown: „Pakete ignorieren, die seit weniger als N Tagen veröffentlicht sind“. Schon 1 Tag hilft, 3 Tage sind gut, 7 Tage sind etwas übertrieben, funktionieren aber
    Zur Einrichtung kann man aktuelles pnpm mit standardmäßigem 1-Tages-Cooldown verwenden oder https://pnpm.io/supply-chain-security; wer es auf einen Schlag für npm, pnpm, yarn, bun, uv und dependabot mit Cooldowns und empfohlenen Einstellungen lösen will, kann https://depsguard.com nutzen. Ich bin der Maintainer
    Oder es gibt noch https://cooldowns.dev, das stärker auf Cooldowns fokussiert ist, sowie ein Skript, das bei lokaler Konfiguration hilft. Alles ist Open Source oder kostenlos
    Wer ~/.npmrc usw. direkt bearbeiten kann, braucht das nicht unbedingt, aber für Leute im eigenen Umfeld, die eine One-Click-Lösung brauchen, kann es gut den nächsten Angriff verhindern
    Natürlich muss man den Cooldown umgehen können, wenn man ein neues kritisches CVE patchen muss; für alles gibt es Umgehungsmöglichkeiten. Exakte Zahlen habe ich nicht, aber in den letzten Wochen schien das größere Risiko eher von Software-Supply-Chain-Angriffen als von neuen Zero-Day-CVEs auszugehen

    • Ich finde eher seltsam, dass 7 Tage als übertrieben gelten. Wenn man nicht gerade ein bestimmtes neues Feature unbedingt braucht, sollten selbst beim Start eines neuen Projekts auch Abhängigkeitsversionen reichen, die schon vor ein paar Monaten erschienen sind
      Dasselbe gilt für regelmäßige Dependency-Upgrades. Es gibt natürlich Fälle wie Vulnerability-Response, in denen man sofort aktualisieren muss; dann kann man Entwickler ja explizit die gewünschte neue Version angeben lassen
    • Dann verschiebt sich das Problem doch einfach nur um 7 Tage, oder? Solche Vorfälle enden doch normalerweise, weil jemand infiziert wird und es bemerkt, nicht weil ein Heer von Leuten Änderungen auditiert und sie findet
      Wenn alle einen 7-Tage-Cooldown setzen, explodiert das dann nicht einfach später?
    • Es scheint ein Satz zu fehlen:

      Disclaimer: I maintain depsguard

    • Ich bin nicht sicher, ob Cooldowns wirksam sind. Jemand muss den Cooldown umgehen, eine problematische Release installieren und den Fehler entdecken. Wenn das niemand tut, hat man das Problem nur um 3/7/10/14 Tage verschoben
      Während ich das schreibe, merke ich aber: Mit einem 10-Tage-Cooldown, also nichts zu installieren, das in den letzten 10 Tagen erschienen ist, bin ich trotzdem einverstanden. Nur sollte man nicht erwarten, dass das die einzige Gegenmaßnahme ist
    • Warum nicht wie bei Linux-Distributionen getrennte Latest/Stable/LTS-Varianten oder Kanäle einführen?

  • Ich frage mich, was Go oder Rust gegenüber Python/npm tatsächlich garantieren. Vielleicht sind Python/npm einfach nur attraktivere Ziele
    Ich versuche zunehmend, alle Third-Party-Pakete zu vermeiden

    • Wie Eigentum an Paketen und Namensräumen vergeben wird, hängt zu 100 % vom Betreiber des Paketmanagers ab
      Maven Central existiert seit Jahrzehnten, aber Fälle von Namespace-Diebstahl sind sehr selten
      Man kann kein Paket mit der groupId com.ycombinator hochladen, ohne zu verifizieren, dass man die Domain ycombinator.com besitzt. Und ein einmal hochgeladenes Paket ist zu 100 % unveränderlich, selbst wenn es Malware enthält. Solche Bibliotheken werden dann natürlich überall als verwundbar markiert
      Ich verstehe nicht, warum NPM es über so viele Jahre nicht geschafft hat, Sicherheitsmechanismen wie bei Maven Central zu kopieren
    • Einer der Kernpunkte des Artikels ist, dass die meisten anderen populären Sprachen eine umfassende Standardbibliothek haben. Die Standardbibliothek von JS ist erstaunlich klein
      Statt eines mit der Sprache ausgelieferten Bündels verifizierter Bibliotheken müssen Anwendungen Dinge selbst bauen oder aus Third-Party-Paket-Repositories holen. Da ständig gelehrt wurde, NIH zu vermeiden, greifen Leute lieber zu Paketen
      Das ist an sich nicht unbedingt schlecht, führt aber oft dazu, dass mehr Code hereingeholt wird als nötig. Das JS-Ökosystem bevorzugt zudem kleine Module, also braucht man viele davon, und alle bauen wieder darauf auf, wodurch der Dependency-Graph riesig wird. Ob absichtlich oder nicht: Die Angriffsfläche für Probleme ist einfach zu groß
      Andere Sprachen bringen von Haus aus viel mehr mit. Bugs und Sicherheitsprobleme gab es dort auch, aber verglichen mit dem JS-Ökosystem sind sie verschwindend gering. Externe Dependency-Graphen sind viel kleiner, und Kernfunktionalität kommt von vertrauenswürdigen Dritten
    • Angreifer gehen dorthin, wo die Opfer sind. Im Frontend gibt es fast eine Monokultur, in der die meisten NPM verwenden; im Backend ist das weniger stark ausgeprägt
      Das entschuldigt NPM nicht, sondern ist eher noch ein weiterer Nachteil für NPM
      Man könnte auch sagen, dass solche Angriffe den Unterschied zwischen Frontend- und Backend-Entwicklern noch deutlicher zeigen, aber so weit würde ich nicht gehen
    • Ehrlich gesagt hat Rust genau dasselbe Supply-Chain-Angriffs-Muster. Es ist nur neuer und wird momentan besser gepflegt. Wartet einfach 10 Jahre
    • Als ich zuletzt nachgesehen habe, hatte npm 2FA fürs Publishen, cargo aber nicht. Ich halte cargo nicht für grundsätzlich besser als npm; es ist nur kein so attraktives Ziel

  • In mehreren Jobs war es ein riesiger Aufwand, auf allen Entwicklerrechnern sichere globale npm-Einstellungen zu installieren, die Leute zu bitten, sie nicht auszuschalten, und das mit MDM-Tools zu überprüfen
    Sicherere Standardeinstellungen hätten schon längst kommen müssen

    • Man kann einfach kein npm benutzen. Man nimmt einen Paketmanager, der standardmäßig kein postinstall ausführt, und der Wechsel ist erstaunlich einfach
    • Ich frage mich, was mit sicheren Einstellungen genau gemeint ist. Wenn es darum geht, Cooldown-Zeiten oder Allow-/Block-Listen für Pakete zu erzwingen, dann ist der richtige Ansatz ein von der Firma kontrolliertes Repository, das vom Upstream-npm-Repository bezieht und die gewünschten Richtlinien durchsetzt

  • Es gibt keinen legitimen Grund, warum postinstall-Skripte existieren sollten. Das npm-Team ist inzwischen reif genug, um zu sagen: „Ab npm-Version soundso werden postinstall-Skripte nur noch für Paketversionen ausgeführt, die vor dem ${today} veröffentlicht wurden.“

    • Ich habe kürzlich mehrere postinstall-Skripte aus populären Paketen auditiert. Die meisten verwendeten oder luden native Binärdateien herunter, erkannten Plattformkompatibilität, verdrahteten Dinge selbst, statt Node das Bootstrapping zu überlassen, und umgingen Probleme mit alten npm-Versionen
      Das liegt daran, dass Toolchains wie esbuild in kompilierten Sprachen geschrieben und als Binärdateien über das npm-Repository verteilt werden. Wenn man aktuelles Node/npm und ein gängiges aktuelles OS bzw. eine gängige Plattform nutzt, sollte man alle postinstall-Skripte ohne legitime Probleme deaktivieren können
    • Installationsskripte sind wie Paketsignaturen eher Ablenkung. Das Hinzufügen oder Entfernen eines einzelnen Features verändert das Wurm-Potenzial dieses Paketökosystems kaum
      Installierter npm-Code wird fast ausnahmslos ausgeführt
    • Dass Rust-Pakete beim Bauen ohne Sandbox ausgeführt werden können, ist auch nicht gerade gut zu rechtfertigen
    • Das behebt das Problem nicht wirklich. Paketcode wird beim Build und beim Testen ebenfalls ausgeführt. Man kann den Umfang etwas verkleinern, aber mehr auch nicht
    • Vorsichtig formuliert sind postinstall-Skripte fast ein Scheinproblem. Die Leute sind schockiert, dass fremdkontrollierter Code auf ihrem Rechner ausgeführt wird und böse Dinge tun kann — und ja, das kann er
      Aber für normalen Code im Paket gilt dasselbe. Er wird vielleicht nicht beim Installationszeitpunkt ausgeführt, aber irgendwann läuft etwas daraus trotzdem. Sonst wäre es gar keine Dependency geworden
      Zu glauben, dass das Abschaffen von postinstall-Skripten die Missbrauchsquote mehr als kurzfristig beeinflusst, zeigt, dass das Problem nicht zu Ende gedacht wurde. Leider ist das alles viel subtiler, als es der Originaltext andeutet
      Das ist nicht so ein Problem wie „Stell keinen Knopf, bei dem die Flügel abfallen, neben den Lichtschalter“, sondern eher: Es gibt ohne extrem mühsame Handarbeit keine Möglichkeit zu unterscheiden zwischen „schlechtem fremdem Code, den wir nicht auf unserem Rechner ausführen wollen“ und „gutem fremdem Code, den wir auf unserem Rechner ausführen wollen“. Und gerade um diese mühsame Handarbeit zu vermeiden, führt man fremden Code aus

  • Jedes Node.js-Projekt beginnt mit npm install, und plötzlich hat man 500 Pakete, die man nie wollte. Die Hälfte davon wurde seit Jahren nicht angefasst

  • Es gibt ein kulturelles Problem, immer möglichst auf die neuesten Pakete zu springen, selbst wenn das Vorhandene schon gut funktioniert. Oft liest man nicht einmal das Changelog, um zu sehen, ob die Änderung überhaupt relevant ist
    Cooldowns sind nur ein Mittel, Maintainer zu etwas Geduld zu zwingen, aber tatsächlich wirken sie

    • Wenn es Compliance-Anforderungen gibt, muss man wegen CVE-Meldungen gegen alte Versionen aktualisieren. Die meisten davon sind fast schon Pseudo-Probleme wie „Regex DoS“, aber das Verfahren muss erfüllt werden, also aktualisiert man trotzdem
    • Und dann gibt es noch Fälle, in denen Paketbesitzer Dinge aktualisieren, die gar kein Update brauchen, nur damit sie nicht alt und verlassen aussehen
      Lisp-Pakete kann man 15 Jahre lang unverändert problemlos nutzen, aber bei JS-Paketen gilt mangelnde Wartung sofort als Katastrophe. Obwohl sie vielleicht schon vor 15 Jahren fertig waren, werden Versionen hochgezogen und manchmal sogar Breaking Changes eingebaut, nur damit es auf npm und GitHub gepflegt aussieht. Dann wird alles aktualisiert

  • Ein 7-Tage-Cooldown fühlt sich wie ein Quick-and-Dirty-Pflaster mit wenig Aufwand an. Die echte Lösung wären wahrscheinlich reproduzierbare Builds und signierte Attestierungen, aber die meisten Teams werden diese Kosten wohl erst tragen, nachdem sie bereits getroffen wurden

  • Das liest sich wie ein Onion-Artikel

    residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy
    Glaubt das wirklich jemand? Dafür gab es viel zu viele Gegenbeispiele
    Es ist gute Satire, die auf das Versagen des Ökosystems zielt, aber am Ende bleibt es Unterhaltung. Vielleicht ist es auch eine Gelegenheit für Marketer, ihre Produkte zu platzieren. Etwa so, wie der Maintainer von depsguard diese Info in seinem Beitrag entfernt, wieder eingefügt und dann wieder entfernt hat. Zum Zeitpunkt dieses Kommentars steht der Beitrag ganz oben

  • Dieser Link ist eine offensichtlich KI-gewaschene Version eines Witzes, den Xe Iaso schon lange macht. Schade
    https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
    https://news.ycombinator.com/item?id=40438408