NPM Paket Nodemon mit Backdoor / Trojaner versehen

[Sithys]

Hallo zusammen,
scheinbar an einigen vorbei gegangen, ist im Bereich rund um den Paket-Manager NPM was ziemlich erstaunliches passiert. Jemand hat es geschafft, eine Backdoor / einen Trojaner in das Paket nodemon zu integrieren. Nicht direkt in Nodemon, aber in eine Abhängigkeit davon.

Ich will hier gar nicht so weit ausholen, die Jungs von https://snyk.io/ haben eine absolut sehenswerte Chronologie erarbeitet. Mein Sophos Anti-Virus hat vorhin im Übrigen auch angeschlagen, als ich ein Repo aus meinem Git gezogen habe.

Ziemlich krass wie ich finde!

Schönes Wochenende!

Das Fazit des Beitrages ->

The series of events that have been described in this blog are another reminder of how fragile the open-source model can be if not respected. If widely used packages, such as event-stream, were supported by just a small proportion of those who consume it, and take value from it, the malicious takeover could easily have been avoided. The event-stream package was included as a dependency all over the npm ecosystem, being included in at least 3931 packages as a dependency. Most notably, affecting top level packages such as: @vue/cli-ui, vscode, nodemon, and ps-tree.

The malicious package could have even remained unnoticed if not for the deprecation message that caused Jayden Seric to open an issue on the nodemon package. Otherwise, it’s likely it would have not been found for a long time.

 

[Yuuri]

https://www.golem.de/news/event-stream-populaeres-npm-paket-verteilt-schadsoftware-1811-137935.html

 

[new Account()]

Ziemlich krass wie ich finde!

Definitiv, die Frage ist, was man dagegen macht?

 

[Kalsarikännit]

seine Anwendungen nicht aus tausenden solcher Pakete zusammenklatschen?

 

[Sithys]

@Kalsarikännit tut mir leid, ich hatte in Deinem Benutzernamen erst das Wort "Käse" gelesen. Das hätte zu Deinem Beitrag gepasst.

 

[new Account()]

@Kalsarikännit
Hättest du in diesem Fall nur eine einzige Abhängigkeit - die Library EventStreams verwendet, hättest du schon ein Problem mit deiner Anwendung.
Dass die Library selbst 7 Abhängigkeiten hat, ist jetzt auch weit von tausenden Paketen weg.

Oder nur Libraries benutzen, die keine Abhängigkeiten haben? Ja, das dürfte interessant werden, zudem ja auch eine von diesen Libraries betroffen sein kann.

 

[Kalsarikännit]

ich verstehe es halt trotzdem nicht - wie kann man man Sicherheit sicherstellen indem man Millionen von Zeilen einbindet über die man reichlich wenig Kontrolle hat?

Käse wäre dann "juusto".

 

[Sithys]

... @vue/cli-ui, vscode, nodemon, and ps-tree....

Das sind riesige Pakete, die von der halben Welt eingesetzt werden.

 

[new Account()]

ich verstehe es halt trotzdem nicht - wie kann man man Sicherheit sicherstellen indem man Millionen von Zeilen einbindet über die man reichlich wenig Kontrolle hat?

Das ist die Frage.
Eine Lösung ist aber sicherlich nicht (okay kommt darauf an, was man programmiert) keinen Code mehr einzubinden und alles selbst zu programmieren

 

[Kalsarikännit]

bin ich ganz bei dir. Was mir allerdings auffällt, vor allem bei den jüngeren Kollegen, dass bei einem Problem erst mal irgendwo nach einem Paket gesucht wird, und wenn es z.B. nur darum geht ein Bild zu skalieren.

natürlich war "tausende Pakete zusammenklatschen" reichlich überspitzt, aber gefühlt geht der Trend dorthin. Ist natürlich auch dem Druck geschuldet, Software immer schneller erstellen zu müssen.

 

[Sithys]

Bin ich zu 100% bei Dir und wie new Account() schreibt, muss man dann eben alles selbst programmieren. Nur das wird dem von dir erwähnten Anspruch "Software immer schneller erstellen zu müssen" nicht gerecht. Ich bin auch ein Fan davon, nach Möglichkeit vieles selbst zu machen. Nur manchmal ist man eben drauf angewiesen, andere Pakete einzubinden. Und wenn dann noch solche großen Pakete verseucht sind, ist das echt übel.

 

[andy_m4]

ist im Bereich rund um den Paket-Manager NPM was ziemlich erstaunliches passiert.

Wieso erstaunlich? Ist ja nicht das erste Mal das so was passiert.
Wird Zeit, dass jemand mal diesen ganzen node.js-Sumpf trocken legt.

 

