Schadcode in npm Paketen laut Heise

Skydream

Moin,

laut Heise news von heute 8.11 wurde die npm Pakete
coa
2.0.3, 2.0.4, 2.1.1, 2.1.3, 3.0.1, 3.1.3
und
rc
1.2.9, 1.3.9, 2.3.9
kompromittiert und mit Schadcode versehen.

Muss ich mir bei ioBroker sorgen machen?

Thomas Braun

@skydream Musst du selber schauen

echad@chet:~ $ cd /opt/iobroker/
echad@chet:/opt/iobroker $ npm list rc
iobroker.inst@3.0.0 /opt/iobroker
├─┬ iobroker.iot@1.8.24
│ └─┬ sharp@0.28.1
│   └─┬ prebuild-install@6.1.4
│     └── rc@1.2.8
├─┬ iobroker.sainlogic@0.7.3
│ └─┬ np@7.5.0
│   └─┬ npm-name@6.0.1
│     ├─┬ registry-auth-token@4.2.1
│     │ └── rc@1.2.8 deduped
│     └─┬ registry-url@5.1.0
│       └── rc@1.2.8 deduped
└─┬ iobroker.zigbee@1.6.3
  ├─┬ zigbee-herdsman-converters@14.0.256
  │ └─┬ zigbee-herdsman@0.13.148
  │   └─┬ @serialport/bindings@9.0.4
  │     └─┬ prebuild-install@6.1.4
  │       └── rc@1.2.8
  └─┬ zigbee-herdsman@0.13.149
    └─┬ serialport@9.2.3
      └─┬ @serialport/bindings@9.2.3
        └─┬ prebuild-install@6.1.4
          └── rc@1.2.8

echad@chet:/opt/iobroker $ npm list coa
iobroker.inst@3.0.0 /opt/iobroker
└── (empty)

echad@chet:/opt/iobroker $

Skydream

@thomas-braun
Danke...grade geschaut hier auch max 1.2.8, also warscheinlich sauber.
Nur ich frage mich wie es mit Modulupdates in naher Zukunft aussieht.
Gibt es eine Liste wo die drin sind? Oder ist das nur im ioBroker selber?

Wer lesen kann ist im Vorteil...man sieht das es im u.a. im Zigbee Modul drin ist

Thomas Braun

@skydream
Die Dependencies siehst du doch oben.

Ist halt in jeder Installation anders.

Feuersturm

@skydream Du kannst ja in deinem ersten Beitrag noch den Link zum Artikel https://www.heise.de/news/Unbekannte-infiltrieren-Paketmanager-npm-und-verseuchen-Tools-mit-Schadcode-6260153.html hinterlegen.

OpenSourceNomad

@skydream schlimmer geht immer: https://github.blog/2021-11-15-githubs-commitment-to-npm-ecosystem-security/

a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization

:boom:

...und seit wann genau?

This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously.

:facepunch:

apollon77

Sie gehen aber sehr transparent damit um. Solche Dinge passieren, das wissen wir alle und alles steht und fällt damit wie man damit umgeht.

OpenSourceNomad

@apollon77 said in Schadcode in npm Paketen laut Heise:

Sie gehen aber sehr transparent damit um.

Mehr Schein als sein würde ich sagen.

Die Lücke wurde von extern gemeldet weswegen Github gar keine andere Möglichkeit hatte als die halbe (oder ganze?) PR Abteilung darauf los zu lassen. Sie mussten damit rechnen das die Lücke nach einer responsible disclosure veröffentlicht wird.

Man sieht es ja ganz gut an dem Artikel der meiner Meinung in die Kategorie "ass covering" fällt (hauptsächlich marketing sprech und kaum aussagekräftige technisch Details).

Das beste ist ja noch wie sie auf ihre "tolles" 2fa hinweisen und raten diese zu aktivieren obwohl genau die Lücke trotz aktiver 2fa ausgenutzt werden konnte :face_palm:

apollon77

@opensourcenomad Naja ... Zeig mir eine IT Firma bei der es anders gelaufen wäre? ;-)

OpenSourceNomad

Naja

@apollon77 ich würde sagen die PR Abteilung von github hat ganze Arbeit geleistet wenn sie es schaffen das Leute den Vorgang plötzlich für "sehr transparent" halten und nicht sagen das ist ja "das mindestese".

