NPM Paket Nodemon mit Backdoor / Trojaner versehen

RedGunPanda

Commander
Dabei seit
Dez. 2010
Beiträge
2.846
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.

Screenshot_23.png


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.
 
Zuletzt bearbeitet:

new Account()

Rear Admiral
Dabei seit
Mai 2018
Beiträge
5.249

Kalsarikännit

Lieutenant
Dabei seit
Aug. 2012
Beiträge
897
seine Anwendungen nicht aus tausenden solcher Pakete zusammenklatschen?
 

new Account()

Rear Admiral
Dabei seit
Mai 2018
Beiträge
5.249
@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

Lieutenant
Dabei seit
Aug. 2012
Beiträge
897
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".
 

new Account()

Rear Admiral
Dabei seit
Mai 2018
Beiträge
5.249

Kalsarikännit

Lieutenant
Dabei seit
Aug. 2012
Beiträge
897
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.
 

RedGunPanda

Commander
Ersteller dieses Themas
Dabei seit
Dez. 2010
Beiträge
2.846
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.
 

Kalsarikännit

Lieutenant
Dabei seit
Aug. 2012
Beiträge
897
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

Lieutenant
Dabei seit
Nov. 2018
Beiträge
955
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.
 

BeBur

Lieutenant
Dabei seit
Nov. 2018
Beiträge
955
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()

Rear Admiral
Dabei seit
Mai 2018
Beiträge
5.249

new Account()

Rear Admiral
Dabei seit
Mai 2018
Beiträge
5.249
Die Gefahr Schadcode zu bekommen verringert sich nicht dadurch, dass ein Unternehmen seine 1500 Pakete auf eins zusammenfasst.
 

andy_m4

Commander
Dabei seit
Aug. 2015
Beiträge
2.785
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.
 
Top