Bösartige npm-Pakete in den Red Hat Cloud Services entdeckt

 (github.com/RedHatInsights)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das Issue ist offen; zum Zeitpunkt des Textes gibt es weder zuständige Bearbeiter noch einen Meilenstein oder verknüpfte Branches bzw. PRs
  • Es wurde als Sicherheitsproblem erfasst, bei dem in mehreren npm-Releases im Scope @redhat-cloud-services/ bösartige Versionen entdeckt wurden
  • Als Referenz werden der Analysebeitrag von StepSecurity und die Suchergebnisse im OSS Security Feed genannt
  • Die aktualisierte Liste der betroffenen Pakete umfasst 32 Pakete, darunter @redhat-cloud-services/chrome, frontend-components, rbac-client, types und vulnerabilities-client
  • Die in der Tabelle aufgeführten kompromittierten Versionen sind meist drei pro Paket; bei @redhat-cloud-services/vulnerabilities-client sind nur die beiden Versionen 2.1.9 und 2.1.11 enthalten
  • Auf Basis der gesamten Tabelle lassen sich 95 kompromittierte Versionen zählen; auch der separat erwähnte Titel eines externen PR verweist auf 95 versions
  • Enthalten sind unter anderem Pakete der Reihe @redhat-cloud-services/frontend-components-* sowie mehrere *-client-Pakete, sodass es sich nicht um ein einzelnes Paket, sondern um ein Release-Problem im gesamten Scope handelt
  • In den Kommentaren wurde auf die Frage „What are these?“ mit „all that module is pwned“ geantwortet, was das gemeinsame Verständnis widerspiegelt, dass die gesamte Liste kompromittiert wurde
  • DanielRuf schrieb, dass er diesen Vorfall zu supply-chain-incidents hinzugefügt hat
  • In der GitHub-Aktivität sind zusammenfassende Inhalte mit Verweis auf dieses Issue sowie ein PR zur Erkennung zu sehen, doch im Text selbst werden von Red Hat bislang weder Diagnose noch Gegenmaßnahmen, Entfernung oder korrigierte Versionen genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Hoffentlich ist es in Ordnung, den Thread noch einmal für das Thema Cooldown zu nutzen. Bei axios, tanstack, @redhat-cloud-services und mehreren jüngsten npm-Supply-Chain-Angriffen hätte ein Cooldown das verhindern können
    Wer Artifactory/Nexus nutzt, hat das wahrscheinlich schon, und falls nicht, ist es leicht einzurichten. Die meisten Kompromittierungen von npm oder PyPI wurden innerhalb weniger Stunden wieder entfernt, daher reicht es aus, Pakete zu ignorieren, die seit weniger als N Tagen veröffentlicht sind. Schon 1 Tag hilft, 3 Tage sind gut, und 7 Tage sind etwas übertrieben, funktionieren aber
    Das aktuelle pnpm hat standardmäßig einen Cooldown von 1 Tag: https://pnpm.io/supply-chain-security
    Wenn man es mit einem Klick erledigen will, kann man https://depsguard.com verwenden. Das ist eine CLI, die Cooldowns und empfohlene Einstellungen für npm, pnpm, yarn, bun, uv und dependabot hinzufügt; ich bin der Maintainer
    Es gibt auch https://cooldowns.dev, das stärker auf Cooldowns fokussiert ist, sowie Skripte, die bei lokalen Einstellungen helfen. Alles ist Open Source/kostenlos
    Wenn man ~/.npmrc usw. direkt bearbeiten kann, braucht man das nicht unbedingt, aber falls es in deinem Umfeld Leute gibt, die nur einen One-Click-Fix brauchen, könnte das helfen, dem nächsten Angriff zu entgehen
    Wenn allerdings ein neuer kritischer CVE gepatcht werden muss, muss man den Cooldown umgehen; dafür gibt es je nach Tool entsprechende Wege. Ich habe für die letzten Monate keine exakten Zahlen, aber selbst im Zeitalter der Mythos-artigen Schwachstellenfunde scheint das Risiko durch Software-Supply-Chain-Angriffe wie die Verteilung bösartiger Versionen größer zu sein als durch neue Zero-Day-CVEs

    • Als Embedded-Entwickler, der daran gewöhnt ist, Toolchains und Abhängigkeiten über Jahre festzunageln, ist die Web-Development-Kultur in vielerlei Hinsicht schockierend
    • Ein Freund hat ein GitHub-Repository mit vernünftigen und etwas sichereren Konfigurationen zusammengestellt: https://github.com/jordanconway/package-manager-hardening
    • Gibt es einen vernünftigen Weg, auch bei Docker-/Podman-Image-Pulls einen Cooldown einzubauen?
    • Selbst bei Leuten, die ihre ~/.npmrc öffnen und eine Zeile hinzufügen können, scheint die Gruppe, die einen One-Click-Fix braucht, sehr klein zu sein
    • Zusätzlich zu Cooldowns wäre es gut, wenn mehr Paketmanager Security-Fixes getrennt von normalen Releases (Bugfixes/Performance-Verbesserungen/neue Features) behandeln würden
      Zu sagen „Security-Fixes sollten nur Security-Fixes enthalten und keine anderen Features mitbringen“ ist absolut machbar. Damit würde es sowohl für Security-Researcher als auch für Tools leichter, Audits durchzuführen
      Auf normale Releases kann man Cooldowns anwenden, und bei Security-Fixes kann man den Cooldown aufheben oder deutlich verkürzen
      Systeme wie bei Debian, wo man sehr stabile Server betreibt und unattended upgrades so konfigurieren kann, dass sie nur für Security-Fixes gelten, sind ein gutes Vorbild. Solche neuen Paket-Releases sind auch für Security-Researcher leichter zu auditieren.

  • In jedem solchen Thread gibt es viele Kommentare, die so tun, als gäbe es diese Art von Angriff nur bei npm, oder sarkastisch behaupten, es habe keinerlei Gegenmaßnahmen gegeben, aber das halte ich für unfair.
    Es gibt auch viele Kommentare, die gute Funktionen erwähnen, die zum Schutz von Paketnutzern eingeführt wurden, etwa delay line und pnpm.
    Weniger besprochen werden die Tools für Paket-Maintainer. MFA für Veröffentlichungen: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., sowie trusted publishers, die seit etwa einem Jahr verfügbar sind: https://docs.npmjs.com/trusted-publishers
    Kürzlich kam auch staged publishing hinzu, das die Vorteile beider Funktionen kombiniert: https://docs.npmjs.com/staged-publishing
    Damit kann man nun aus CI ohne statische Zugangsdaten veröffentlichen und verlangen, dass ein Maintainer dies per MFA genehmigt, bevor es tatsächlich im Registry öffentlich wird. Wenn man möchte, kann man mit GitHub Actions Environments protections auf der CI-Seite auch mehrere Genehmigungen oder eine Zeitverzögerung verlangen.
    Die Community sollte dazu ermutigt werden, solche Schutzmechanismen für Veröffentlichungen zu übernehmen, sonst wird dieses Problem weiter bestehen.

    • Laut [1] wurden „alle betroffenen Pakete über GitHub Actions OIDC aus dem Repository RedHatInsights/javascript-clients veröffentlicht, was darauf hindeutet, dass die Upstream-CI/CD-Pipeline selbst kompromittiert wurde“.
      Dann hätte auch ein bösartiges Paket den grünen Stern erhalten und den Nutzern versichert, es sei „mit Herkunftsnachweis gebaut und signiert“ worden.
      [1] https://lwn.net/Articles/1075742/
    • Es ist schon irgendwie komisch, weil es ständig passiert. npm-Angriffe sind so häufig, dass man sie in den Kalender eintragen könnte, und jemand hat sogar eine npm-Version der klassischen The-Onion-Parodie „Es gibt keine Möglichkeit, dies zu verhindern“ gemacht.
      Es ist großartig, dass an Gegenmaßnahmen gearbeitet wird, aber es passiert trotzdem weiter. Komisch im Sinne von „Schon wieder geht es los“.
    • Erst wenn man es für alle verpflichtend macht, hat man wirklich etwas getan.
    • Ich bin von mechanischen Änderungen nicht besonders beeindruckt, und es scheint eine Gruppe zu geben, die dies als kulturelles Problem betrachtet.
      Von außen betrachtet hat Webentwicklung etwas von der hektischen Energie eines Wilden Westens: Mutabilität, dynamische Typisierung, sich ständig ändernde Standards und Frameworks, Continuous Deployment, CDN, Echtzeit-A/B-Kampagnen, viele Abhängigkeiten und sensible Nutzerdaten, die über mehrere Infrastrukturen verteilt sind.
      Ich sage nicht, dass diese Sichtweise korrekt ist oder dass eine Haltung nach dem Motto „Siehst du“ gerechtfertigt wäre, aber ich verstehe, woher sie kommt.
    • Meiner Meinung nach sind beide nur Lippenstift für ein Schwein. Letztlich sind es alles Varianten von „Machen wir Releases schwieriger zu veröffentlichen“, und sie bringen den Leuten nur bei, wie man sie umgeht.
      Vor allem hätte keines von beiden den xz-utils-Backdoor daran gehindert, in eine Paketveröffentlichung zu gelangen. xz-utils bleibt der Maßstab für einen ausgefeilten Upstream-Kompromiss.
      Der Fehler hier ist nicht, dass wir Upstream, dem wir bereits vertrauen, besser authentifizieren müssten, sondern dass man Upstream nicht als einzige Quelle von Sicherheit vertrauen kann. Upstream ist eine Gruppe von Hackern, die sich wenig für solide Release-Engineering-Praktiken interessieren und darin auch nicht besonders gut sind.
      Aber es gibt Leute, die darin gut sind. Die Lösung in der Linux-Welt und die Art, wie wir vor xz-utils gerettet wurden, besteht darin, dass es eine zweite menschliche Ebene gibt, die von Hackern geschaffenen Upstream-Code für Nutzer prüft, auditiert, paketiert und anpasst.
      Diese Menschen haben andere Augen, andere Anforderungen von Verbrauchern und andere Qualitätsmaßstäbe und entdecken Bugs und Böswilligkeit, die Upstream noch nicht zu fassen bereit ist.
      NPM, cargo, PyPI usw. glauben weiterhin, dass sie diesen Bedarf an menschlicher Arbeit umgehen können, aber das können sie nicht. Im NPM-Ökosystem sieht man so etwas besonders häufig, weil es dort viele Webentwickler gibt, die an sehr schnelle Releases, lockere Kompatibilitätsanforderungen und extreme Wiederverwendung gewöhnt sind, wodurch solche Vorfälle bei Node-Paketen häufiger auftreten als bei Python oder Rust.

  • Wir nutzen in unserem Unternehmen yarn 4; dort gibt es eine Option, die die Installation von npm-Paketen in den ersten Tagen nach dem Release blockiert. Die meisten dieser Angriffe scheinen in diesem Zeitraum (1–3 Tage) entdeckt zu werden.
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Ich habe ein paar Vorschläge. Ein Dependency-Cooldown von 1–2 Tagen scheint sehr wirksam zu sein, ohne die Fähigkeit zur CVE-Behebung zu beeinträchtigen.
    Überall dort, wo Code ausgeführt wird, etwa bei npm install oder npm test, sollte in einer nicht privilegierten Umgebung gearbeitet werden. In GitHub Actions ist es relativ einfach, Jobs zum Bauen und Testen von Artefakten von Jobs für Deployment, Signierung usw. zu trennen. Wenn man AI nutzt, kann man einfach ein Skill-/Guide-Dokument hinzufügen, das dieses Muster erzwingt.
    Wenn man GitHub Actions verwendet, verbessert die Installation des neuesten zizmor die Sicherheitslage erheblich.
    Die zweite Maßnahme sorgt dafür, dass sich so etwas nicht mehr „wie ein Wurm verbreiten“ kann, und reduziert einen großen Teil des aktuellen Problems. Die erste verschafft Unternehmen Zeit, auf Angriffe zu reagieren. Einige Anbieter in diesem Bereich sind ebenfalls einen Blick wert.

    • Was, wenn zizmor kompromittiert wird?
      Direkt nachdem gesagt wurde, neue Pakete sollten verzögert werden, war das als Witz ziemlich lustig.
    • Wäre es nicht besser, Builds statt solcher Cooldowns einfach in einem isolierten Kontext auszuführen?
      Ich betreibe lokal einen Maven-Proxy, und alle Builds laufen in Containern. Python, npm und Go verwenden nur öffentliche Repositories, daher laufen auch diese Builds in Containern, aber ohne Repository-Proxy.
    • Wenn wirklich überall, wo Code ausgeführt wird, dann scheinen agentische Orchestratoren wie codex oder claude-code das standardmäßig so zu machen.

  • Das ist am selben Tag wie die Ankündigung von Project Lightwell durch Red Hat und IBM, das bei der Erkennung und Behebung von Schwachstellen in der Supply Chain helfen soll.
    https://www.redhat.com/en/lightwell

  • Vor ein paar Tagen habe ich diesen interessanten Rant gesehen: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Das Argument, der richtige Weg sei, alle verwendeten Abhängigkeiten zu forken und dann bei Bedarf Upstream-Änderungen zu prüfen und zu mergen, während man aus dem eigenen Repository installiert, hat schon etwas für sich. Allerdings klingt das extrem lästig.

    • Unmöglich zu automatisieren ist das nicht. In der Go-Welt könnte man das Vendoring nennen: https://go.dev/ref/mod#vendoring
      Das ist gut geeignet, um die Abhängigkeit von Hosting-Anbietern für Drittanbieter-Dependencies zu verringern oder ganz zu vermeiden, Abhängigkeiten in die eigenen Code-Review-Tools zu holen und langfristig reproduzierbare Builds sicherzustellen.
    • Das Problem ist, dass es mit den Abhängigkeiten der Abhängigkeiten weitergeht, und dann noch über mehrere Ebenen darunter.
    • Ich habe Packj gebaut, um Abhängigkeiten in der CLI leichter zu auditieren.
      Packj(https://github.com/ossillate-inc/packj) erkennt bösartige Abhängigkeiten in PyPI/NPM/Ruby/PHP usw. per Verhaltensanalyse. Mit statischer und dynamischer Codeanalyse scannt es nach Kompromittierungsindikatoren wie Shell-Ausführung, Nutzung von SSH-Schlüsseln, Netzwerkkommunikation oder dem Einsatz von decode+eval. Außerdem prüft es verschiedene Metadaten-Eigenschaften, um bösartige Akteure wie etwa Typosquatting zu finden.
    • Man kann die Wahrscheinlichkeiten vielleicht verschieben, aber wenn man nicht gewissenhaft forkt und alle zukünftigen Schwachstellen per Monkeypatch behebt, verteilt man am Ende womöglich für immer einen kompromittierten Fork.
    • Sollte man Pakete nicht nur aktuell halten, sondern auch Versionsnummern einschränken?

  • Ich habe vor ungefähr einer Woche Node von meinem Laptop gelöscht, und das hat sich gut angefühlt.
    Selbst wenn ich Pech habe und ein Exploit trifft, versuche ich alles in Entwicklungscontainern oder anderen Sandboxes zu erledigen, um den Schadensradius zu begrenzen. Ein Angreifer könnte zwar mein Claude-Token stehlen, aber nicht so leicht aus dem Container ausbrechen und mein Home-Verzeichnis durchwühlen.
    Cooldowns und Allowlists für Installationsskripte sind besonders in CI eine gute zusätzliche Schicht der Absicherung. Aber grundsätzlich muss sich aus meiner Sicht das Berechtigungsmodell des Betriebssystems ändern. Der Standard, Drittsoftware pauschal mit allen Benutzerrechten zu vertrauen, funktioniert nicht mehr.

    • Mich würde interessieren, ob du so etwas wie Bubblewrap/Firejail/Flatpak verwendest oder wie so ein Setup konkret aussieht. Ich trage eine ähnliche Idee schon eine Weile mit mir herum, habe sie aber noch nicht umgesetzt.

  • Ich glaube, man sollte den Link zur ursprünglichen Veröffentlichung angeben.
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Stimmt. Und im Titel ist sogar die Schreibweise von Red Hat falsch.

  • Ich habe mir inzwischen angewöhnt, beim Installieren von Paketen das Flag --before=2026-05-30 zu verwenden. Damit wird eine Version gewählt, die vor dem angegebenen Datum veröffentlicht wurde, und normalerweise nehme ich ungefähr fünf Tage Abstand.

  • NPM ist schon vom Design her kaputt, und wegen des in der Community verbreiteten NIH-Syndroms lassen sich nicht einmal einfache Maßnahmen durchsetzen.

    • Den zweiten Satz verstehe ich nicht ganz. Hat npm nicht eher das gegenteilige Problem von „nicht hier erfunden“?
      Weil so viele externe Pakete übernommen werden statt selbst etwas zu entwickeln, haben npm-Projekte oft große und komplexe Dependency-Trees. Über Pakete wie https://www.npmjs.com/package/is-windows wird schon lange geklagt, weil man denselben Code viel zu leicht selbst schreiben könnte, sie aber potenzielle Schwachstellen und Wartungsprobleme mit sich bringen.
    • Ein häufiger Denkfehler auf der NIH-Seite ist die Annahme, dass es viel Zeit kosten würde, Paket X nachzubauen.
      Aber natürlich muss man nicht die komplette Funktionalität neu implementieren, sondern nur das, was man tatsächlich braucht.
      Außerdem muss man, wenn man nur eine einzelne Funktion schreibt, keine Abstraktionen oder zusätzliche Funktionsschnittstellen bauen. Dadurch ist es billiger und wahrscheinlich auch besser integriert.
      Ein weiterer Irrtum ist die Annahme, dass man dadurch Bugs und Schwachstellen erzeugt. Bei schlechten Programmierern mag das stimmen, aber dafür vermeidet man die ganze Klasse von Schwachstellen an den Integrationsgrenzen zweier Bibliotheken, die nie dafür entworfen wurden, exakt zusammenzupassen. Das kommt oft vor.