8 ms·
yeah 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 p
by jitl 2mo ago
yeah 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)
- esseph 2mo ago> 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. One of the problems a lot of companies are having right now is trying to determine a proper window size between CVE release and patching. On one hand, you have LLM created 0days and attacks are happening almost as fast as CVEs can be posted, and CVEs are being posted at lightning speed. You maybe had a month or a few weeks to patch before, now the window may be down to days or even hours. On the other hand, you want to prevent these repo bombing attacks. There's a tension there but I think we're going to end up measuring that window in hours within the year, if we're not already there.
- rcxdude 2mo agoIf you need quick responses to such things, you're gonna need some intelligence in the loop regardless, even if it's just deciding when it's worth pushing a new release to prod.
- fhdkweig 2mo agoThe term you are looking for is Defense in Depth/Layers
- rcxdude 2mo agoThat makes sense if it's actually a layer. You can create a thousand minor obstacles and it still won't be a very secure system.
- lkjdsklf 2mo agoMissile defense systems are unnecessary because they could just use tanks Anti-tank measures are unnecessary because they can just use missiles
- rcxdude 2mo agoWhat's your solution to using a library without executing the code in it?
- msm_ 2mo agoThis is moving the goalposts. The original problem was that installing a library should not execute code from that library. In most sane environments, like for example native languages, this is already the case. Downloading a .dll file and putting it in an appropriate directory won't, by itself, execute code in that library. You may argue that the code will get executed at some point anyway, but that's besides the point. Sandboxing the build environment is a different problem than sandboxing the test/staging/production environment. I think we both agree that "adding random obstacles that don't actually protect anything" is not a valid approach to security, but my mental model of the build step is "transformation of input data into output data", and while this step may produce a malicious output from malicious inputs, it should not do anything malicious itself. For example, "gcc source.c" should not execute arbitrary code by itself.
- rcxdude 2mo ago>In most sane environments, like for example native languages, this is already the case. Installing a node package is much more like compiling a dll, not downloading it. The same is true for most package managers that exist for C and C++ as languages as opposed to for an OS. These are two different tools for different use-cases. (though still pretty much all installation processes for all OSs involve an opportunity for arbitrary code execution, as well, apart from just downloading a zip file and extracting it, which is not the norm)
- csomar 2mo agoThese half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushing more and more garbage where all you find is 2FA that, captcha this, not supported this, app not signed, etc..
- woodruffw 2mo agoDefense in depth is the “meat and potatoes” of security. In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.
- rcxdude 2mo agoDefence in depth is not just 'throw anything in that might improve security' though. The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed. A stronger layer might be sandboxing, or separating your build and publishing steps as others have suggested (and also probably worth restricting the credentials the publishing step to just the relevant packages as well). These will at least robustly prevent a malicious dependency from spreading horizontally, but you'll still potentially ship malware to your customers.
- woodruffw 2mo agoI would consider 2FA and signing to be strong layers, when applied well. I think everybody agrees we shouldn’t add layers just for the sake of it.
- msm_ 2mo ago>The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed Definitely. On the other hand, in my opinion, "not running arbitrary code during package install" is not a "half-measure", it's a basic sanity. This whole arbitrary code execution at install time is a convenience feature that was adapted by some package managers, but it was never a good idea. Fortunately, nixos solves that for me in most cases.
- 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