Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

671–680 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#671

Post by eyberg »

nathan_compton wrote: post #426

I never, ever, do development outside of a podman container these days. Basically if I am going to run some code from somewhere and I haven't read it, it goes in a container. I know its not foolproof, but I can't believe how often people run code they haven't read where it can make a huge mess, steal secrets, etc. I'll probably get owned someday, I'm sure, but this feels like a bare minimum.

The same podman that had three new CVE breakouts not even two weeks ago?

Containers do not contain.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#672

Post by eyberg »

Lutger wrote: post #457
netdevphoenix wrote: post #444

Earlier quoted context omitted.

> if I am going to run some code from somewhere and I haven't read it, it goes in a container How does this work? Every single npm package has tons of dependency tree nodes

Everything runs in the container and cannot escape it. Its like a sandbox. You have to make sure you're not putting any secrets in the container environment.

No it is not.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#673

Post by skydhash »

whizzter wrote: post #660
skydhash wrote: post #298

Earlier quoted context omitted.

You can have security without having a walled garden. By trusting the user with the key of their own property.

You mean like the developers holding the npm-publishing keys that just allowed a worm to spread?

No. By NPM not allowing any package to run code on the developer's machine. I can trust npm (the software), but not the library. It's a very weird choice to just allow any package to run post install script. Especially when there's little to none verification done on npmjs side.

Developers can feel free to not secure their computer or sell their keys. But that not means npm should allow straight code push from their computers to everyone that has downloaded their library.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#674

Post by skydhash »

lijok wrote: post #664
sph wrote: post #7

Earlier quoted context omitted.

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

I don’t get this I installed the package, obviously I intend to run it. How does getting pwned once I run it manually differ from getting pwned once I install it? I’m still getting pwned

NPM default installation method does not really lock down you dependencies. It allows for update when the patch number (semver) is increased. Which is why those malware bump it up. Anyone who then run `npm install` will get it and will run the code.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#675

Post by calvinmorrison »

hinkley wrote: post #563
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

Npm is what happens when you let tech debt stack up for years too far. It took them five attempts to get lock files to actually behave the way lock files are supposed to behave (lockfile version 3, + at least 2 unversioned attempts before that). It’s clear from the structure and commit history they’ve been working their asses off to make it better, but when you’re standing at the bottom of a well of suck it takes tha…

but this stuff is basically solved. We have enough history with languages and distribution of packages, repositories, linux, public trust, signing, maintainers, etc.

One key shift is there is no packager anymore. Its just - trust the publisher.

Any language as big as Node should hire a handful of old unix wizards to teach them the way the truth and the life.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#676

Post by skydhash »

ratmice wrote: post #582
sph wrote: post #7

Earlier quoted context omitted.

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

My feeling is that languages with other packing models are merely less convenient, and there is no actual tangible difference security-wise. Just take C and replace "look for writable repositories". It just takes more work and is less uniform to say write a worm that looks for writable cmake/autoconf and replicate that way. What would actually stop this is writing compilers and build systems in a way that isolates bu…

Not really. cmake and automake are for compiling the library, not for the downloading it. The gap between the two is what's get erased from npm. And it made worse because of the auto update set by default when `npm install` is run.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#677

Post by koito17 »

benjifri wrote: post #635
latchkey wrote: post #488

Earlier quoted context omitted.

ProTip: `use bun` Funny that this is getting downvoted, but it installs dependencies super fast, and has the same approval feature as pnmp, all in a simple binary.

This is like saying "use MacOS and you won't get viruses" in the 2000s

Bun disables post-install scripts by default and one can explicitly opt-in to trusting dependencies in the package.json file. One can also delay installing updated dependencies through keys like `minimumReleaseAge`. Bun is a drop-in replacement for the npm CLI and, unlike pnpm, has goals beyond performance and storage efficiency.

Not sure what your analogy is trying to imply.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#678

Post by mbreese »

bilalq wrote: post #278
timgl wrote: post #4

co-founder of PostHog here. We were a victim of this attack. We had a bunch of packages published a couple of hours ago. The main packages/versions affected were: - posthog-node 4.18.1, 5.13.3 and 5.11.3 - posthog-js 1.297.3 - posthog-react-native 4.11.1 - posthog-docusaurus 2.0.6 We've rotated keys and passwords, unpublished all affected packages and have pushed new versions, so make sure you're on the latest versio…

You're probably already planning this, but please setup an alarm to fire off if a new package release is published that is not correlated with a CI/CD run.

Or require manual intervention to publish a new package. I'm not sure why we need to have a fully automated pipeline here to go from CI/CD to public package release. It seems like having some kind of manual user interaction to push a new version of a library would be a good thing.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#679

Post by capyba »

mx7zysuj4xew wrote: post #396
TheFlyingFish wrote: post #70

Earlier quoted context omitted.

I've worried about this for a while with Rust packages. The total size of a "big" Rust project's dependency graph is pretty similar to a lot of JS projects. E.g. Tauri, last I checked, introduces about 600 dependencies just on its own. Like another commenter said, I do think it's partially just because dependency management is so easy in Rust compared to e.g. C or C++, but I also suspect that it has to do with the si…

It won't, it's a culture issue Most rust programmers are mediocre at best and really need the memory safety training wheels that rust provides. Years of nodejs mindrot has somehow made pulling into random dependencies irregular release schedules to become the norm for these people. They'll just shrug it off come up with some "security initiative* and continue the madness

I only personally know one Rust programmer (works in scientific HPC) and he’s fantastic, but in general I do get the sense that most Rust devs migrated from JS and are just now figuring out “omg strong typing and compiled code native to the client hardware is really nice!” and think it’s a ground breaking revelation.

Saying this as someone who is cautiously optimistic about Rust for my own work.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#680

Post by acedTrex »

tetha wrote: post #531
twistedpair wrote: post #469

ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…

> And of course make a very limited scope publisher key, bind it to specific packages (e.g. workflow A can only publish pkg A), and IP bound it to your self hosted CI/CD runners. No one should have publish keys on their local, and even if they got the publish keys, they couldn't publish from local. I've by now grown to like Hashicorp Vaults/OpenBao's dynamic secret management for this. It's a bit complicated to under…

We do that in our github runners with oidc integration. Works well
Post reply on HN