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

301–310 of 1001 posts

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

#301

Post by lucideer »

Tadpole9181 wrote: post #296
simiones wrote: post #278

Earlier quoted context omitted.

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.

A lot of people use tools like Dependabot which automates updates to the lockfile.

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

#302

Post by Icathian »

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…

Go sits at about the same level of abstraction as Python or Java, just with less OO baked in. I'm not sure where go's reputation as "low-level" comes from. I'd be curious to hear why that's the category you think of it in?

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

#303

Post by rlpb »

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…

There is another related growing problem in my recent observation. As a Debian Developer, when I try to audit upstream changes before pulling them in to Debian, I find a huge amount of noise from tooling, mostly pointless. This makes it very difficult to validate the actual changes being made.

For example, an upstream bumps a version of a lint tool and/or changes style across the board. Often these are labelled "chore". While I agree it's nice to have consistent style, in some projects it seems to be the majority of the changes between releases. Due to the difficulty in auditing this, I consider this part of the software supply chain problem and something to be discouraged. Unless there's actually reason to change code (eg. some genuine refactoring a human thinks is actually needed, a bug fix or new feature, a tool exposed a real bug, or at least some identifiable issue that might turn into a bug), it should be left alone.

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

#304

Post by treyd »

spoiler wrote: post #288
johnisgood wrote: post #208

Earlier quoted context omitted.

Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.

Not saying this in defence of Rust or Cargo, but often times those dependencies are just different versions of the same thing. In a project at one of my previous companies, a colleague noticed we had LOADS of `regex` crate versions. Forgot the number but it was well over 100

That seems like a failure in workspace management. The most duplicates I've seen was 3, with crates like url or uuid, even in projects with 1000+ distinct deps.

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

#305

Post by freakynit »

pingou wrote: post #150

As a developer, is there a way on mac to limit npm file access to the specific project? So that if you install a compromised package it cannot access any data outside of your project directory?

Wrote a small utility shell script that uses docker behind the scenes to prevent access to your host machine while still allowing full npm install and run workflow.

https://github.com/freakynit/simple-npm-sandbox

Disclaimer: I am not Docker expert. Please review the script (sandbox.js) and raise any potential issues or suggestions.

Thanks..

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

#306

Post by rectang »

paulirish wrote: post #257

This vulnerability was reported to NPM in 2016: https://blog.npmjs.org/post/141702881055/package-install-scr... https://www.kb.cert.org/vuls/id/319816 but the NPM response was WAI.

Acronym expansion for those-not-in-the-know (such as me before a web search): WAI might mean "working as intented", or possibly "why?"

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

#307

Post by bpt3 »

SkiFire13 wrote: post #219
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…

> 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. Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.

What hardware isn't supported by Debian stable that is supported by unstable?

Or is this just a "don't use Linux" gripe?

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

#308

Post by zarzavat »

hannob wrote: post #30
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?

It's actually relatively simple. Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies. In the world of NPM, people think those simple truths don't app…

You can't put this all on the users. The JS/node/npm projects have been mismanaged since the start.

node should have shipped "batteries included" after the left-pad incident. There was a boneheaded attachment to small stdlib, which you could put down to youthful innocence, except that it's been almost 10 years.

The TC39 committee which controls the design of JS stdlib and the node maintainers basically both act like the other one doesn't exist.

NPM was never designed with security in mind. It's a dirty hack that somehow became the most popular package manager.

The dependency hell is a reflection of the massive egos of the people involved in the multiple organizations. Python doesn't have this problem because it's all centralized under one org with a single vision.

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

#309

Post by [deleted] »

spoiler wrote: post #288
johnisgood wrote: post #208

Earlier quoted context omitted.

Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.

Not saying this in defence of Rust or Cargo, but often times those dependencies are just different versions of the same thing. In a project at one of my previous companies, a colleague noticed we had LOADS of `regex` crate versions. Forgot the number but it was well over 100

[deleted]

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

#310

Post by theodorejb »

notatallshaw wrote: post #298
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"…

In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.
Post reply on HN