25 ms·

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will onl

by 827a 5mo ago

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

Rohansi 5mo ago
This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.
- tkel 5mo ago
  If you look at the last N npm worms, they all used postinstall scripts.
  - cluckindan 5mo ago
    Is that even true?
    - tkel 5mo ago
      shai-hulud and variants https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-s...
      - cluckindan 5mo ago
        So N=1? 2? 3?
        tkel 5mo ago
        at least 3 that i can remember off the top my head in these last couple months. If you look further back you will find more.
- 827a 5mo ago
  There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways. Its childish to believe that because you can't fix everything you shouldn't fix anything. Defense in depth.
  - Rohansi 5mo ago
    > There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package) You don't need to test a compromised package to have it execute code. Importing it anywhere in your tests is enough, even transitively. It's for sure less likely to run but I doubt it's significantly different in practice.
raggi 5mo ago
install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.
- throwaway27448 5mo ago
  Surely every layer of defense in depth is a distraction except the one that prevents the problem.
  - dns_snek 5mo ago
    It's not defense in depth if the mechanism is trivially bypassed.
    - throwaway27448 5mo ago
      Trivial relative to which perspective? The distinction matters enough to care. Just because your father might give away their phone pin over the phone doesn't mean we should allow this granting remote access to his phone.
      - dns_snek 5mo ago
        Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately. Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removing these scripts wouldn't materially change the situation we're in. You're locking the back door but leaving the front door and all of the windows wide open. I'm going to suggest that we might be worse off in the short-medium term if post-install scripts are removed because everyone who thought that disabling post-install scripts was a "good enough" standalone security strategy will get caught with their pants down as attackers modify their payloads.
nine_k 5mo ago
...and only if you invoke it with --dangerously-run-postinstall-scripts; otherwise it will report an error if a postinstall script is found. This is definitely going to affect any packages that need to link to native code and/or compile shims, but these are very few.
guidedlight 5mo ago
Security issues aside, they are a nightmare in enterprise environments where internet and OS access is heavily restricted.
amluto 5mo ago
There is also not too much legitimacy to the fact that Rust packages can run unsandboxed when they build themselves.
- adamnemecek 5mo ago
  I feel like it's harder to hide malicious stuff in Rust build scripts.
  - chadgpt3 5mo ago
    Why?
akoboldfrying 5mo ago
With respect, post-install scripts are a total red herring. You're alarmed by them because they are code controlled by someone else that runs on your box, and they could do something bad -- yes, they are, and yes they could. But so is the regular code in those packages! It won't run at install time, but something in there will run -- otherwise it wouldn't have been included in the dependencies. Thinking that eliminating post-install scripts will have more than a momentary impact on exploitation rates is a sign of not thinking the issue through. Unfortunately the issue is much more nuanced than TFA implies -- it's not at all a case of "Let's just stop putting the wings-fall-off button next to the light switch", it's that the thing we want to prevent (other people's bad code running on our box) cannot be distinguished from the thing we want (other people's good code running on our box) without a whole lot of painstaking manual effort, and avoiding painstaking manual effort is the only reason we even consider running other people's code in the first place.
- apf6 5mo ago
  The time difference does matter though. There were some recent worm attacks in NPM that spread very quickly because they used post-install. I don’t remember how long it took NPM to block the packages but it was probably around 30 minutes or so? If it wasn’t for post-install then that same attack would have a much slower spread and thus a smaller blast radius.
  - dns_snek 5mo ago
    I don't accept the idea that it would significantly slow down the spread. How often do you run "npm install" just for the fun of it, without actively working on the codebase? IME 99% of the time the time between "npm install" and some form of execution that pulls in dependencies is less than 30 seconds.
- 827a 5mo ago
  > There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways.
tkel 5mo ago
I audited several postinstall scripts recently in popular packages. They seem to be mostly around using native binaries, downloading them, detecting if the platform is compatible, linking to it directly instead of having it bootstrapped by node, working around issues in older versions of npm, etc. Since dev toolchains (e.g. esbuild) are now being built in compiled languages and distributed as binaries via npm registry. If you are on a recent version of node/npm and a common/recent OS/platform, you should be able to disable all the postinstall scripts without legitimate issue.
- tkel 5mo ago
  [dead]

by 827a 5mo ago

Rohansi 5mo ago

This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.

tkel 5mo ago
If you look at the last N npm worms, they all used postinstall scripts.
- cluckindan 5mo ago
  Is that even true?
  - tkel 5mo ago
    shai-hulud and variants https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-s...
    - cluckindan 5mo ago
      So N=1? 2? 3?
      - tkel 5mo ago
        at least 3 that i can remember off the top my head in these last couple months. If you look further back you will find more.
827a 5mo ago
There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways. Its childish to believe that because you can't fix everything you shouldn't fix anything. Defense in depth.
- Rohansi 5mo ago
  > There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package) You don't need to test a compromised package to have it execute code. Importing it anywhere in your tests is enough, even transitively. It's for sure less likely to run but I doubt it's significantly different in practice.

