5 ms·
At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion. It's time pre-inst
by xnorswap 2mo ago
At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion.
It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.
- mechazawa 2mo agoiirc does pnpm not allow them by default. But even if we killed them off there would still be a chance of the malware hooking into something else or only working in cli applications.
- jonchurch_ 2mo agonpm v12 released last month also defaults into blocking them by default
- madeofpalk 2mo agoThe latest version of all node package managers (npm, yarn, pnpm) now deny this by default. pnpm was ahead of the curve.
- jitl 2mo agoyeah but they can just put the dropper, etc in index.js, so that it runs at import time rather than at install time, no? i guess first-install time is often a privileged developer machine, and will execute in a "server"-like runtime such as Node, Bun, Deno. but blocking preinstall scripts is basic first aid...
- jerf 2mo agoNobody is claiming this is a complete solution to security. I would call this "necessary but not sufficient". You won't get far as an engineer if you refuse to implement "necessary but not sufficient" changes because the change doesn't in and of itself one-shot the entire problem.
- rcxdude 2mo agoThe fact that it's not sufficient also largely means it's not necessary either, because the real solution is auditing and trusting the codebase as a whole. All you do when disabling install hooks is make a lot of situations much more difficult to handle.
- jitl 2mo ago"make no mistakes" is not the "real solution"
- rcxdude 2mo agoNeither is 'close the gate with no fence on either side of it'. If you want to run code, you either need to run it in a sandbox or trust it. Choosing to run only part of the code is not really a solution. (if you want to disable such hooks yourself, then you may get some security by diversity because you're not using the common configuration. But if it becomes the default then these worms will switch to a different vector)
- jerf 2mo agoYou will also not get very far in engineering if you have a production incident, someone proposes a thing that will mitigate it partially but significantly, and you insist that we can't deploy that mitigation because we need to do the multi-year project that will actually fix it instead. Even if we still need that project, we also need that mitigation. Sure, solve the problem of "auditing and trusting codebases". Go for it. Shouldn't take you until, oh, let me be generous and give you until next Monday. No sweat.
- rcxdude 2mo agoFeel free to turn it off yourself, just don't be surprised when the attackers switch tactics. And don't make life harder for everyone else by pushing it as mandatory. (if you want a better mitigation: don't automatically update dependencies in CI. At a minimum have a cooling-off period that you only bypass on manual review. This is not hard to implement and at least gives some time for alarm bells to be sounded before you're pwned. Probably while doing the updates you can also just do a quick sanity check on the changes, that'll also catch the ones using a blatant install hook)
- sysguest 2mo agowell Deno has the necessary ingredients for defense: file-system permission by path
- insanitybit 2mo agoProd tends to have less privileges than CI/CD. CI/CD tends to be full admin, so it's far more sensitive. Prod tends to have tooling for detecting breaches, better logging, etc. People tend to use containers, which act as a sandbox. Prod also won't be wormable the way that CI/CD is. With CI/CD I can own another dev, use their creds to push another malicious build script, etc. "Attacker is in my prod env" isn't wormable. Yes, capabilities in prod would be hugely beneficial but removing CI/CD is massive as a win.
- JustSkyfall 2mo agoWouldn't the dropper get executed once tests are run within CI though?
- jitl 2mo agoyeah, or when a dev starts the local development server (unless that server is containerized).
- insanitybit 2mo agoDev laptops tend to have better monitoring than CI/CD so I still think this is a better option. You can also have devs use VMs or separate dev environments like an ec2 instance. To be clear, just solving the CI/CD portion is insufficient, but it is a massive win.
- insanitybit 2mo agoYes, you should separate "tests execute" into their own unprivileged workflows that don't have "deploy" secrets.
- rcxdude 2mo agoYou can also do the same for the build workflow, no?
- 2mo ago
- insanitybit 2mo agoYou'll just end up with people running `./configure` scripts or whatever instead. The solution I've currently landed on is: 1. Audit build scripts/ proc macros for rust code (and mark with cargo-vet). 2. Have an isolated workflow for "build/test/push artifact to temporary place" (s3, github artifact, whatever). No API keys in this workflow. 3. Have another workflow that has the API keys to publish that grabs the artifact and then places it into a registry. This creates clear separation of "code runs here" and "environment has privileges". In my own slop-driven programming language I have build scripts declare their capabilities upfront so that you can statically reason about them (same with runtime permissions).