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

611–620 of 797 posts

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

#611

Post by twistedpair »

tripplyons wrote: post #503
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…

Is there a way to set a minimum release age globally for my pnpm installation? I was only able to find a way to set it for each individual project.

I think it's a `pnpm-workspace.yaml` setting, for now, but PNPM has been pretty aggressive with expanding this feature set [1].

[1] https://pnpm.io/supply-chain-security

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

#612

Post by XorNot »

Aeolun wrote: post #542
roozbeh18 wrote: post #484

Earlier quoted context omitted.

You are just reducing the blast radius with use of podman; you will likely need secrets for your app to work, which will be exposed regardless of the podman approach.

Most people don’t have NPM keys in their application containers.

If you're developing in a container then you would have to be doing it without doing something like say, mounting your home directory into it.

The reality here is this is the sort of attack SELinux should be good at stopping (it's not because no one uses SELinux, the policies most commonly used don't confine the user profile in a useful way, and a whole bunch of tools love ambient credentials in environment variables).

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

#613

Post by mikestorrent »

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…

Definitely curious if you've come up with a way to give each build a short lived vault approle somehow in any CI system.

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

#614

Post by mook »

madeofpalk wrote: post #570
halflife wrote: post #552

Earlier quoted context omitted.

What does it do with packages that download binaries for specific architecture in the post script?

You don't need post-install scripts for this. Use optionalDependencies instead https://github.com/nrwl/nx/blob/master/packages/nx/package.j... Each of those deps contains a constraint installing only for the relevant platform.

As far as I can understand from the documentation, that doesn't actually specify in that config that one of them is required, does it? That is, if they _all_ fail to install as far as the system is concerned there's nothing wrong? There will be runtime errors of course, but that's sort of disappointing…

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

#615

Post by SkyPuncher »

Nextgrid wrote: post #599
SkyPuncher wrote: post #408

Earlier quoted context omitted.

This works until you consider regular security vulnerability patching (which we have compliance/contractual obligations for).

This only makes sense for vulnerabilities that can actually be exploited in your particular use-case and configuration of the library. A lot of vulns might be just noise and not exploitable so no need to patch.

Yes and no.

Problem is code bases are continuously evolving. A safe decision now, might not be a safe decision in the future. It's very easy to accidentally introduce a new code path that does make you vulnerable.

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

#616

Post by anpat »

ashishb wrote: post #573

Run npm and yarn inside docker [1]. Infact, do this for all risky tools[2] 1 - https://github.com/ashishb/dotfiles/blob/067de6f90c72f0cf849... 2 - https://ashishb.net/programming/run-tools-inside-docker/

I think it's better to not run npm as root user on container. I would suggest adding --user 1000 to your docker run command.

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

#617

Post by jjice »

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…

There were some recent posts I saw about "dependency cooldowns", which seem to be what you're referring to in item 2. The idea really resonated with me.

That said, I hard pin all our dependencies and get dependabot alerts and then look into updates manually. Not sure if I'm a rube or if that's good practice.

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

#618

Post by Aperocky »

skwee357 wrote: post #122
vintagedave wrote: post #2

Serious question: should someone develop new technologies using Node any more? A short time ago, I started a frontend in Astro for a SaaS startup I'm building with a friend. Astro is beautiful. But it's build on Node. And every time I update the versions of my dependencies I feel terrified I am bringing something into my server I don't know about. I just keep reading more and more stories about dangerous npm packages…

I’m not a node/js apologist, but every time there is a vulnerability in NPM package, this opinion is voiced. But in reality it has nothing to do with node/js. It’s just because it’s the most used ecosystem. So I really don’t understand the argument of not using node. Just be mindful of your dependencies and avoid updating every day.

It has everything to do with node/js. Because the community believes in tiny dependencies that must be updated as often as possible and the tooling reflects that belief.

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

#619

Post by arccy »

chha wrote: post #112
gred wrote: post #74

Earlier quoted context omitted.

NPM has about 4 million packages, Maven Central has about 3 million packages. If this were true, wouldn't there have been at least one Maven attack by now, considering the number of NPM attacks that we've seen?

Been a while since I looked into this, but afaik Maven Central is run by Sonatype, which happens to be one of the major players for systems related to Supply Chain Security. From what I remember (a few years old, things may have changed) they required devs to stage packages to a specific test env, packages were inspected not only for malware but also vulnerabilities before being released to the public. NPM on the oth…

npm is run by github / microsoft now, which also sells security products...

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

#620

Post by divmain »

vedhant wrote: post #604

Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.

pnpm’s minimumReleaseAge can help a ton with this. There’s a tricky balance, because allowing your dependencies to get stale makes you inherently more vulnerable to vulnerabilities in your packages. And, critically, fixing a vulnerability in an urgent situation (i.e. you were compromised) gets increasingly harder to address the more stale your dependencies are.

minimumReleaseAge strikes a good balance between protecting yourself against emerging threats like Shai-Hulud and keeping your dependencies up-to-date.

Because you asked: you can get another layer of protection through Socket Firewall Free (sfw), which prevents dependencies known to be malicious from being installed. Socket typically identifies malware very soon after its is published. Disclaimer: I’m the lead dev on the project, so obviously biased — YMMV.

Post reply on HN