Another reason to train yourself to always think before you execute code you found on a site.
Too many of us are so used to git clone'ing a repo and building the software with make or its descendants that we overlook the security considerations.
Too many of us are so used to git clone'ing a repo and building the software with make or its descendants that we overlook the security considerations.
The issue here is that the "git clone ..." allows for arbitrary code execution so the flow of 1) clone 2) analyze 3) make breaks at step 1.
Looks like it's back to tarballs for me.
We've been totally conditioned to just wget some archive, unpack it and build it, and even if git clone takes it one step further in day-to-day practice there is no difference between the two.
And depending on the sophistication you might want to do that in a chrooted environment or a VM.
It does not, actually. It's the submodule steps that create the vulnerability, and those have to be done manually. There are no standard or automated ways of pulling submodules, every project that uses them has its own scheme and provides its own build instructions. Frankly they're pretty obscure and in most communities replaced by tricks like npm's dependency management instead. It's a goof, and fixed, but even for the most naive users the exposure is fairly low.
It's true that it happens early in the process, but it's not true that a simple git clone command is a vector.
I’m pretty sure that it would be trivial to hide malicious code in a tarball that you wouldn’t find (especially if you’re not expecting it).
npm from a security standpoint feels a little like a house of cards.
Regardless, it still highlights the fact that everything is built on a rather fragile layer of trust.
The left-pad issue [0] highlights how one developer can unpublish their code and result in breaking every package depended on that package. "Unpublish" can be substituted for anything from "unpublish" to "publish broken code" or "publish actively malicious code."
Further, issues like the is-odd/is-even package popularity spike how developers can develop minimally beneficial encapsulation packages and then insert them into other packages as dependencies to pump up their numbers. [1] Well, what if someone's motivation wasn't to make their packages look important but to instead give them a way to inject code to all the locations (or maybe just one!) that run `npm update` or similar automatically on a daily basis.
No, neither of these events that have actually happened are particularly malicious. On a scale of "excessive use of service" to "full network worm ransomware" they're somewhere around "suspiciously sketchy." But, the same problem can be exploited to cause real damage. Yeah, it very much reveals how fragile the web of trust in NPM is.
I really do hate to keep posting these links, but people keep bringing NPM up where they're relevant!
[0]: https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
[1]: https://www.reddit.com/r/programming/comments/886zji/why_has...
How they could unpublish their code. left-pad's specific issue is no longer allowed by npm and thus could not arise today. That's not to say other issues could not crop up, of course.