Es gibt übrigens Sprachen in denen das Wort Werbung übersetzt Propaganda ist. Die Manipulation von Vorstellungen und Haltungen ist auch genau das für was PR Abteilungen von Firmen zuständig sind, dafür gibt auch Github Millionen aus.

Github hat es geschafft statt einen verdienten shit storm der extraklasse (wegen elementaren Mängeln wie nicht funktionierender 2fa und rba) heil aus der Sache rauszukommen.

@apollon77 said in Schadcode in npm Paketen laut Heise:

Zeig mir eine IT Firma bei der es anders gelaufen wäre?

Sie standen mit dem Rücken zur Wand und hatten keine andere Wahl, was hätten sie den anders machen können?

AlCalzone

@opensourcenomad sagte in Schadcode in npm Paketen laut Heise:

Die Lücke wurde von extern gemeldet weswegen Github gar keine andere Möglichkeit hatte

Die Aussage versteh ich nicht. Die wurde über Githubs Bug Bounty-Programm gemeldet und innerhalb 6 Stunden geschlossen. Bei so einer kritischen Lücke nachträglich zu beruhigen find ich da sogar angebracht.

Da ist man von Apple oder der CDU andere Dinge gewöhnt...

OpenSourceNomad

@alcalzone said in Schadcode in npm Paketen laut Heise:

Die wurde über Githubs Bug Bounty-Programm gemeldet

Das ist quasi nicht mehr als eine Pseudoversicherung für schlechte Codequalität heutzutage. Nur hoffen das niemand anderes mehr für die Lücke(n) im eigenen Produkt zahlt....

und innerhalb 6 Stunden geschlossen.

Die "Aufräumarbeiten" werden noch Monate dauern, wurde ja schon angekündigt. Ich könnte mir gut vorstellen das da noch so einiges brodelt was die lieber nicht "transparent" machen wollen...

This is why we will begin to require two-factor authentication (2FA) during authentication for maintainers and admins of popular packages on npm, starting with a cohort of top packages in the first quarter of 2022. We are currently evaluating next steps to ensure that the strongest and most user-friendly authentication options, such as WebAuthn, are available and accessible to developers using npm.

Genau die 2fa übrigens, die in der Vergangenheit im eigenen Haus leider total versagt hat. Und dann noch schön weiter evaluieren (das marketing team schon wieder am Werk?) um dann noch die technisch völlig absurde "strongest and most user-friendly authentication" These aufzustellen die jeder Informatik Student im ersten Semester total zerpflückt. Echte Sicherheit geht (leider) immer auf Kosten von Komfort (ergo usabilty). Fehlt eigentlich nur noch eine ordentliche Dosis Schlangenöl :face_palm:.

Bei so einer kritischen Lücke nachträglich zu beruhigen find ich da sogar angebracht.

Es hilft hallt nur nichts. Technisch rekapituliert hat in der Vergangenheit weder die Authentifizierung noch die Segmentierung jemals sauber funktioniert. Das ist die Basis für jedes Wald- und Wiesenprogramm wo mehr als ein User mit arbeitet.

Und wenn man genau liest beruhigen (oder beschwichtigen) sie ja nicht einmal sondern sagen ziemlich klar das sie keine Ahnung haben ob, wer und wann diese Lücke (eigentlich eher ein Loch oder Krater :hole:) ausgenutzt hat. Ziemlicher Totalschaden.

Da ist man von Apple oder der CDU andere Dinge gewöhnt...

Das man von der CDU keine Digitalkompetenz verlangen kann ist ja eigentlich klar. Die haben ja Hackertools verboten weswegen es ja eigentlich gar keine Hacker mehr geben kann. Verlangt ja auch niemand Korruptionsbekämpfung von dieser Partei oder Sozialkompetenzen bei der SPD.

Wobei die CDU den scheiß ja nicht selber programmiert haben, die haben nur genau so reagiert wie man es von ihnen erwartet hätte als sie auf Fehler hingewiesen wurden. Daran sehe ich eigentlich nichts wirklich verwerfliches dran.

OpenSourceNomad

@skydream said in Schadcode in npm Paketen laut Heise:

laut Heise news von heute 8.11

laut Heise news vom 17.11 :boom:

Jahrelange Sicherheitslücke im JavaScript-Repository NPM

Über die jetzt entdeckte Lücke war es jahrelang möglich, fremde JavaScript-Pakete durch eigene Versionen zu überschreiben.

