←back to thread

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

(socket.dev)
1208 points jamesberthoty | 5 comments | 16 Sep 25 11:22 UTC | HN request time: 0.001s | source
Show context
Meneth ◴[16 Sep 25 12:25 UTC] No.45261303[source]▶
This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person.

The general solution is to do what Debian does.

Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use.

Keep a testing/unstable distro where new packages and new versions can be added, but even then added only by the distro maintainer, NOT by the package developers. This is where the audits happen.

NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories.

replies(25): >>45261528 #>>45261617 #>>45261792 #>>45262591 #>>45262655 #>>45262978 #>>45263089 #>>45263137 #>>45263570 #>>45263728 #>>45264113 #>>45264189 #>>45265297 #>>45266032 #>>45266873 #>>45267343 #>>45268626 #>>45268669 #>>45269007 #>>45269777 #>>45270131 #>>45270753 #>>45272097 #>>45273282 #>>45273471 #
ncruces ◴[16 Sep 25 18:32 UTC] No.45266032[source]▶
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments.

Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-parties.

replies(7): >>45266877 #>>45266951 #>>45267014 #>>45267066 #>>45267203 #>>45267940 #>>45267944 #
zwnow ◴[16 Sep 25 19:35 UTC] No.45266877[source]▶
Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.
replies(2): >>45267089 #>>45267512 #
jen20 ◴[16 Sep 25 20:27 UTC] No.45267512[source]▶
Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.
replies(1): >>45267969 #
ncruces ◴[16 Sep 25 20:59 UTC] No.45267969[source]▶
Just the other day someone argued with me that it was reasonable for Limbo (the SQLite Rust rewrite) to have 3135 dependencies (of those, 1313 Rust dependencies).

https://github.com/tursodatabase/turso/network/dependencies

replies(3): >>45268596 #>>45270283 #>>45273091 #
Ygg2 ◴[17 Sep 25 01:00 UTC] No.45270283[source]▶
Yeah. You have dev dependencies in there, those alone will increase number of dependencies by ~500, without ending up in the final product.

Those numbers are way off their actual number.

replies(2): >>45271323 #>>45272468 #
1. ncruces ◴[17 Sep 25 06:30 UTC] No.45272468{6}[source]▶
Right. Allowing 500 strangers to push code to our CI infra, or developer laptops, with approximately zero review, sounds similarly ill advised.

That JLR got their factories hacked, rather than customer cars, is less bad for sure. But it's still pretty bad.

Also, before arguing that code generators should get a pass as they don't “end up in the final product”, you really should read “Reflections on trusting trust” by Ken Thompson.

replies(1): >>45273212 #
2. Ygg2 ◴[17 Sep 25 08:16 UTC] No.45273212[source]▶
> Right. Allowing 500 strangers to push code to our CI infra

That's bullshit, pure and simple. If you pull in a deeply nested dependency like icu_normalizer it has 30 dependencies, OMGHAXOZRS. I'm doing this, so I don't have to spend a day going through the library.

Except of the 30 depedencies crates, there are 10 from ICUX repository, and then you have almost standard dependencies like proc-macro/syn/quote crates from dtolnay, `zerofrom` from Google. `smallvec` from the Servo project, and yoke from... checks notes... from ICUX.

The only few remaining crates here are `write16`, `utf8_iter` and `utf16_iter` that are written from hsivonen, who is also a ICUX contributor.

So even for 30 dependencies, you actually depend on proc-macro/syn/quote which are foundational crates. Few crates from Google, few crates from Servo, and three crates written by another ICUX contributor.

We started with 30 dependencies and ended up with 3 strangers

replies(2): >>45273391 #>>45273569 #
3. ncruces ◴[17 Sep 25 08:43 UTC] No.45273391[source]▶
It's great that you did that due diligence once. It really is. If I were reviewing that merge request, and you told me that, I'd be inclined to approve.

But how do we scale that to 1000 dependencies, and every one of their updates? What tools are there to help us, and does the community at large use them?

What I really don't like, and why I wrote that it's a culture issue, is the lightness with which these decisions are often made.

My most popular library has about a dozen dependencies. The README states clearly and “above the fold” what are the core deps (3, no transitive). Every other dependency is either first party, or optional and justified with a comment in the deps file (if you don't use the optional feature, it doesn't end up in your deps file).

There's also a generated BLOB. The generation of the BLOB is reproducible in your own environment, and its provenance attestated.

Those are all risks, that I'm passing on to my users, but I do my best to mitigate them, and communicate this clearly to them.

4. Etherlord87 ◴[17 Sep 25 09:17 UTC] No.45273569[source]▶
Sorry, I don't know much about the subject, so this is not a rhetorical or even just loaded question:

Isn't it actually the case that you started with 3 strangers, but 27 of them were relatively easy (still took some time) to figure out as safe?

replies(1): >>45275437 #
5. Ygg2 ◴[17 Sep 25 13:13 UTC] No.45275437{3}[source]▶
You have 30 items you bought from various stores. You bought ~20 from yourself, around 5 from Google, 4 from hsivonen and one from servo.

You could of course investigate individuals commits, but that's probably an overkill.