←back to thread

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

(socket.dev)
1208 points jamesberthoty | 3 comments | 16 Sep 25 11:22 UTC | HN request time: 0.439s | 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 #
rlpb ◴[16 Sep 25 15:38 UTC] No.45263728[source]▶
There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made.

For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chore". While I agree it's nice to have consistent style, in some projects it seems to be the majority of the changes between releases. Due to the difficulty in auditing this, I consider this part of the software supply chain problem and something to be discouraged. Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.

replies(2): >>45265038 #>>45266945 #
kirici ◴[16 Sep 25 17:15 UTC] No.45265038[source]▶
I'm using difftastic, it cuts down a whole lot of the noise

https://difftastic.wilfred.me.uk/

replies(1): >>45265749 #
rlpb ◴[16 Sep 25 18:12 UTC] No.45265749[source]▶
This looks good! Unfortunately it looks like it also suffers from exactly the same software supply chain problem that we need to avoid in the first place: https://github.com/Wilfred/difftastic/blob/master/Cargo.lock

Edit: also, consider how much of https://github.com/Wilfred/difftastic/commits/master/ is just noise in itself. 15k commits for a project that appears to only be about four years old.

replies(1): >>45267376 #
1. weinzierl ◴[16 Sep 25 20:14 UTC] No.45267376[source]▶
"exactly the same software supply chain problem"

While the crates ecosystem is certainly not immune to supply chain attacks this over generalization is not justified.

There are several features that make crates.io more robust than npm. One of them is that vulnerable versions can be yanked without human intervention. Desperate comments from maintainers like this one[1] from just a few days ago would not happen with crates.io.

There are also features not provided by crates.io that make the situation better. For example you could very easily clone the repo and run

    cargo vet
to check how many of the packages had human audits. I'd done it if I was on a computer, but a quick glance at the Cargo.lock file makes me confident that you'd get a significant number.

[1] https://news.ycombinator.com/item?id=45170687

replies(2): >>45270940 #>>45272062 #
2. lukaslalinsky ◴[17 Sep 25 02:34 UTC] No.45270940[source]▶
I'd argue it's more of a culture thing, not technical thing.

In both JavaScript and Rust, it's normal/encouraged to just add a tiny dependency to the package manager. The communities even pride themselves, that they have such good package managers to allow this.

It's this "yeah, there is a crate for this tiny function I need, let's just include it" mentality that makes the ecosystem vulnerable.

People need to be responsible for whatever they include, either pay the price by checking all versions up front, or pay it by risking shipping a vulnerable program that it's much harder to retract than a JavaScript frontend.

3. inbx0 ◴[17 Sep 25 05:27 UTC] No.45272062[source]▶
The main issue there is that the maintainer lost access to their account. Yanking malicious packages is better, but even just being able to release new patch versions would've stopped the spread, but they were not able to do so for the packages that didn't have a co-publisher. How would crates.io help in this situation?

FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.

1: https://en.wikipedia.org/wiki/Npm_left-pad_incident