←back to thread

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

(socket.dev)
1208 points jamesberthoty | 4 comments | 16 Sep 25 11:22 UTC | HN request time: 0.027s | source
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 #
kees99 ◴[16 Sep 25 12:37 UTC] No.45261408[source]▶
I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages).

But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attractive target.

replies(1): >>45261968 #
znort_ ◴[16 Sep 25 13:27 UTC] No.45261968[source]▶
npm in itself isn't special at all, maybe the userbase is but that's irrelevant because the mitigation is pretty easy and 99.9999% effective, works for every package manager and boils down to:

1- thoroughly and fully analyze any dependency tree you plan to include 2- immediately freeze all its versions 3- never update without very good reason or without repeating 1 and 2

in other words: simply be professional, face logical consequences if you aren't. if you think one package manager is "safer" than others because magic reasons odds are you'll find out the hard way sooner or later.

replies(3): >>45262164 #>>45262676 #>>45274141 #
1. moi2388 ◴[16 Sep 25 14:25 UTC] No.45262676[source]▶
Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package
replies(2): >>45264021 #>>45270837 #
2. godshatter ◴[16 Sep 25 15:58 UTC] No.45264021[source]▶
As an outsider looking in as I don't deal with NPM on a daily basis, the 30k dependencies going 50 branches deep seems to be the real problem here. Code reuse is an admiral goal but this seems absurd. I have no idea if these numbers are correct or exaggerations but from my limited time working with NPM a year or two ago it seems like it's a definite problem.

I'm in the C ecosystem mostly. Is one NPM package the equivalent of one object file? Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? I guess it's a problem either way, internal dependencies having bugs vs supply chain attacks like these. Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

replies(1): >>45265158 #
3. marcosdumay ◴[16 Sep 25 17:26 UTC] No.45265158[source]▶
> Is one NPM package the equivalent of one object file?

No. The closest thing to a package (on almost every language) is an entire library.

> Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones?

Yes, they can. They just don't do it.

> Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

There aren't many unecessary dependencies, because the number of direct dependencies on each package is reasonable (on the order of 10). And you don't get a lot of unecessary code because the point of tiny libraries is to only import what you need.

Dead code is not the problem, instead the JS mentality evolved that way to minimize dead code. The problem is that dead code is actually not that much of an issue, but dependency management is.

4. znort_ ◴[17 Sep 25 02:20 UTC] No.45270837[source]▶
there are indeed monster packages but you should ask yourself if you need them at all, because if you really do there is no way around performing nr1. you get the code, you own it. you propagate malware by negligence, you're finished as a sw engineer. simple as that.

personally i keep dependencies at a minimum and are very picky with them, partly because of nr1, but as a general principle. of course if people happily suck in entire trees without supervision just to print ansi colors on the terminal or, as in this case, use fancy aliases for colors then bad things are bound to happen. (tbf tinycolor has one single devDependency, shim-deno-test, which only requires typescript. that should be manageable)

i'll grant you that the js ecosystem is special, partly because the business has traditionally reinforced the notion of it being accessory, superficial and not "serious" development. well, that's just naivety, it is as critical a component as any other. ideally you should even have a security department vetting the dependencies for you.