←back to thread

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

(socket.dev)
1208 points jamesberthoty | 9 comments | 16 Sep 25 11:22 UTC | HN request time: 0.283s | source | bottom
Show context
codemonkey-zeta ◴[16 Sep 25 11:56 UTC] No.45261026[source]▶
I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem.

These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probably be faster and less janky anyway.

replies(18): >>45261086 #>>45261121 #>>45261140 #>>45261165 #>>45261220 #>>45261265 #>>45261285 #>>45261457 #>>45261571 #>>45261702 #>>45261970 #>>45262601 #>>45262619 #>>45262851 #>>45267210 #>>45268405 #>>45269073 #>>45273081 #
lucideer ◴[16 Sep 25 12:21 UTC] No.45261265[source]▶
> I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem.

I see this odd take a lot - the automatic narrowing of the scope of an attack to the single ecosystem it occurred in most recently, without any real technical argument for doing so.

What's especially concerning is I see this take in the security industry: mitigations put in place to target e.g. NPM, but are then completely absent for PyPi or Crates. It's bizarre not only because it leaves those ecosystems wide open, but also because the mitigation measures would be very similar (so it would be a minimal amount of additional effort for a large benefit).

replies(7): >>45261389 #>>45261408 #>>45261464 #>>45262010 #>>45263376 #>>45266913 #>>45270888 #
WD-42 ◴[16 Sep 25 13:30 UTC] No.45262010[source]▶
I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.
replies(3): >>45262394 #>>45262453 #>>45263490 #
johnisgood ◴[16 Sep 25 14:07 UTC] No.45262453[source]▶
Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.
replies(2): >>45263514 #>>45265047 #
1. Klonoar ◴[16 Sep 25 17:16 UTC] No.45265047[source]▶
Your typical Rust project does not have over 1000 dependencies.

Zed is not a typical Rust project; it's a full fledged editor that includes a significant array of features and its own homegrown UI framework.

replies(2): >>45267992 #>>45273067 #
2. worik ◴[16 Sep 25 21:01 UTC] No.45267992[source]▶
What is a "typical Rust project", I wonder?
replies(1): >>45268783 #
3. cesarb ◴[16 Sep 25 22:04 UTC] No.45268783[source]▶
One famous example is ripgrep (https://github.com/BurntSushi/ripgrep). Its Cargo.lock (which contains all direct and indirect dependencies) lists 65 dependencies (it has 66 entries, but one of them is for itself).
replies(2): >>45269118 #>>45277060 #
4. burntsushi ◴[16 Sep 25 22:32 UTC] No.45269118{3}[source]▶
Also, that lock file includes development dependencies and dependencies for opt-in features like PCRE2. A normal `cargo build` will use quite a bit fewer than 65 dependencies.

I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies.

We aren't quite at thousands of dependencies yet though.

replies(1): >>45277112 #
5. wolvesechoes ◴[17 Sep 25 07:51 UTC] No.45273067[source]▶
> Zed is not a typical Rust project; it's a full fledged editor

Funny that text editor is being presented here as some kind of behemoth, not representative of typical software written in Rust. I guess typical would be 1234th JSON serialization library.

6. johnisgood ◴[17 Sep 25 15:31 UTC] No.45277060{3}[source]▶
Not quite. He is a better developer than most who happen to minimize dependencies, but according to my experiences it is not as common as you would like to believe. Do I really need to make a list of all the Rust projects I have compiled that pulled in over 1000 dependencies? If I need to do it to convince you, I will do so, as my time allows.
7. johnisgood ◴[17 Sep 25 15:35 UTC] No.45277112{4}[source]▶
> I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies.

Thank you for your honesty, and like you and I said, you put a lot of energy into keeping the dependency tree slim. This is not as common as one would like to believe.

replies(1): >>45277366 #
8. burntsushi ◴[17 Sep 25 15:54 UTC] No.45277366{5}[source]▶
I agree it's not common. But neither are Rust applications with 1000+ dependencies. I don't think I've ever compiled a Rust project with over 1,000 dependencies.

Hundreds? Yes, absolutely. That's common.

replies(1): >>45277672 #
9. johnisgood ◴[17 Sep 25 16:11 UTC] No.45277672{6}[source]▶
Maybe I am just unlucky enough to always running into Rust projects that pull in over 1000 dependencies. :D

In retrospect, I should have kept a list of these projects. I probably have not deleted these directories though, so I probably still could make a list of some of these projects.