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

311–320 of 1001 posts

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

#311

Post by lenerdenator »

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.

It'd be interesting to see how much of the world runs on Debian containers, where most of the whole "it doesn't support my insert consumer hardware here" argument is completely moot.

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

#312

Post by jlarocco »

chamomeal wrote: post #269
skydhash wrote: post #200

Earlier quoted context omitted.

You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture. > You can't expect people to re-write everything over and over. That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.

When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”. I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture

It's not really bad advice, it just has different implications in Javascript.

In other languages, you'd have a few dependencies on larger libraries providing related functionality, where the Javascript culture is to use a bunch of tiny libraries to give the same functionality.

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

#314

Post by godshatter »

moi2388 wrote: post #227
znort_ wrote: post #166

Earlier quoted context omitted.

npm in itself isn't special at all, maybe the userbase is but that's irrelevant because the mitigation is pretty easy and 99.9999% effective, works for every package manager and boils down to: 1- thoroughly and fully analyze any dependency tree you plan to include 2- immediately freeze all its versions 3- never update without very good reason or without repeating 1 and 2 in other words: simply be professional, face l…

Good luck with nr 1 in the js ecosystem and its 30k dependencies 50 branches deep per package

As an outsider looking in as I don't deal with NPM on a daily basis, the 30k dependencies going 50 branches deep seems to be the real problem here. Code reuse is an admiral goal but this seems absurd. I have no idea if these numbers are correct or exaggerations but from my limited time working with NPM a year or two ago it seems like it's a definite problem.

I'm in the C ecosystem mostly. Is one NPM package the equivalent of one object file? Can NPM packages call internal functions for their dependencies instead of relying so heavily on bringing in so many external ones? I guess it's a problem either way, internal dependencies having bugs vs supply chain attacks like these. Doesn't bringing in so many dependencies lead to a lot of dead code and much larger codebases then necessary?

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

#315

Post by lenerdenator »

jeswin wrote: post #167
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…

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…

> Traditional JS is actually among the safest environments ever created.

> However, processes and practices around NodeJS and npm are in dire need of a security overhaul. leftpad is a cultural problem that needs to be addressed. To start with, snippets don't need to be on npm.

Traditional JS is the reason we have all of these problems around NodeJS and npm. It's a lot better than it was, but a lot of JS tooling came up in the time when ES5 and older were the standard, and to call those versions of the language lacking is... charitable. There were tons of things that you simply couldn't count on the language or its standard library to do right, so a culture of hacks and bandaids grew up around it. Browser disparities didn't help either.

Then people said, "Well, why don't we all share these hacks and bandaids so that we don't have to constantly reinvent the wheel?", and that's sort of how npm got its start. And of course, it was the freewheeling days of the late 00s/early 10s, when you were supposed to "move fast and break things" as a developer, so you didn't have time to really check if any of this was secure or made any sense. The business side wanted the feature and they wanted it now.

The ultimate solution would be to stop slapping bandaids and hacks on the JS ecosystem by making a better language but no one's got the resolve to do that.

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

#316

Post by WorldMaker »

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

Deno has a similar formatter to prettier and similar linter to eslint (with Typescript plugins) out-of-the-box. (Some parts of those written in Rust.) I have been finding myself moving to Deno more and more. I also haven't noticed too many reformatting problems with migrating from prettier to Deno. (If there are major changes, you can also add the commit to a .git-ignore-revisions file.)

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

#317

Post by simiones »

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…

The point is still different. In PyPI, if I put `requests` in my requirements.txt, and I run `pip install -r requirements.txt` every time I do `make build`, I will still only get one version of requests - the latest available the first time I installed it. This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day. And the ecosystem being committed to respecting semver is entirely irrelevant to supply chain security. Malicious actors don't care about semver.

Overall, publishing a new malicious version of a package is a much lesser problem in virtually any ecosystem other than NPM; in NPM, it's almost an automatic remote code execution vulnerability for every NPM dev, and a persistent threat for many NPM packages even without this.

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

#318

Post by a99c43f2d565504 »

homebrewer wrote: post #66

When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project i…

> Does anyone know of other major projects written in as strict a style as esbuild?

As in any random major project with focus on not having dependencies? SQLite comes to mind.

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

#319

Post by lenerdenator »

jlarocco wrote: post #312
chamomeal wrote: post #269

Earlier quoted context omitted.

When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”. I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture

It's not really bad advice, it just has different implications in Javascript. In other languages, you'd have a few dependencies on larger libraries providing related functionality, where the Javascript culture is to use a bunch of tiny libraries to give the same functionality.

Sometimes I wonder how many of these tiny libraries are just the result of an attempt to have something ready for a conference talk and no one had the courage to say "Uh, Chris, that already exists, and the world doesn't need your different approach on it."

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

#320

Post by thewebguyd »

noodlesUK wrote: post #299
btown wrote: post #252

Earlier quoted context omitted.

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.

Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.
Post reply on HN