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

241–250 of 329 posts

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

#241

Post by amiga386 »

joshkel wrote: post #234
kommunicate wrote: post #225

Earlier quoted context omitted.

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

I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorpora…

> Python packages traditionally use setup.py

But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.

> PHP Composer packages can ship install scripts

Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "composer -n config allow-plugins.foo/bar true && composer -n require foo/bar"

> The venerable .tar.gz approach to packaging

Which most people don't install directly, but have already had built for them by their distro.

As more and more languages get "package managers", there's an expectation that installing what should just be inert package/library code should not run commands. Sometimes generated files are needed, and the direction seems to be that these package managers should be like distro package managers, where they take the risk of running the build instructions and generate those files for you, serving up os/architecture-specific builds.

This is the direction npm ought to take, and furthermore shouldn't allow things like electron being a small bundle of javascript code that fetches large lumps of binary code from somewhere else on the internet to install. It should all be uploaded to, and sourced from, NPM.

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

#242

Post by esafak »

zahlman wrote: post #193
btown wrote: post #113

At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days. It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets thei…

> and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right? ... Does NPM not create full lockfiles, with hashes and pinned transitive dependencies and everything?

https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-...

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

#243

Post by Rantenki »

kommunicate wrote: post #225
bakugo wrote: post #219

Earlier quoted context omitted.

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

/me looks at the `build.rs` file in my Rust's project's `Cargo.toml` and laughs nervously...

(For non Rustaceans: "Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.")

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

#245

Post by [deleted] »

tomxor wrote: post #230

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 shoul…

[deleted]

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

#247

Post by codedokode »

Havoc wrote: post #49
vsgherzi wrote: post #33

Earlier quoted context omitted.

I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?

Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID

Namespaces look dangerous to me because they break lot of assumptions software was built on before. For example, sudo relies on /etc/sudoers being accessible only to root. But with unprivileged containers one can easily create a filesystem namespace where /etc/sudoers would contain arbitrary data. I think, SUID bit won't work in container, but there might be other ways to confuse privileged software using containers. Or not?

Also, if the container has access to dbus, one can try to exploit multiple services listening on dbus.

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

#248

Post by Sohcahtoa82 »

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?

It's the general ecosystem.

There's not a word in the English language that really expresses how absolutely stupid the npm ecosystem is and the developers that perpetuate it by importing a package rather than writing 5 lines of code.

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

#249

Post by bakkoting »

amiga386 wrote: post #241
joshkel wrote: post #234

Earlier quoted context omitted.

I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorpora…

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages

Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.

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

#250

Post by joshkel »

amiga386 wrote: post #241
joshkel wrote: post #234

Earlier quoted context omitted.

I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorpora…

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages.

Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provide an arbitrary-code `build-backend`, etc., and pip would still function as designed.

I appreciate the clarifications/corrections on PHP.

> Which most people don't install directly, but have already had built for them by their distro.

Yes, but the original claim was that npm is "particularly susceptible to these attacks" because "npm can execute code after install and most package managers don't do that." I don't think that's accurate: we've seen hundreds of NPM packages compromised in multiple high-profile attacks over the last several months, while .tar.gz was used for decades with nowhere near the same number of compromises.

Rather, I suspect it's a combination of factors: Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects. And the extreme popularity of JS, the centralization of NPM + GitHub, and increased usage of automation makes attacks more practical and more lucrative.

Taking a step back from that particular debate, I'm very much in favor of changes like what you describe.

Taking still another step back, I'm not sure that even those will be enough. If I download a package, it's because I intend to run its code at some point: if it's malicious, I may be less automatically hosed than if its postinstall script runs, but I'm still hosed at execution time. I trust my distro packages, not because they don't execute arbitrary code on installation (RPMs and .debs both do), but because I _trust my distro_. NPM et al. simply cannot vouch for every package they host.

Thanks for the reply!

Post reply on HN