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

271–280 of 1001 posts

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

#271

Post by azemetre »

dmix wrote: post #230
benmccann wrote: post #156

Earlier quoted context omitted.

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 :/

Have you looked into biome? We recently switched at work. It’s fine and fast. If you overly rely on 3rd party plugins it might be hard but it covered our use case fine for a network based react app.

Way less dependencies too.

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

#272

Post by rs999gti »

reactordev wrote: post #70
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…

Until you go get malware Supply chain attacks happen at every layer where there is package management or a vector onto the machine or into the code. What NPM should do if they really give a shit is start requiring 2FA to publish. Require a scan prior to publish. Sign the package with hard keys and signature. Verify all packages installed match signatures. Semver matching isn’t enough. CRC checks aren’t enough. This h…

> What NPM should do if they really give a shit is start requiring 2FA to publish.

How does 2FA prevent malware? Anyone can get a phone number to receive a text or add an authenticator to their phone.

I would argue a subscrption model for 1 EUR/month would be better. The money received could pay for certification of packages and the credit card on file can leverage the security of the payments system.

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

#274

Post by foobarbecue »

progbits wrote: post #220
m4r71n wrote: post #203

Earlier quoted context omitted.

Since so many vendors discovered these packages seemingly independently, you'd think that they would share those mechanisms with NPM itself so that those packages would never be published in the first place. But I guess that removes their ability to sell an "early alert" mechanism through their offerings...

NPM is owned by github/microsoft. I'm sure they could afford to buy one of these products or just build their own, but clearly security is not a thing they care about.

Can't help noticing, in the original article:

> The entire attack design assumes Linux or macOS execution environments, checking for os.platform() === 'linux' || 'darwin'. It deliberately skips Windows systems

If I were the conspiracy-minded sort I might jump to some wild conclusions here.

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

#275

Post by int_19h »

galaxyLogic wrote: post #241
kortilla wrote: post #188

Earlier quoted context omitted.

None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does. The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.

So maybe the solution would be to sandbox Node.js? I'm not quite sure what that would mean, but if it solves the problem for browsers, why not for server?

Deno does exactly that.

But in practice, to do useful things server-side you generally need quite a few permissions.

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

#276

Post by theodorejb »

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 is actually imported in a browser or other production environment.

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

#277

Post by xrisk »

williamcotton wrote: post #152
neilv wrote: post #141

Earlier quoted context omitted.

In less time than that, you could `git clone` the desired open source package, and text search & replace the author's name with your own.

And then still be subject to supply-chain attacks with all of the dependencies in whatever open source package you're cloning?

you are aware that the app you just wrote with Claude pulls in dependencies, yes?

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

#278

Post by simiones »

lucideer wrote: post #81
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…

> 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 patch version of a package they have gained access to will likely poison a good chunk of all of the users of that package in a relatively short amount of time. Even if the projects using this are careful and use `npm ci` instead of `npm install` for their CI builds, it will still easily get developers to download and run the malicious new version.

Most other ecosystems don't have this unsafe-by-default behavior, so deploying a new malicious version of a previously safe package is not such a major risk as it is in NPM.

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

#279

Post by int_19h »

skydhash wrote: post #211
WD-42 wrote: post #194

Earlier quoted context omitted.

Maybe the language should have a standard library then.

C library is smaller than Node.js (you won’t have HTTP). What C have is much more respectable libraries. If you add libcurl or freetype to your project, it won’t pull the whole jungle with them.

What C doesn't have is an agreed-upon standard package manager. Which means that any dependency - including transitive ones! - requires some effort on behalf of the developer to add to the build. And that, in turn, puts pressure on library authors to avoid dependencies other than a few well-established libraries (like libpng or GLib),

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

#280

Post by cesarb »

juliend2 wrote: post #195
cookiengineer wrote: post #112

Earlier quoted context omitted.

Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends. Additionally I really like to go mod vendor my snapshot…

> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I've also seen something similar with Java, with its culture of "pure Java" code which reimplements everything in Java instead of calling into preexisting native libraries. What's common between Java and Go is that they don't play well with native code; they really want to have full control of the process, which is made harder by code running outside their runtime environment.

Post reply on HN