It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies.
This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package is actually imported in a browser or other production environment.
I'm also wondering why huge scale attacks like this don't happen for other package managers.
Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed.
Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc...
Like, there is the post install script issue or course, but I feel like these attacks could have been just as (or almost as) effective in other programming languages, but I feel like we always only hear about npm packages.
All package managers are vulnerable to this type of attack, it just happens that npm is like 10+ times more popular than the others, so it gets targeted often.
It's a lot harder to do useful things with backend languages. JavaScript is more profitable as you can do the crypto wallet attacks without having to exploit kernel zero days.
Yes but outside of dumping user data, there's not much else you can do. Crypto mining will get caught rather quickly (most big clouds ban mining). User data is useful for the type of attacker that's willing to go through the whole blackmarketing selling process. For script kiddies, if you think about it, the easiest pay-off for a social engineering/phishing is a frontend wallet crypto theft.
This has still nothing to do with the language or kernel exploits. Only code execution on a valuable host matters.
You could make a malicious Rust crate that on installation runs a Python shell and injects JavaScript into your browser to extract crypto wallets. There even seems to be a significant overlap of Rust devs/crypto fans.
Also script kiddies don't do social engineering and blackmarket crypto selling, that's 100% professional crime territory. Real-life script kiddie attacks I've seen were more like hacking an ecommerce site and adding bananas as currency.
What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands?
I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.
In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.
This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package is actually imported in a browser or other production environment.