5 ms·

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 t

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.

Someone1234 8y ago
Wouldn't that preclude the usage of npm almost entirely? npm from a security standpoint feels a little like a house of cards.
- Jeremy1026 8y ago
  Using npm has never been secure, here is a fun little article about how someone used npm to inject malware into thousands of sites. https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://hackernoon.com/im-harvesting-credit-card-numbers-and...
  - nneonneo 8y ago
    That’s a hypothetical piece (read it to the end), not the account of something that actually happened. Regardless, it still highlights the fact that everything is built on a rather fragile layer of trust.
    - TooBrokeToBeg 8y ago
      NPM is still not secure. So dangerous, many companies run their own NPM repos with analyzed packages.
    - da_chicken 8y ago
      I mean, there hasn't been anything as malicious as that, but... 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/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [1]: https://www.reddit.com/r/programming/comments/886zji/why_has_there_been_nearly_3_million_installs_of/ https://www.reddit.com/r/programming/comments/886zji/why_has...
      - Vinnl 8y ago
        > The left-pad issue [0] highlights how one developer can unpublish their code and result in breaking every package depended on that package. 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.
  - deleted 8y ago
    [deleted]
  - latchkey 8y ago
    In a similar vein, here is a fun issue I filed: https://github.com/npm/npm/issues/20072 https://github.com/npm/npm/issues/20072
- tlrobinson 8y ago
  npm might be one of the riskiest, but most other package managers aren't materially better.
koolba 8y ago
> 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.
- tetha 8y ago
  This is going to be interesting for the go-guys, since a lot of go package management is built around git clones. It's probably fine for things hosted on gitlab, github or bitbucket, and then you missed that one sneaky little dependency stabbing you in the back.
  - lolc 8y ago
    Why is it more interesting for the go packaging situation? As far as I'm aware, most packaging systems run scripts from inside the packages anyway. If you're running the packages' scripts, being vulnerable to this is a side-note. You have to trust the packagers anyway.
- cesarb 8y ago
  From what I understood, it's only "git clone --recursive"/"git clone --recurse-submodules" or "git submodule init ..." that's vulnerable, not bare "git clone". So the flow of (1) clone (2) look at .gitmodules (3) git submodule init (4) analyze would still work.
- jacquesm 8y ago
  Even with tarballs all it takes is one fuck-up in a script and your homedirectory is gone. In that sense nothing is safe. You could of course audit all the code that the makefile or build script executes but I really don't know anybody that would do that for anything beyond the trivial. 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.
  - 8y ago

Someone1234 8y ago

Wouldn't that preclude the usage of npm almost entirely? npm from a security standpoint feels a little like a house of cards.

Jeremy1026 8y ago
Using npm has never been secure, here is a fun little article about how someone used npm to inject malware into thousands of sites. https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://hackernoon.com/im-harvesting-credit-card-numbers-and...
- nneonneo 8y ago
  That’s a hypothetical piece (read it to the end), not the account of something that actually happened. Regardless, it still highlights the fact that everything is built on a rather fragile layer of trust.
  - TooBrokeToBeg 8y ago
    NPM is still not secure. So dangerous, many companies run their own NPM repos with analyzed packages.
  - da_chicken 8y ago
    I mean, there hasn't been anything as malicious as that, but... 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/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ [1]: https://www.reddit.com/r/programming/comments/886zji/why_has_there_been_nearly_3_million_installs_of/ https://www.reddit.com/r/programming/comments/886zji/why_has...
    - Vinnl 8y ago
      > The left-pad issue [0] highlights how one developer can unpublish their code and result in breaking every package depended on that package. 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.
- deleted 8y ago
  [deleted]
- latchkey 8y ago
  In a similar vein, here is a fun issue I filed: https://github.com/npm/npm/issues/20072 https://github.com/npm/npm/issues/20072
tlrobinson 8y ago
npm might be one of the riskiest, but most other package managers aren't materially better.

koolba 8y ago

> 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.

tetha 8y ago
This is going to be interesting for the go-guys, since a lot of go package management is built around git clones. It's probably fine for things hosted on gitlab, github or bitbucket, and then you missed that one sneaky little dependency stabbing you in the back.
- lolc 8y ago
  Why is it more interesting for the go packaging situation? As far as I'm aware, most packaging systems run scripts from inside the packages anyway. If you're running the packages' scripts, being vulnerable to this is a side-note. You have to trust the packagers anyway.
cesarb 8y ago
From what I understood, it's only "git clone --recursive"/"git clone --recurse-submodules" or "git submodule init ..." that's vulnerable, not bare "git clone". So the flow of (1) clone (2) look at .gitmodules (3) git submodule init (4) analyze would still work.
jacquesm 8y ago
Even with tarballs all it takes is one fuck-up in a script and your homedirectory is gone. In that sense nothing is safe. You could of course audit all the code that the makefile or build script executes but I really don't know anybody that would do that for anything beyond the trivial. 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.
- 8y ago