raggi 5mo ago

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

throwaway27448 5mo ago
Surely every layer of defense in depth is a distraction except the one that prevents the problem.
- dns_snek 5mo ago
  It's not defense in depth if the mechanism is trivially bypassed.
  - throwaway27448 5mo ago
    Trivial relative to which perspective? The distinction matters enough to care. Just because your father might give away their phone pin over the phone doesn't mean we should allow this granting remote access to his phone.
    - dns_snek 5mo ago
      Trivial in the sense that in 99.9% of situations, "npm install" is immediately followed by "npm run", "npm test", or some form of execution. Any execution that imports a dependency is enough for a transitive dependency to execute its malicious payload immediately. Post-install scripts have a slight edge over executing malicious code on import, i.e. they work 99.95% of the time instead of 99.9% of the time, but removing these scripts wouldn't materially change the situation we're in. You're locking the back door but leaving the front door and all of the windows wide open. I'm going to suggest that we might be worse off in the short-medium term if post-install scripts are removed because everyone who thought that disabling post-install scripts was a "good enough" standalone security strategy will get caught with their pants down as attackers modify their payloads.

nine_k 5mo ago

...and only if you invoke it with --dangerously-run-postinstall-scripts; otherwise it will report an error if a postinstall script is found. This is definitely going to affect any packages that need to link to native code and/or compile shims, but these are very few.

guidedlight 5mo ago

Security issues aside, they are a nightmare in enterprise environments where internet and OS access is heavily restricted.

amluto 5mo ago

There is also not too much legitimacy to the fact that Rust packages can run unsandboxed when they build themselves.

adamnemecek 5mo ago
I feel like it's harder to hide malicious stuff in Rust build scripts.
- chadgpt3 5mo ago
  Why?

akoboldfrying 5mo ago

With respect, post-install scripts are a total red herring. You're alarmed by them because they are code controlled by someone else that runs on your box, and they could do something bad -- yes, they are, and yes they could. But so is the regular code in those packages! It won't run at install time, but something in there will run -- otherwise it wouldn't have been included in the dependencies. Thinking that eliminating post-install scripts will have more than a momentary impact on exploitation rates is a sign of not thinking the issue through. Unfortunately the issue is much more nuanced than TFA implies -- it's not at all a case of "Let's just stop putting the wings-fall-off button next to the light switch", it's that the thing we want to prevent (other people's bad code running on our box) cannot be distinguished from the thing we want (other people's good code running on our box) without a whole lot of painstaking manual effort, and avoiding painstaking manual effort is the only reason we even consider running other people's code in the first place.

apf6 5mo ago
The time difference does matter though. There were some recent worm attacks in NPM that spread very quickly because they used post-install. I don’t remember how long it took NPM to block the packages but it was probably around 30 minutes or so? If it wasn’t for post-install then that same attack would have a much slower spread and thus a smaller blast radius.
- dns_snek 5mo ago
  I don't accept the idea that it would significantly slow down the spread. How often do you run "npm install" just for the fun of it, without actively working on the codebase? IME 99% of the time the time between "npm install" and some form of execution that pulls in dependencies is less than 30 seconds.
827a 5mo ago
> There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways.

tkel 5mo ago

I audited several postinstall scripts recently in popular packages. They seem to be mostly around using native binaries, downloading them, detecting if the platform is compatible, linking to it directly instead of having it bootstrapped by node, working around issues in older versions of npm, etc. Since dev toolchains (e.g. esbuild) are now being built in compiled languages and distributed as binaries via npm registry. If you are on a recent version of node/npm and a common/recent OS/platform, you should be able to disable all the postinstall scripts without legitimate issue.

tkel 5mo ago
[dead]