←back to thread

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

(socket.dev)
1208 points jamesberthoty | 8 comments | 16 Sep 25 11:22 UTC | HN request time: 0s | source | bottom
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 #
1. rectang ◴[16 Sep 25 19:49 UTC] No.45267066[source]▶
It's not unreasonable to trust large numbers of trustworthy dependency authors. What we lack are the institutions to establish trust reliably.

If packages had to be cryptographically signed by multiple verified authors from a per-organization whitelist in order to enter distribution, that would cut down on the SPOF issue where compromising a single dev is enough to publish multiple malware-infested packages.

replies(3): >>45267357 #>>45268097 #>>45270906 #
2. dboreham ◴[16 Sep 25 20:12 UTC] No.45267357[source]▶
Problem is that beyond some threshold number of authors, the probability they're all trustworthy falls to zero.
replies(1): >>45267458 #
3. rectang ◴[16 Sep 25 20:22 UTC] No.45267458[source]▶
It's true that smuggling multiple identities into the whitelist is one attack vector, and one reason why I said "cut down" rather than "eliminate". But that's not easy to do for most organizations.

For what it's worth, back when I was active at the ASF we used to vote on releases — you needed at least 3 positive votes from a whitelist of approved voters to publish a release outside the org and there was a cultural expectation of review. (Dunno if things have changed.) It would have been very difficult to duplicate this NPM attack against the upstream ASF release distribution system.

4. WesolyKubeczek ◴[16 Sep 25 21:10 UTC] No.45268097[source]▶
"Find large numbers of trustworthy dependency authors in your neighborhood!"

"Large numbers of trustworthy dependency authors in your town can't wait to show you their hottest code paths! Click here for educational livecoding sessions!"

replies(1): >>45269857 #
5. rectang ◴[16 Sep 25 23:54 UTC] No.45269857[source]▶
I don't understand your critique.

Establishing a false identity well enough to fool a FOSS author or organization is a lot of work. Even crafting a spear phishing email/text campaign doesn't compare to the effort you'd have to put in to fool a developer well enough to get offered publishing privileges.

Of course it's possible, but so are beat-them-with-a-five-dollar-wrench attacks.

6. jitix ◴[17 Sep 25 02:30 UTC] No.45270906[source]▶
It IS unreasonable to trust individual humans across the globe in 100+ different jurisdictions pushing code that gets bundled into my application.

How can you guarantee a long trusted developer doesn't have a gun pointed to their head by their authoritarian govt?

In our B2B shop we recently implemented a process where developers cannot add packages from third party sources - only first party like meta, google, spring, etc are allowed. All other boilerplate must be written by developers, and on the rare occasion that a third party dependency is needed it's copied in source form, audited and re-hosted on our internal infrastructure with an internal name.

To justify it to business folks, we presented a simple math where I added the man-hours required to plug the vulnerabilities with the recurring cost of devsecops consultants and found that it's cheaper to reduce development velocity by 20-25%.

Also devsecops should never be offshored due to the scenario I presented in my second statement.

replies(2): >>45271074 #>>45274000 #
7. rectang ◴[17 Sep 25 02:55 UTC] No.45271074[source]▶
You've presented your argument as if rebutting mine, but to my mind you've reinforced my first paragraph:

* You are trusting large numbers of trustworthy developers.

* You have established a means of validating their trustworthiness: only trust reputable "first-party" code.

I think what you're doing is a pretty good system. However, there are ways to include work by devs who lack "first-party" bona-fides, such as when they participate in group development where their contributions are consistently audited. Do you exclude packages published by the ASF because some contributions may originate from troublesome jurisdictions?

In any case, it is not necessary to solve the traitorous author problem to address the attack vector right in front of us, which is compromised authors.

8. user34283 ◴[17 Sep 25 10:26 UTC] No.45274000[source]▶
If someone is wondering how effective such an approach is going to be with npm, consider the following:

If you add jest, the popular test runner by Meta, that's adding 300 packages to your dependency graph.

And here we don't yet have a bundler, linter, code formatter, or even web framework.

So good luck with minimizing those dependencies.