ClickCease "Alles" und auch die Node.js-Küchenspüle

Inhaltsübersicht

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

"Alles" und auch die Node.js-Küchenspüle

Joao Correia

11. Januar 2024 - Technischer Evangelist

  • *Die Lieferkette ist auf allen Ebenen verwundbar, vom Code bis zum Vertrieb.
  • *Node.js-Repository wurde effektiv gesperrt, nachdem ein Entwickler ein bösartiges Paket hochgeladen hatte

Es ist oft schwer, zwischen beabsichtigten und unbeabsichtigten Folgen zu unterscheiden. Ein kürzlich erfolgter "Streich" über die Feiertage hat das Leben von Node.js-Entwicklern erschwert und unterstreicht ein bekanntes Sprichwort: Keine gute Tat bleibt ungesühnt. 

Es wird eine Geschichte erzählt, für die man unbedingt Popcorn essen sollte.

In den fernen Zeiten des Jahres 2016...

 

...hat ein Node.js-Entwickler ein Paket namens "leftpad" erstellt, das nur 11 Zeilen Code umfasst. Das Auffüllen von Zeichenketten ist eine häufige Aufgabe für Entwickler, die es in der Regel vorziehen, das Rad nicht neu zu erfinden (das Prinzip der "Don't Repeat Yourself"-Programmierung - DRY -). 

Natürlich entschieden sich viele dafür, "leftpad" in ihre Projekte zu importieren. Aber dieses Vertrauen brachte eine Schwachstelle mit sich - die Anfälligkeit für jegliche Probleme mit "leftpad", seien es Fehler, Sicherheitslücken oder die Launen seines Schöpfers. In einer dramatischen Wendung hat der Entwickler von "leftpad" unter Berufung auf das Recht, seine Arbeit zu entfernen, genau das getan. Diese Aktion brachte eine beträchtliche Anzahl großer Websites zum Absturz und machte deutlich, wie anfällig solche Abhängigkeiten sind. Fairerweise muss man sagen, dass der Autor einige Gründe dafür angegeben hat, und ob Sie mit der Kommerzialisierung von Open-Source-Code durch Unternehmen einverstanden sind, wird Ihre Meinung darüber ändern (Sie können mehr darüber lesen hierlesen, wenn Sie dazu geneigt sind).

Letztendlich führte die Entfernung von "leftpad" zu schwerwiegenden Störungen bei zahlreichen Paketen und Websites von Drittanbietern. Um eine Wiederholung zu verhindern, führte die npm-Registry eine Richtlinie ein: Ein Paket kann nicht unveröffentlicht werden, wenn es eine Abhängigkeit für ein anderes Paket darstellt. Diese Regel schien eine Zeit lang wirksam zu sein.

 

Das ist alles gut, aber was ist in letzter Zeit passiert?

 

Da wir offensichtlich keine schönen Dinge haben können, haben die Leute nach Möglichkeiten gesucht, die durch die Registrierung eingeführte Änderung zu missbrauchen. Und in Umkehrung der Logik, wenn ich ein Paket nicht entfernen kann, von dem jemand anderes abhängt, kann vielleicht jemand anderes seins nicht entfernen, wenn mein Code von seinem Paket abhängt... und natürlich hat es funktioniert.

Der Entwickler beschrieb dies später als "Test" und "Streich" und fügte der Registrierung ein Paket namens "everything" hinzu. Es tat nichts anderes, als eine Gruppe anderer Pakete namens "everything chunk 1", "everything chunk 2" usw. als Abhängigkeiten einzuschließen. Diese enthielten ihrerseits jedes einzelne Paket in der Registry. Dies machte es unmöglich, irgendein Paket zu deinstallieren, da es immer eine Abhängigkeit davon geben würde.

Aber es wird noch besser. Oder schlimmer, je nachdem, wie viel Popcorn Sie noch übrig haben.

Die Abhängigkeitsdeklaration eines npm-Pakets erlaubt es Entwicklern, von einer bestimmten Version "abhängig" zu sein. In der Regel handelt es sich dabei um eine getestete Version, die das tut, was sie vorgibt zu tun, und zwar korrekt. Der Entwickler, der dieses Paket einbindet, hat umfangreiche Tests durchgeführt, um sicherzustellen, dass das Verhalten für sein Paket oder seine Anwendung das notwendige ist. 

Aber Sie sind nicht auf die Angabe einer einzigen Version beschränkt. Indem Sie "*" als Versionswert angeben, teilen Sie npm mit, dass *jede* Version dieses Pakets als Abhängigkeit verwendet werden kann. 

Nun, "alles" beinhaltete jede einzelne Abhängigkeit... und jede einzelne Version dieser Abhängigkeiten, da es "*" in der Deklaration verwendete.

So waren andere Entwickler nicht nur daran gehindert, ihre eigenen Pakete zu entfernen (zum Beispiel, wenn sie einen Fehler hatten), sondern auch alle alten Versionen. 

"Alles" war fest verschlossen.

 

Wurde das Problem gelöst?

 

Ja, glücklicherweise. Der Ersteller von "everything" hat mit dem npm-Supportteam zusammengearbeitet, um das Problem zu beheben, wobei er eingreifen musste, indem er die "everything chunk"-Repositories als privat markierte und damit die Abhängigkeitskette unterbrach (mehr dazu, einschließlich eines Screenshots, auf dem sich der Entwickler entschuldigt, finden Sie hier).

Dieser Vorfall war eine knappe Angelegenheit für die kollektive Cybersicherheits- und IT-Gemeinschaft. Er wirft eine beängstigende Möglichkeit auf: Was wäre, wenn es sich nicht um einen Entwickler handelt, der dieses Chaos als Streich (oder "Test") verursacht hat, sondern um einen ernsthaften Bedrohungsakteur? Was wäre, wenn ein "Alles"-Paket nur die Spitze des Eisbergs gewesen wäre, um die Entfernung eines anderen Pakets mit einer Sicherheitslücke auf log4j-Niveau in seinem Code zu verhindern?

Das npm-Ökosystem, und eigentlich jede ähnliche Umgebung, die sich auf die Abhängigkeit von Paketen konzentriert, steht immer noch vor großen Herausforderungen bei der Behebung dieser Schwachstellen. Es ist möglich, dass es keine perfekte Lösung gibt, angesichts der Kreativität, mit der Menschen Schwachstellen ausnutzen. 

Vielleicht kann die KI in diesem ständigen Kampf die dringend benötigte Unterstützung leisten.

 

* Weitere Beispiele für scheinbar triviale, aber wirkungsvolle Pakete finden Sie in der "One liner rpm package "is-windows" has 2.5 million dependents, why on earth?!" Thread auf Reddit. Einem einzigen Entwickler werden über 1400 Pakete zugeschrieben, von denen die meisten einfache Einzeiler sind, was den überraschenden Einfluss von minimalem Code verdeutlicht.

 

Zusammenfassung
"Alles" und auch die Node.js-Küchenspüle
Artikel Name
"Alles" und auch die Node.js-Küchenspüle
Beschreibung
Es ist oft schwer, zwischen beabsichtigten und unbeabsichtigten Folgen zu unterscheiden. Ein kürzlich erfolgter "Streich" erschwerte das Leben von Node.js-Entwicklern.
Autor
Name des Herausgebers
TuxCare
Logo des Herausgebers

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter