Live data from Hacker News

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

socket.dev

81–90 of 1001 posts

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

#81

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

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

#82

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?

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 version) to avoid accruing tech debt. They're all pinned and locally hosted, nuget exists but we (like most .Net developers) don't use it to the extent that npm devs do. We read the changelogs - all four of them! - and manually update.

I understand that the NPM ecosystem works differently from a "batteries included" .Net environment for a desktop app, but it's not just about where the users are. Line of business code in .Net and Java apps process a lot of important data. Slipping a malicious package into pypi could expose all kinds of juicy, proprietary data, but again, it's less about the existence of a package manager and more about when and how you use it.

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

#83
post #38
post #15

I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.

I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.

Just more engineering leaning than you. Actual engineers have to analyze their supply chains, and so makes sense they would be baffled by NPM dependency trees that utterly normal projects grow into in the JavaScript ecosystem.

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

#84

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?

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.

So do you expect other supply chain services that also supply juicy targets to be affected? I mean, we live in a bubble here in HN, so not seeing something in the front page doesn't mean it doesn't exist or it doesn't happen, but the feeling is that NPM is particularly more vulnerable than other services, correct me if I'm wrong.

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

#85
post #10

Is there a theoretical framework that can prevent this from happening? Proof-carrying code?

There are, but they have huge performance or usability penalties. Stuff like intents "this is a math library, it is not allowed to access the network or filesystem". At a higher level, you have app sandboxing, like on phones or Apple/Windows store. Sandboxed desktop apps are quite hated by developers - my app should be allowed to do whatever the fuck it wants.

[deleted]

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

#86

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…

HTMX is full of JavaScript. Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you.

I don't think the point is to avoid Javascript, but to avoid depending on a random number of third-parties.

> Server-side-rendering without JavaScript is just back to the stuff Perl and PHP give you.

As well as Ruby, Python, Go, etc.

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

#87

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…

> Until you go get malware

While technically true, I have yet to see Go projects importing thousands of dependencies. They may certainly exist, but are absolutely not the rule. JS projects, however...

We have to realize, that while supply chain attacks can happen everywhere, the best mitigations are development culture and solid standard library - looking at you, cargo.

I am a JS developer by trade and I think that this ecosystem is doomed. I absolutely avoid even installing node on my private machine.

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

#89

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…

Javascript is badly over-used and over-depended on. So many websites just display text and images, but have extremely heavy javascript libraries because that's what people know and that is part of the default, and because it enables all the tracking that powers the modern web. There's no benefit to the user, and we'd be better off without these sites existing if there were really no other choice but to use javascript.

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

#90

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

From what I've seen, it's either spam, telemetry, or downloading prebuilt binaries. The first two are anti-user and should not exist, the last one isn't really necessary — swc, esbuild, and typescript-go simply split native versions into separate packages, and install just what your system needs.

Use pnpm and whitelist just what you need. It disables all scripts by default.

Post reply on HN