Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?
-
@albert said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@oliverio Danke!
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.Dann sollte alles i.O. sein.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.
npm audit und die sort gelisteten vulnarabilities erleichtern oder verhindern in keiner Weise dass du in Zukunft ein bösartiges Paket installierst. Dass npm audit vulnarbilities meldet ist eher als normal anzusehen. Eine saubere Bereinigung kann hier eigentlich nur der Entwickler des betroffenen Pakats vornehmen,
-
@armilar said in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
@mcm1957 sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Auf kritische Dinge in sub sub Paketen hat der Dev im Allgemeinen keinen Einfluss ...
und das dürfte das Hauptproblem sein...
Diese Liste wird in der Regel aktuell gehalten...
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
ist mit aktuell 477 NPM Paketen nicht grade kurz und wächst noch weiter...
Ja, nur da hilft npm audit praktisch nichts.
Persönlich würde ich DRINGEND davon ABRATEN auf einem produktiven Sytem eben mal mit npm audit --fix was zu verändern.
Kann zwar jeder machen was er will - aber bitte nachher nicht heulen wenn nichts mehr geht.
-
Ja, ich würde mir davon ebenso abraten... Wie das System früher mal war, weiß ich ja
-
@mcm1957 Ich habe vorher einen Snapshot gemacht. War auch gut so. Es wurden teils uralte Adapter Versionen installiert...Lief natürlich nachher nix mehr.
Also wieder einen Rollback gemacht. -
@msauer
Danke für Info. Ev. lesen es genug BEVOR sie ihr System schrotten
-
npm audit meldet bei meinem Produktivsystem eine Unmenge von Issues diverser Severities. Für User m.E. unverständlich. Für einen Check im Rahmen des Releases eher zuviel / undurchsichtig.
Hmm ....
martin@iobroker-test-sicher:~$ npm audit --verbose npm verbose cli /usr/bin/node /usr/bin/npm npm info using npm@10.9.3 npm info using node@v22.19.0 npm verbose title npm audit npm verbose argv "audit" "--loglevel" "verbose" npm verbose logfile logs-max:10 dir:/home/martin/.npm/_logs/2025-09-17T14_32_02_986Z- npm verbose logfile /home/martin/.npm/_logs/2025-09-17T14_32_02_986Z-debug-0.log npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 941ms found 0 vulnerabilities npm verbose cwd /home/martin npm verbose os Linux 6.8.12-15-pve npm verbose node v22.19.0 npm verbose npm v10.9.3 npm verbose exit 0 npm info ok martin@iobroker-test-sicher:~ -
Und weil wir gerade bei Checks und Audits sind:
Im
iob diaggibt es ja auch einen solchen Test, der bezieht sich aber NUR auf die nodejs-Version und dort bekannte Sicherheitsprobleme. Da wird nicht auf die einzelnen Module geschaut. -
@martinp sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
npm verbose cwd /home/martin
Du stehst im falschen Verzeichnis...
Stell dich dahin, wo der ioBroker wohnt, dann wird da auch was ausgespuckt. -
gelöscht als ergebnis von 2 parallel geöffneten kommentarfenstern
-
@albert sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
Ich habe dein Skript laufen lassen und es meldet dass nichts gefunden ist.
npm audit meldet aber einige vulnerabilities, jetzt befürchte ich dass ich mir ein verseuchtes Paket mit einem Update installieren könnte.ja das sieht für die meisten ähnlich aus.
57 vulnerabilities (11 low, 15 moderate, 28 high, 3 critical)primär ist der audit befehl für die entwickler. dann ist das skript doch nicht ganz so schlecht, allerdings zeigt es nur einen teil, nicht aktuellen stand der wahrheit.
die meisten probleme sind nicht wirklich kritisch, da es nicht bedeutet, das problem in funktionen steckt die nicht verwendet werden. behoben werden sollten sie dennoch, aber:
da die verwendeten abhängigkeiten eine baumstruktur abbilden, also packet ist von packet ist von packet abhängig, ist es nicht so einfach das zu beheben. insbesondere benötigt man die mithelfe von den maintainer der anderen packete (diese dann aber auch wieder der maintainer deren verwendeten packete).
für viele probleme gibt es bereits verbesserte packete, allerdings durch die vielfältige verflechtungen muss immer der kleinste gemeinsame nenner genommen werden, so das oft wegen wenigen blockierern das neuere/bessere packet nicht verwendet werden kann.
die selbe problematik hat man auch unter windows (DLL Hölle genannt, kenne ich aber auch noch ähnlich bei PHP) bei python weiß ich nicht, aber bei npm nun auch. das war aber absehbar.
die folgende grafik zeigt das sehr gut
-
@oliverio sagte in Nach Angriff auf node.js: Sofortmaßnahmen erforderlich?:
die selbe problematik hat man auch unter windows (DLL Hölle genannt, kenne ich aber auch noch ähnlich bei PHP) bei python weiß ich nicht, aber bei npm nun auch.
Gleiches 'Phänomen' bei Linux Distributionen, da halt statt 'DLL Hölle' die 'Dependency Hell'. Die wird umso größer, je mehr Paketquellen von Dritten und/oder vorherigen Releases da angelegt sind.
