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

251–260 of 1001 posts

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

#251

Post by orbital-decay »

shermantanktop wrote: post #245
rs999gti wrote: post #238

Earlier quoted context omitted.

> supply chain attacks You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages. Call it something like "free code attacks" or "hobbyist code attacks."

“code I picked up off the side of the road” “code I somehow took a dependency on when copying bits of someone’s package.json file” “code which showed up in my lock file and I still don’t know how it got there”

All of which is true for far too many projects

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

#252

Post by btown »

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…

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."

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

#253

Post by fulafel »

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…

They were new versions of the packages instead of modified existing ones so vendoring has the same effect as the usual practice of pinning npm deps and using npm ci, I think.

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

#254

Post by dist-epoch »

LeifCarrotson wrote: post #82
dist-epoch wrote: post #4

Earlier quoted context omitted.

It's just where the users and the juicy targets are. NPM packages are used by huge Electron apps like Discord, Slack, VS Code, the holy grail would be to somehow slip something inside them.

It's both that and a culture of installing a myriad of constantly-updating, tiny libraries to do basic utility functions. (Not even libraries, they're more like individual pages in individual books). In our line-of-business .NET app, we have a logger, a database, a unit tester, and a driver for some specialty hardware. We upgrade to the latest version of each external dependency about once per year (every major versi…

> Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data

> In July 2024, Bittensor users were the victims of an $8 million hack. The Bittensor hack was an example of a supply chain hack using PyPI. PyPI is a site that hosts packages for the Python programming language

https://www.halborn.com/blog/post/explained-the-bittensor-ha...

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

#255

Post by pixl97 »

hoppp wrote: post #132
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…

They are. Any language that depends heavily on package managers and lacks a standard lib is vulnerable to this. At some point people need to realize and go back to writing vanilla js, which will be very hard. The rust ecosystem is also the same. Too much dependence on packages. An example of doing it right is golang.

>and go back to writing vanilla js

Lists of things that won't happen. Companies are filled with node_modules importers these days.

Even worse, now you have to check for security flaws in that JS that's been written by node_modules importers.

That or there could someone could write a standard library for JS?

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

#256

Post by stinos »

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…

security updates and bugfixes only

Just wondering: while this is less of an attack surface, it's still a surface?

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

#258

Post by theodorejb »

eknkc wrote: post #102
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?

Does that even matter? The malware could have been a JS code injected into the module entry point itself. As soon as you execute something that imports the package (which, you did install for a reason) the code can run. I don't think that many people sandbox their development environments.

It absolutely matters. Many people install packages for front-end usage which would only be imported in the browser sandbox. Additionally, a package may be installed in a dev environment for inspection/testing before deciding whether to use it in production.

To me it's quite unexpected/scary that installing a package on my dev machine can execute arbitrary code before I ever have a chance to inspect the package to see whether I want to use it.

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

#259

Post by zarzavat »

qudat wrote: post #223
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.

I agree in principle, but child_process is a thing so I don't think it makes much difference. You are pwned either way if the package can ever execute code.

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

#260

Post by cesarb »

deanc wrote: post #187
psychoslave wrote: post #136

Earlier quoted context omitted.

How will multi-factor-authentication prevent such a supply chain issue? That is, if some attacker create some dummy trivial but convenient package and 2 years latter half the package hub depends on it somehow, the attacker will just use its legit credential to pown everyone and its dog. This is not even about stilling credentials. It’s a cultural issue with bare blind trust to use blank check without even any expiry…

That's an entirely different issue compared to what we're seeing here. If an attacker rug-pulls of course there is nothing that can be done about that other than security scanning. Arguably some kind of package security scanning is a core-service that a lot of organisations would not think twice about paying npm for.

> If an attacker rug-pulls of course there is nothing that can be done about that other than security scanning.

As another subthread mentioned (https://news.ycombinator.com/item?id=45261303), there is something which can be done: auditing of new packages or versions, by a third party, before they're used. Even doing a simple diff between the previous version and the current version before running anything within the package would already help.

Post reply on HN