[...] eine gravierende Sicherheitslücke [...]
[...] und die Lücke besteht bereits länger – wie lange genau, sagt Hanley nicht

https://www.heise.de/news/Jahrelange-Sicherheitsluecke-im-JavaScript-Repository-NPM-6270404.html

apollon77

@opensourcenomad Mensch bist du negativ drauf … ;-) will hier niemanden in Schutz nehmen (vor allem nicht GitHub oder npm) aber so wie du grad kannst man jede IT firma zerpflücken. Nur was bringt’s?!

OpenSourceNomad

@apollon77 said in Schadcode in npm Paketen laut Heise:

Mensch bist du negativ

Glaube nicht, ich lasse mich nur nicht gerne verarschen, anlügen und finde ebenfalls versuche mich zu manipulieren einfach nur unerträglich.

Ich finde es aber vor allem auch schlimm das sich so viele so leicht um den Finger wickeln lassen und rein gar nichts hinterfragen.

Grundsätzlich gebe ich dir soweit recht das code immer komplexer wird und daher leider auch immer schwieriger zu warten. Allerdings sind viele Sachen auch einfach hausgemacht und haben unnötig viele Abhängigkeiten die zu mehr Angriffsvektoren führen.

Als negativ Beispiel sei da jetzt z.B. mal ein Programm zum beschreiben von SD/Flash-Speichern namens balena etcher genannt. Das Teil ist über 300MB groß bringt mit electron einen fetten Rattenschwanz und mit Sicherheit einige schöne Sicherheitslücken mit. Für mich ist so eine Software nicht mehr als Bloatware, Spyware, Adware oder kurz :hankey:Ware (dafür ist 99,9% des codes zuständig). Die eigentliche (Kern)Funktion lässt sich auch in 300kb komplett ohne Abhängigkeiten nicht nur viel sicherer sondern nebenbei auch noch viel performanter verpacken. Als gutes Beispiel lässt sich hier usbimager nennen.

OliverIO

@opensourcenomad

Ok was würdest du github nun raten bzw.
Als ceo von github besser machen? und immer den shareholder value mit betrachten die dir im Nacken sitzen

OpenSourceNomad

@oliverio said in Schadcode in npm Paketen laut Heise:

immer den shareholder value mit betrachten

Wegen den shareholdern wird ja selbst heute noch bei deutschen Autobauern an Verbrennern festgehalten (weiter Profit aus jahrzehntealter Technik schlagen, das Investment wurde ja schon getätigt). Könnten wir hier jetzt natürlich weiter spielen aber grundsätzlich ist das halt einfach nur unser Kapitalismus im Endstadium. Kurzfristige Gewinne (für wenige) sind wichtiger als Nachhaltigkeit (für alle).

Du würdest als CEO (aus marktwirtschaftlichen Gesichtspunkten) wahrscheinlich auch das Angebot annehmen was dir die Entwicklung eines Produktes in einem Monat (Kartenhaustechnologie auf Sand gebaut) verspricht als ein anderes welches 10 Monate (mit ordentlichem Fundament) veranschlagt.

Der Witz daran (das zeigen uns ja genau Geschichten wie diese), selbst wenn dein Kartenhaus kollabiert war es am Ende (trotz horrender Ausgaben für PR) wahrscheinlich sogar wirtschaftlicher (nicht unbedingt billiger!) als ein ordentliches und ausgereiftes Produkt zu haben.

OliverIO

@opensourcenomad

du weißt was whataboutism ist?
ich glaube für solch einen Diskussionsstil ist Facbook besser.

OpenSourceNomad

@oliverio said in Schadcode in npm Paketen laut Heise:

du weißt was whataboutism ist?

Fragt tatsächlich genau die Person deren Post aus genau einer Frage besteht und shareholder in den Raum geworfen hat? :man-facepalming:

ist Facbook besser.

Im G'sichtsbuch bist du vielleicht tatsächlich besser aufgehoben :wink:

OpenSourceNomad

Um nach der Nebelkerze von @OliverIO mal wieder zurück zum Thema zu kommen und weil ich gerade über dieses schöne xkcd Bildchen gestolpert bin:

Kartenhaustechnologie

Im explain xkcd wiki zu diesem Bild wird übrigens auch npm erwähnt

Community Forum

NEWS

Schadcode in npm Paketen laut Heise

Support us

718

32.5k

81.7k

1.3m