Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

socket.dev

Post reply on HN
Print view View original

221–230 of 1001 posts

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

#221

Post by jmull »

codemonkey-zeta wrote: post #31

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 probab…

Simply avoiding Javascript won't cut it.

While npm is a huge and easy target, the general problem exists for all package repositories. Hopefully a supply chain attack mitigation strategy can be better than hoping attackers target package repositories you aren't using.

While there's a culture prevalent in Javascript development to ignore the costs of piling abstractions on top of abstractions, you don't have to buy into it. Probably the easiest thing to do is count transitive dependencies.

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

#222

Post by motorest »

epolanski wrote: post #108
motorest wrote: post #5

Earlier quoted context omitted.

> New day, new npm malware. Sigh.. This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?

Why are people using React to write simple ecommerces? Why are React devs pulling object utils from lodash instead of reimplementing them?

> Why are people using React to write simple ecommerces?

What leads you to believe React is not well suited to simple ecommerce sites?

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

#223

Post by qudat »

codemonkey-zeta wrote: post #31

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 probab…

The blast radius is made far worse by npm having the concept of "postinstall" which allows any package the ability to run a command on the host system after it was installed.

This works for deps of deps as well, so anything in your node_modules has access to this hook.

It's a terrible idea and something that ought to be removed or replaced by something much safer.

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

#224

Post by lyu07282 »

quotemstr wrote: post #160

Jesus Christ. Another one? What the fuck? This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? This whole mess was foreseeable. So what's to be done? Look. Any serious project needs to start vendoring its dependencies. People should establish big, coarse grained meta-distributions like C++ Boost that come from a trustable a…

Rust was hit by a similar attempt: https://github.com/rust-lang/crates.io/discussions/11889

Nothing much came of it, I don't know.

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

#225

Post by paulddraper »

Meneth wrote: post #91

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…

Go’s package repository is just GitHub.

At the end of the day, it’s all a URL.

You’re asking for a blessed set of URLs. You’d have to convince someone to spend time maintaining that.

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

#226

Post by imtringued »

karel-3d wrote: post #77
gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

There is a guy (ljharb) who is literally on TC39 - JavaScript specification committee - who is maintaining like 600 packages full of polyfills/dependencies/utilities. It's just javascript being javascript.

That wouldn't be a problem if there was proper package signing and the polyfill packages were hosted under a package namespace owned by the javascript specification committee.

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

#227

Post by moi2388 »

znort_ wrote: post #166
kees99 wrote: post #109

Earlier quoted context omitted.

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 attrac…

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 l…

Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package

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

#228

Post by tln »

philipwhiuk wrote: post #49

post-install seems like it shouldn't be necessary anyway, let alone need shell access. What are legitimate JS packages using this for?

I think these compromises show that install hooks should be severely restricted.

Something like, only packages with attestations/signed releases and OIDC-only workflow should allow these scripts.

Worm could propogate through the code itself but I think it would be quite a bit less effective.

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

#229

Post by bapak »

karel-3d wrote: post #77
gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

There is a guy (ljharb) who is literally on TC39 - JavaScript specification committee - who is maintaining like 600 packages full of polyfills/dependencies/utilities. It's just javascript being javascript.

Irrelevant here. You use eslint-plugin-import with its 60 dependencies; One dependency or 60 is irrelevant because you only need one token: his. They're all his packages.

The problem with that guy is that the dependencies are useless to everyone except his ego.

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

#230

Post by dmix »

benmccann wrote: post #156
homebrewer wrote: post #66

When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project i…

Yes, eslint is particularly frustrating: https://npmgraph.js.org/?q=eslint There are plenty of people in the community who would help reduce the number of dependencies, but it really requires the maintainers to make it a priority. Otherwise the only way to address it is to switch to another solution like oxlint.

I tried upgrading ESLint recently and it took me forever to fix all the dependency issues. I wish I never used ESLint prettier as now my codebase styling is locked into an ESLint config :/
Post reply on HN