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

461–470 of 797 posts

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

#461

Post by n4r9 »

myaccountonhn wrote: post #443
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.

I ssh into a second local user and do development there instead with tmux.

I send mail to a demon which runs MsBuild and mails the output back to me.

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

#462

Post by smallerfish »

timgl wrote: post #460
smallerfish wrote: post #455

Because PostHog's "Talk to a human" chat instead gets a grumpy gatekeeping robot (which also doesn't know how to get you to a working urgent support link), and there's nothing prominently on their home page or github about this: Hey PostHog! What version do we need to avoid?

co-founder here. We mentioned it in the main thread about this: https://news.ycombinator.com/item?id=46032650 and on status.posthog.com - 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 If you make sure you're on the latest version you should be good.

Thanks. Also - maybe change "talk to a human" to "talk to a grumpy robot" :)

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

#463

Post by moffkalast »

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.

All right then, keep your secrets.

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

#464

Post by burninhell »

I wish everyone here would read https://en.wikipedia.org/wiki/Capability-based_security and then realize that maybe, JUST MAYBE, THE PROGRAMMING LANGUAGES WE USE SHOULD NOT ALLOW IMPORTED PACKAGES TO ACCESS EVERYTHING, AND THEIR LACK OF SECURITY GUARANTEES AND ACCESS RESTRICTION MECHANISMS MAKES THEM DANGEROUS!

The number and range of affected devices may be reduced with any number of package manager level workarounds, but NOT the impact of attacks once any succeeds. For this, you NEED the above.

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

#465

Post by hokkos »

nfriedly wrote: post #381
tragiclos wrote: post #317

Earlier quoted context omitted.

The docs list this caveat: > Note that previous stable versions will not be suggested. The package will be completely ignored if its latest published version is within the cooldown period. Seems like a big drawback to this approach.

I could see it being a good feature. If there have been two versions published within the last week or two, then there are reasonable odds that the previous one had a bug.

some lib literally publish a new package at every PR merged, so multiple times a day.

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

#466

Post by Lutger »

LeifCarrotson wrote: post #454
christophilus wrote: post #436

Earlier quoted context omitted.

What do you mean? You can drop into bash in a container and run any arbitrary command, so `npm install foo` works just fine. Why would posthog's SDK be a special case?

I think the issue is more about what else has to go into or be connected to that container. Posthog isn't really useful if it's air-gapped. You're going to give it keys to access all kinds of juicy databases and analytics, and those NPM tokens, AWS/GCP/Azure credentials, and environment variables are exactly what it exfiltrates. I don't run much on the root OS of my dev machine, basically everything is in a container…

You're severely limiting the blast radius. This malware works by exfiltrating secrets during installation, if I understood it correctly. If you would properly containerize your app and limit permissions to what is absolutely required, you could be compromised and still suffer little to no consequences.

Of course, this is not a real defense on its own, its just good practice to limit blast radius, much like not giving everybody admin rights.

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

#467

Post by echelon »

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.

Another effective strategy I learned of recently that seems like it would have avoided this is to wait months before using new versions of packages.

Most attacks on popular packages last at most a few months before detection.

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

#468

Post by Yokohiii »

joshstrange wrote: post #398
Yokohiii wrote: post #390

Earlier quoted context omitted.

You are right about version locking, bullshit on my side, not sure what I was thinking. I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy.

> I personally don't have a problem with the general ability to change vendor code. The question is whether you want it in an specific case or not. If you update frequently then certainly not. But that decision should be deliberate team policy. Fair, in the instances I ran into it was code that was downloaded and unzipped into a "js-library-name" folder but then the code was edited, even worse, the `.min.js` version…

I'd require vendor code being committed to git and integrated into the CI/CD pipeline. It should be treated as if you own it, just with a policy whether you want to change it or not.

The difficulty to make changes obvious is same for forks and vendored commits, imho. You can write big warnings in commit messages, that's it I guess. Which kind of boils down to deliberate team policy again. But I generally prefer monorepos for various reasons.

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

#469

Post by twistedpair »

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 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. (Granted, GHA fans can use OIDC Trusted Publishers as well, but tokens done well are just as secure)

Post reply on HN