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

321–330 of 1001 posts

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

#321

Post by silverwind »

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…

So, who is going to audit the thousands of new packages/versions that are published to npm every day? It only works for Debian because they hand-pick popular software.

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

#322

Post by cxr »

orbital-decay wrote: post #244
cxr wrote: post #118

Earlier quoted context omitted.

It's not possible for a language to have an insane dependency tree. That's an attribute of a codebase.

Modern programming languages don't exist in a vacuum, they are tied to the existing codebase and libraries.

Whatever you're trying to say, you aren't.

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

#323

Post by f33d5173 »

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…

You can use debian's version of your npm packages if you'd like. The issues you're likely to run into are: some libraries won't be packaged period by debian; those that are might be on unacceptably old versions. You can work around these issues by vendoring dependencies that aren't in your distro's repo, ie copying a particular version into your own source control, manually keeping up with security updates. This is, to my knowledge, what large tech companies do. Other companies that don't are either taking a known risk with regards to vulnerabilities, or are ignorant. Ignorance is very common in this industry.

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

#324

Post by Yeroc »

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

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

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

Please elaborate on this. I'm a long-time Java developer and have never once seen something akin to what you're describing here. Maven has support for version ranges but in practice it's very rarely used. I can expect a project to build with the exact same dependencies resolved today and in six months or a year from now.

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

#325

Post by simiones »

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.

No, this is just wrong. It might indeed use package-lock.json if it matches your node_modules (so that running `npm install` multiple times won't download new versions). But if you're cloning a repo off of GitHub and running npm install for the first time (which a CI setup might do), it will take the latest deps from package.json and update the package-lock.json - at least this is what I've found many responses online claim. The docs for `npm ci` also suggest that it behaves differently from `npm install` in this exact respect:

> In short, the main differences between using npm install and npm ci are:

> The project must have an existing package-lock.json or npm-shrinkwrap.json.

> If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.

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

#326

Post by debazel »

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.

Even if we didn't have post install scripts wouldn't the malware just run as soon as you imported the module into your code during the build process, server startup, testing, etc?

I can't think of an instance where I ran npm install and didn't run some process shortly after that imported the packages.

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

#328

Post by Rockslide »

simiones wrote: post #325
Tadpole9181 wrote: post #296

Earlier quoted context omitted.

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

No, this is just wrong. It might indeed use package-lock.json if it matches your node_modules (so that running `npm install` multiple times won't download new versions). But if you're cloning a repo off of GitHub and running npm install for the first time (which a CI setup might do), it will take the latest deps from package.json and update the package-lock.json - at least this is what I've found many responses onlin…

Well but the docs you cited don't match what you stated. You can delete node_modules and reinstall, it will never update the package-lock.json, you will always end up with the exact same versions as before. The package-lock updating happens when you change version numbers in the package.json file, but that is very much expected! So no, running npm install will not pull in new versions randomly.

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

#329

Post by lupusreal »

WD-42 wrote: post #190
jeswin wrote: post #167

Earlier quoted context omitted.

Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, pro…

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1] https://www.npmjs.com/package/uuid

> You can't expect people to re-write everything over and over.

Call me crazy but I think agentic coding tools may soon make it practical for people to not be bogged down by the tedium of implementing the same basic crap over and over again, without having to resort to third party dependencies.

I have a little pavucontrol replacement I'm walking Claude Code through. It wanted to use pulsectl but, to see what it could do, I told it no. Write your own bindings to libpulse instead. A few minutes later it had that working. It can definitely write crap like leftpad.

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

#330

Post by dmix »

azemetre wrote: post #271
dmix wrote: post #230

Earlier quoted context omitted.

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.

Even minor styling rule changes would result in a huge PR across our frontend so I tend to avoid any change in tooling. But using old tools is not the end of the world. I only upgrade ESLint because I had to upgrade something else.
Post reply on HN