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

291–300 of 1001 posts

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

#291

Post by lucideer »

simiones wrote: post #278
lucideer wrote: post #81

Earlier quoted context omitted.

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

Most people have addressed the package registry side of NPM. But NPM has a much, much bigger problem on the client side, that makes many of these mitigations almost moot. And that is that `npm install` will upgrade every single package you depend on to its latest version that matches your declared dependency, and in JS land almost everyone uses lax dependency declarations. So, an attacker who simply publishes a new p…

> in JS land almost everyone uses lax dependency declarations

They do, BUT.

Dependency versioning schemes are much more strictly adhered to within JS land than in other ecosystems. PyPi is a mishmash of PEP 440, SemVer, some packages incorrectly using one in the format of the other, & none of the 3 necessarily adhering to the standard they've chosen. Other ecosystems are even worse.

Also - some ecosystems (PyPi again) are committing far worse offences than lax versioning - versionless dependency declaration. Heavy reliance on requirements.txt without lockfiles where half the time version isn't even specified at all. Astral/Poetry are improving the situation here but things are still bad.

Maven land is full of plugins with automated pom.xml version templating that has effectively the same effect as lax versioning, but without any strict adherence to any kind of standard like semver.

Yes, the situation in JS land isn't great, but there are much worse offenders out there.

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

#292

Post by Yasuraka »

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…

> NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories

Can you point me to Go's centralized package repository?

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

#293

Post by Ajedi32 »

int_19h wrote: post #284
Ajedi32 wrote: post #237

Earlier quoted context omitted.

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.

With Node the final deliverable is an app that comes packaged with all its dependencies, and often bundled into a single .js file, which is conceptually the same as a single binary produced by Go.

Can you give an example? While theoretically possible I almost never see that in Node projects. It's not even very practical because even if you do cram everything into a single .js file you still need an external dependency on the Node runtime.

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

#295

Post by lillecarl »

hombre_fatal wrote: post #247
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…

The problem with your idea is that you need to find the person who wants to do all this auditing of every version of Node/Python/Ruby libraries.

I believe good centralized infrastructure for this would be a good start. It could be "gamified" and reviewers could earn reputation for reviewing packages, common packages would be reviewed all the time.

Kinda like Stackoverflow for reviews, with optional identification and such.

And honestly an LLM can strap a "probably good" badge on things with cheap batch inference.

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

#296

Post by Tadpole9181 »

simiones wrote: post #278
lucideer wrote: post #81

Earlier quoted context omitted.

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

Most people have addressed the package registry side of NPM. But NPM has a much, much bigger problem on the client side, that makes many of these mitigations almost moot. And that is that `npm install` will upgrade every single package you depend on to its latest version that matches your declared dependency, and in JS land almost everyone uses lax dependency declarations. So, an attacker who simply publishes a new p…

`npm install` uses a lockfile by default and will not change versions. No, not transitives either. You would have to either manually change `package.json` or call `npm update`.

You'd have to go out of your way to make your project as bad as you're describing.

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

#297

Post by WorldMaker »

skydhash wrote: post #204
WD-42 wrote: post #169

Earlier quoted context omitted.

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.

Stuff like Babel, React, Svelte, Axios, Redux, Jest… should be self contained and not depend on anything other than being a peer dependency. They are core technological choices that happens early in the project and is hard or impossible to replace afterwards.

- I feel that you are unlikely to need Babel in 2025, most things it historically transpiled are Baseline Widely Available now (and most of the things it polyfilled weren't actually Babel's but brought in from other dependencies like core-js, which you probably don't need either in 2025). For the rest of the things it still transpiles (pretty much just JSX) there are cheaper/faster transpilers with fewer external dependencies and runtime dependencies (Typescript, esbuild). It should not be hard to replace Babel in your stack: if you've got a complex webpack solution (say from CRA reasons) consider esbuild or similar.

- Axios and Jest have "native" options now (fetch and node --test). fetch is especially nice because it is the same API in the browser and in Node (and Deno and Bun).

- Redux is self-contained.

- React itself is sort of self-contained, it's the massive ecosystem that makes React the most appealing that starts to drive dependency bloat. I can't speak to Svelte.

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

#298

Post by notatallshaw »

theodorejb wrote: post #276

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package…

Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts...

What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands?

I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.

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

#299

Post by noodlesUK »

btown wrote: post #252
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 direc…

I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads.

Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

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

#300

Post by simiones »

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.

The solution is not to go back to vanilla JS, it's for people to form a foundation and build a more complete utilities library for JS that doesn't have 1000 different dependencies, and can be trusted. Something like Boost for C++, or Apache Commons for Java.
Post reply on HN