[Kalsarikännit]

nach Lesen dieses Tweets bin ich auch gottfroh, nur serverseitig unterwegs zu sein, da ist die Notwendigkeit, Bibliotheken einzubinden, zwar auch vorhanden, aber bei weitem nicht in diesem Maße wie frontendseitig, und auch per nuget kann man sich Müll in die Anwendung ziehen...

https://twitter.com/garybernhardt/status/1067170893401546759 (da wären wir dann auch bei den tausenden an Paketen ;-)

 

[BeBur]

Eine Lösung besteht darin, die Versionen der Abhängigkeiten zu fixieren. Dann muss man natürlich schauen, dass man security-fixes dennoch bekommt.
Eine andere Vorgehensweise besteht darin, keine Pakete einzubinden, die zu viele Abhängigkeiten haben, bzw. unnütze von z.B. mini-paketen mit trivialer Funktionalität. Ebenso keine, die nicht mehr aktiv maintained werden. Letzteres hätte dazu geführt, dass man event-stream nicht einbindet.

Im Idealfall hält man sich von dem riskanten node.js ökosystem fern, das ja nicht zum ersten mal mit Problemen geradezu apokalyptischen ausmaßes auffällt.

 

[mastaqz]

Wie wird das in anderen Programmiersprachen gemanagt?

 

[BeBur]

Vom Prinzip her nicht viel anders.
Aber siehe hier z.B.: http://www.modulecounts.com/
Für node.js ist das drei- bis fünffache an Modulen verzeichnet. Massiv.
Bei Ruby ergeben die trivialen Module schon keinen Sinn, weil die Funktionen von Ruby selbst zur Verfügung gestellt werden. Für node.js/JS könnte es Sinn ergeben, wenn ein Haufen Funktionalität in ein einzelnes Modul zusammengefasst wird. Oder wenn es eine Sammlung von einem größeren Unternehmen gäbe.

 

[new Account()]

Für JS könnte es Sinn ergeben, wenn ein Haufen Funktionalität in ein einzelnes Modul zusammengefasst wird. Oder wenn es eine Sammlung von einem größeren Unternehmen gäbe.

Bringt aber auch nicht wirklich was, weil das Hauptproblem ja nicht die Module sind, sondern die Quellen (Personen(gruppen)) von Schadcode.

 

[BeBur]

Wie meinst du das genau?

 

[new Account()]

Die Gefahr Schadcode zu bekommen verringert sich nicht dadurch, dass ein Unternehmen seine 1500 Pakete auf eins zusammenfasst.

 

[andy_m4]

Ein Problem sind schon mal die Leute die sich so im node.js Umfeld versammeln. Nicht selten so der Typus: "Boah. Javascript. Das haben wir doch auch im Browser und dort kann man tolle blinkende Werbebanner machen. Wenn wir die Sprache jetzt auch für den Server nutzen könnten? Geil!"
Ich will nicht sagen, dass alle node.jsler so sind. Aber das Ökosystem zieht halt solche Leute an. Die bedienen sich wo es geht (egal obs immer Sinn macht) und wenn ein Stück Code fehlt, wird auf StackOverflow.com gesucht.
Jeder benutzt alles. Aber keiner fühlt sich verantwortlich oder macht sich überhaupt darüber Gedanken, dass er jetzt von irgendwoher quasi ungeprüften Code zieht.

In einem solchen Ökosystem ist es natürlich leicht auch mal etwas einzuschmuggeln was eben nicht ganz koscher ist.

Richtig. Andere Projekte haben das Problem prinzipiell auch. Man braucht gar nicht mal bei Programmiersprachen gucken. Man braucht nur bei Linux-Distributionen zu gucken. Die machen ja nix anderes als Code irgendwo zu ziehen und dann zu einem schicken Paket für den Endanwender zu schnüren.

Und die kriegen das in aller Regel auch relativ gut hin. Klar können die nicht alles durchreviewen. Aber da ist dann halt zumindest noch eine Instanz die so ein bisschen ein Auge drauf hat.

Bei node.js fehlen solche oder ähnliche Prozesse ganz. Das war ein Hype und ist halt auch schnell (quasi unkontrolliert) schnell gewachsen und nu merkt man, dass man letztlich auch nur mit Wasser kocht und mit den gleichen Problematiken zu kämpfen hat wie alle anderen auch. Nur haben alle anderen eben schon entsprechende Maßnahmen etabliert. node.js hat schon damit angefangen, aber ist eben noch nicht so weit.
Und das äußert sich dann halt in solchen Vorfällen.