3 ms·

I'm not sure I get this. You can be pretty sure the platform on which your js package is installed has a js runtime. But it might not have shell or make (eg: wi

by e12e 6y ago

I'm not sure I get this. You can be pretty sure the platform on which your js package is installed has a js runtime. But it might not have shell or make (eg: windows). If you have specific needs and no ambition for being cross-platform ; sure, go ahead and use rc, batch, shell scripts. And no, just staying with js isn't enough to be cross platform - but you'll be closer. I don't see why a package would have a backdoor in install, but not run - or not in the package code itself?

dubbel 6y ago
It's by far the most popular method of malicious payload execution for these kinds of attacks. It's easy to write, definitely executed (if not for the settings suggested by the blog posts), doesn't depend on the usage of the library by the victim, and you don't really need to know anything about the setup the victim has. You are right in that it's not the patch that fixes the entire problem, but that is rarely the case in security. Source: earlier this year i analysed every package dependency compromise between 2006-2017. https://www.haukeluebbers.de/blog/2020-01-timeline-of-package-dependency-compromises/ https://www.haukeluebbers.de/blog/2020-01-timeline-of-packag... You can see that the most common method for npm, Rubygems and pypi is something like "Method: executed by install hook"