I always advocate switching to pnpm where install scripts are disabled by default. It has plenty of security features to ward off most supply chain attacks.
techpeakedin1991@lemmy.ml
on 31 Mar 14:47
collapse
Does disabling install scripts actually do anything though? The attack would still work if put in the code itself, no? The only difference I can see is that it would run when the project is run instead of when the package is installed.
TechnoCat@piefed.social
on 31 Mar 19:58
nextcollapse
On closer inspection, preventing post-install would have fixed it too: “The attack exploited a transitive dependency, plain-crypto-js@4.2.1, which executed a postinstall script to deploy the RAT.”
threaded - newest
Doesn’t seem to have been live for very long.
You can mitigate similar attacks by editing your .npmrc
It’s a good way to keep the exploit around for seven days, too, if you apply it right away.
I agree, I think it would be better to use something like dependabot or renovatebot so you can know of and apply security updates right away.
As long as the bot is not allowed to automatically merge minor version bumps in libraries…
Well yes, one can misuse any tool.
How? If you got hit by this you are looking at restoring the system from a safe previous version.
And the compromised versions get pulled, not superseeded by a new release, so once you rebuild you would go back to a safe version…
I always advocate switching to
pnpmwhere install scripts are disabled by default. It has plenty of security features to ward off most supply chain attacks.Does disabling install scripts actually do anything though? The attack would still work if put in the code itself, no? The only difference I can see is that it would run when the project is run instead of when the package is installed.
Minimum age would have prevented it in this case.
On closer inspection, preventing post-install would have fixed it too: “The attack exploited a transitive dependency, plain-crypto-js@4.2.1, which executed a postinstall script to deploy the RAT.”