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

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

221–230 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#221

Post by OhMeadhbh »

shoeb00m wrote: post #206
freedomben wrote: post #146

Earlier quoted context omitted.

I agree generally, but I also think it's important to point out that in the NPM ecosystem it is culturally acceptable and even encouraged to install even trivial dependencies to avoid reinventing the wheel. Philosophically I completely agree with this, though practically we see the result and it is not good. The left pad debacle should have been a huge wake up call, but not really much seems to have changed after tha…

Most of these attacks have nothing to do with installing trivial dependencies. It’s usually because the authors npm tokens got hacked; often due to github actions. The issue is that github actions has too many security gaps that are easy to miss.

No. It is partially due to trivial dependencies. With so many dependencies it is very difficult to evaluate the security posture of all the teams that are inserting themselves into your code.

When I publish commercial software for Unices that use shared object libraries, one of the things we do before publishing is review known vulnerabilities of our 10 dependencies. That is a tractable number. I get a senior engineer to spend time with an intern and step them through the evaluation criteria.

If the team managing a particular library grows lax over time with respect to responding to vulnerabilities, we move away from using that library.

And we can do these things because there are a tractable number of dependencies.

But yes, also GitHub is not pure as the driven slush. I agree with you on that.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#222

Post by gherkinnn »

WorldMaker wrote: post #178
gherkinnn wrote: post #109

> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages. I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library. 0 - https://docs.deno.com/runti…

To be fair, Node has `node:test` [0] and `node:assert/strict` [1] modules out of the box for several LTS versions now. `node --test` can easily replace Mocha and `node:assert/strict` is fine, but `chai` is still sometimes nicer (include ergonomics like `expect`). (Deno's @std includes an `expect` style assertion library.) Of course, the trouble is that there are so many test runners in the Node ecosystem and many of…

Much came after Deno added them. I don't know what will happen to Deno, but I am glad they showed the Node world than life can be a little more pleasant

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#223

Post by freakynit »

bakugo wrote: post #219
nepthar wrote: post #218

“No way to prevent this” says only package manager where this regularly happens.

Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?

Yep.

1. Every day there's a new package.

2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself.

3. Then someone writes a wrapper around those five packages.

4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper.

5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy.

6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally.

7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues.

8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization.

9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment."

10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real.

So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#224

Post by OhMeadhbh »

gabdpipi wrote: post #149
ch4s3 wrote: post #131

Earlier quoted context omitted.

NPM by virtue of its popularity and the vagaries of the ecosystem is always going to be a prime target for attackers, and people (maintainers) will always be a weak point.

Yeah I was thinking the difference between open source and enterprise to mitigate this is a simple hardware security module right? If the attackers spearfish folks who hold “keys to the castle” and everything is digital it’s game over no matter what ecosystem. Those things should be locked down by “something you have” because that’s much more difficult.

What will cryptography buy you in this instance? Do digital signatures imply virtuous behaviour? Does the lack of a signature imply vice?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#225

Post by kommunicate »

bakugo wrote: post #219
nepthar wrote: post #218

“No way to prevent this” says only package manager where this regularly happens.

Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?

npm can execute code after install and most package managers don't do that

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#226

Post by epicide »

cyanydeez wrote: post #44
rubnogueira wrote: post #40

aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

dino was wired with security in mind, but you can see developers dont tend towards aecurity

Because employers don't tend towards security. In fact, many actively punish somebody for "sandbagging" or simply taking too long if they even suggest a security concern.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#227

Post by toast0 »

nonethewiser wrote: post #169
tialaramex wrote: post #156

Earlier quoted context omitted.

The "No way to prevent this" analogies seem to me to work better for Memory Safety because, as with Gun Safety, the simple fact is that everybody knows how to solve the problem, but one group insists it's impossible. There is crowing from the "Actually copy-paste is better" people when this happens, but when it's their turn they just jam their fingers in their ears. The memory safety and gun safety problems are the a…

>The "No way to prevent this" analogies seem to me to work better for Memory Safety because, as with Gun Safety, the simple fact is that everybody knows how to solve the problem, but one group insists it's impossible. I'm not following. Whats the 2nd Amendment equivalent for memory safety? The amount of C/C++ in production or something?

> A well regulated Memory Operation, being necessary to the security of a free Computer, the right of the people to keep and bear Pointer Arithmetic, shall not be infringed.

(maybe workshop this)

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#228

Post by smsm42 »

This had been going on for years. I'd expect there would be some kind of solution for now? Like banning scripts and only allowing them to be executed at the explicit user request, for example (not a guarantee but at least a barrier) or somehow restricting them from accessing stuff that does not belong to packaging system. I mean, we have millions of people in the ecosystem, and we keep having this problem for years. Maybe we should ask Claude Code how to fix it (sad laugh)?

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#230

Post by tomxor »

At this point lifecycle script should be disabled by default in NPM.

It's a convenience feature that provides built-in Arbitrary Code Execution (even for transient dependencies), and every one of these widespread NPM worm style attacks has propagated through it, because of the default setting. Also enabling it for one command shouldn't automatically permit all transient dependencies to run lifecycle scripts, it should be required to explicitly mark each dependency to limit it to where it's absolutely necessary.

The vast majority of NPM packages do not depend on these scripts, and you should disable them globally if you haven't already.

Post reply on HN