←back to thread

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

(socket.dev)
1208 points jamesberthoty | 1 comments | 16 Sep 25 11:22 UTC | HN request time: 0.341s | 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 #
btown ◴[16 Sep 25 14:50 UTC] No.45263089[source]▶
I'd like to think there are ways to do this and keep things decentralized.

Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates.

Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push directly to NPM, which would mean that any malware injector would need to first compromise the source code repository. Which, to be fair, wouldn't necessarily have stopped this worm from propagating entirely, but would have slowed its progress considerably.

This isn't a "sacrifice all of NPM's DX and decentralization" question. This is "a marginally more manual DX only when you're at a scale where you should be release-managing anyways."

replies(2): >>45263691 #>>45265306 #
noodlesUK ◴[16 Sep 25 15:35 UTC] No.45263691[source]▶
I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads.

Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

replies(5): >>45264100 #>>45265273 #>>45265343 #>>45266948 #>>45267592 #
thewebguyd ◴[16 Sep 25 16:04 UTC] No.45264100[source]▶
Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.
replies(1): >>45264470 #
ronsor ◴[16 Sep 25 16:31 UTC] No.45264470[source]▶
Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.
replies(5): >>45265686 #>>45266277 #>>45266585 #>>45266931 #>>45267621 #
1. LtWorf ◴[16 Sep 25 20:34 UTC] No.45267621[source]▶
Download counters are completely useless. I could download your package 2 million times in under a minute and cause you to need the 2FA.

And true 2FA means you can't automate publishing from github's CI. Python is going the other direction. There is a fake 2FA that is just used to generate tokens and there is a preferential channel to upload to pypi via github's CI.

But in my opinion none of this helps with security. But it does help to de-anonymise the developers, which is probably what they really want to do, without caring if those developers get hacked and someone else uses their identity to do uploads.