Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Ruby gem security changes #3252

Closed
shesek opened this Issue Mar 14, 2013 · 4 comments

Comments

Projects
None yet
5 participants

shesek commented Mar 14, 2013

I stumbled on a post [1] that talks about some security-related changes in Ruby Gems after the recent security issues they had, and I think the author has some good ideas that could be relevant to npm too. Just thought it might be interesting to start a discussion about that.

[1] http://cristianobetta.com/blog/2013/02/02/ruby-gems-are-not-safe-to-use/

Contributor

luk- commented Mar 15, 2013

Is there anything specific you wanted to touch on/propose?

@luk- luk- closed this Mar 17, 2013

shesek commented Mar 28, 2013

For the record, @isaacs response from IRC, along with the Rubygems proposals from the original post:

<shesek> isaacs, any thoughts on https://github.com/isaacs/npm/issues/3252?
<shesek> I do think the ruby guys have some good points
<shesek> isaacs, notifying package owners of changes is a good idea, so is mirroring checksums (if that's not done yet) and signing packages
<shesek> that yaml bug really caught Gem by surprise, they had hard time making sure nothing was effected and restoring everything
<shesek> learning from their mistakes can really make it easier to handle those cases if it ever happens with npm
<isaacs> shesek: so, some of those are planned, some require some nontrivial work, and some are ok ideas, but not high priority.
  • Notify gem owners of newly published gems. Adding a simple email notification to the gem owner will at least allow for easier detection of compromised gems. Sadly at this point the gem is already compromised and possibly already spread over any mirrors and downloaded by users.
<isaacs> shesek: in order: Notify gem owners of newly published gems
<isaacs> shesek: that's a terrible idea.
<isaacs> shesek: if i get an email every time i publish, guess where those emails are going to be automatically routed.
<shesek> how often do people update packages? I would just archive them
<isaacs> shesek: what would be nice is to watch the IP address it comes from, and if there's a publich from a new IP, THEN email the author.
<shesek> it seems to be worth it, for that one case where I got that email if I didn't make the change
<isaacs> shesek: right ,but if the email goes to archive without being seen, you're not going to be alerted.
<shesek> no, I mean, manually archive them
<isaacs> shesek: email alerts have to be rare, and have a high likelihood of being important.
<isaacs> otherwise, they're worth than nothing
<isaacs> ok, well... you probably get a lot less email than I do :)
<isaacs> shesek: or maybe your'e just more tolerant of it than i am
<shesek> yeah, that's true too. perhaps only from different IPs, or even different countries (using geoip) could be a good idea
<isaacs> shesek: but a) we have to have way on the server to track the curren tuser's IP address.  not sure if couch _update functions have this already or not.
<isaacs> shesek: and b) we have to write a thing that monitors the changes feed, and detects new IP blocks, and sends an email
<isaacs> shesek: both parts are non-trivial.
<isaacs> right
<isaacs> if i go to mexico, and then do an npm publish, and get an email about it, then i'm not likely to set up a filter rule because of that.
  • Secure developer’s Rubygems.org credentials. This is pretty simple. My ssh key has a passphrase on it and so should my Rubygems.org credentials. Stealing a rubygems.org API key is easy, using one that requires a passphrase a lot harder.
<isaacs> next:
<isaacs> Secure developer’s Rubygems.org credentials
<isaacs> it'd be nice to have a passphrase.  not everyone would use it, probably.
<isaacs> but etc, etc, defense in depth, yeah, it's a great idea.  patch welcome.
<shesek> is it even possible to sign packages currently?
<isaacs> we're not there yet :)
<shesek> is it planned?
<isaacs> (no, not currently, yes planned, windows makes it hard.)
<isaacs> we can go back to encrypting the _auth field, and use a passphrase, now that everyone has crypto in node 100% of the time (as we bundle openssl)
<isaacs> that's not all that hard.  patch welcome.
  • Stop running code on gem install. I totally see the need for having C extensions in a Ruby gems, and those extensions need to be compiled, but we seriously need to find a way to compile C code without allowing for the arbitrary execution of code on install of a gem.
<isaacs> next:
<isaacs> Stop running code on gem install
<isaacs> hoooo boy.  yeah.  i'd love that.  but like, i don't see how, really.
<isaacs> there IS a plan to only allow `node-gyp` on install, and only for binding.gyp fiels.
<shesek> yeah, that one is pretty problematic, as also noted on hat post
<isaacs> but there's also all this legacy crap that runs `make` and `node-waf` and other stupid things.
<isaacs> not to mention packages that bundle coffee-script as a dep, and then do `cake build` or some bullshit.
<isaacs> so, that'll be many steps to get there.
<isaacs> we can limit what node-gyp is willing to do.
<isaacs> TooTallNate: (feel free to weigh in on this point)
<TooTallNate> isaacs: what's up?
<isaacs> TooTallNate: discussing the points in http://cristianobetta.com/blog/2013/02/02/ruby-gems-are-not-safe-to-use/ wrt npm
<shesek> yeah, it'll break a lot of packages... you'll probably to wait a few months / years between announcing that and actually doing that
<isaacs> TooTallNate: my plan is to make node-gyp eventually the Only One True Way to do binary addons
<isaacs> TooTallNate: and only by running `node-gyp rebuild`, nothing else, ever.
<isaacs> TooTallNate: the problem is that you can make node-gyp do arbitrary commands.
<isaacs> TooTallNate: so we'd have to do something to say that you may only compile a .cc file, and link to .h files etc., but not arbitrary code execution.
<TooTallNate> isaacs: hmmm, that'd be hard… gyp allows arbitrary program execution by design
<bnoordhuis> isaacs, TooTallNate: and it should. how else are you going to run e.g. pkg-config?
<isaacs> exactly my point.
<isaacs> this is hard.
<isaacs> basically, you would end up creating a white-list of commands that are ok to run, and make sure that none of THOSE commands can trigger an arbitrary code expoit.
<TooTallNate> isaacs: i'm still trying to read up on the problem exactly
<TooTallNate> i guess i need to watch this youtube vid
<isaacs> TooTallNate: if you feel so inclined.
TooTallNate> isaacs: do you have the short version? :p
<isaacs> but i think the bottom line with this one is, that's not likely to happen any time soon.
<TooTallNate> is this in preparation for a build farm thing?
<isaacs> TooTallNate: nah, just general "rubygems got haxx0red, how do we not get haxx0red thusly?"
  • Automatically mirror gems and checksums. A system involving the automatic mirroring of gems and their checksums to other servers would definitely have made the verification of gems a lot easier in the last few days.
<isaacs> shesek: so, it's hard, we can keep thinking about it, not likely any time soon.  next: Automatically mirror gems and checksums.
<isaacs> shesek: we actually already do this.
<shesek> oh, that's good
<isaacs> shesek: the registry couchdb is replicated many many places, and couch actually keeps a complete history of docs until you compress it
<shesek> at least we could easily verify everything's okay if somethings does happen
<isaacs> rigth
<isaacs> it would not be trivial, but it would be possible, and we have couchdb experts who would jump in and help (ie, iriscouch)
  • Force signing of gems. Yes, you can sign your gems but almost nobody does (and neither do I). Additionally it’s a pain to force the usage of signed keys on the gem user’s side, not to mention the futility as most gems aren’t signed. Signing is the way to go though and work on this has started. It’s a difficult topic though and work is being done to make it as painless as possible for users and developers.
<isaacs> next: Force signing of gems
<isaacs> we don't have a way to sign npm pacakges currently.
<isaacs> the tricky thing is that "signing" is done very differently on unix (where it's gpg is pretty universal) and windows (where there are other ways)
<isaacs> some people at microsoft have mentioned lending a hand with making this a reality
<isaacs> but basically, someone will have to own it, and it's a nontrivial amount of work.
<isaacs> in theory, we could build something in node to do this, using our crypto stuff, but it really ought to use public gpg keys
  • Notify gem users of unsigned/insecure gems. The rubygem binary (together with tools like Bundler) should be updated to allow for verification of signatures which will allow it to notify gem users of unsigned or compromised gems.
<isaacs> Notify gem users of unsigned/insecure gems: If we had signing, the default would be to have allow-unsigned=false or something
<isaacs> that's trivial, once you have signing
<isaacs> we could also just use the registry as our key authority, and attach the public key to the owner doc, and make sure that signature checks out when you install it, by fetching it right then.  i don't know.  it's not trivial.
<shesek> than the default would be to reject 99% of the packages? sounds somewhat problematic
<shesek> but I guess there's not much you can do... it'll get better over time
<isaacs> well... it'd warn if there's no signature, maybe?
<isaacs> the root problem, really, is that we need someone to step up and decide that they're going to own this kind of stuff.  for the time being, that's not me.
<shesek> I guess it could be a warning for some time, until people are used to it and signing is adopted widely enough... than make it an error by default
<isaacs> it was actually high on my todo list, before ryah ran off and left me holding the node steering wheel :)
<shesek> heh :)
<shesek> is there some issue on it somewhere?
<shesek> if you opened an issue about that, I'm sure people would help
<isaacs> shesek: 1) implementation.  2) once it's widely adopted, start rejecting unsigned publishes.  3) once that's common, start rejecting unsigned installs by default
<isaacs> shesek: so, st_luke closed your issue becuase it was kind of vague.
<shesek> yeah, sounds like a good plan :)
<isaacs> shesek: if you want to take any of these ideas, and create a more specific "next step" issue, be my guest.
<shesek> do you mind if I post the log to that issue I opened? just for the record
<isaacs> shesek: go nuts :)
<isaacs> shesek: i was planning on it, so you'd be saving me the trouble :)

And also:

<isaacs> shesek: Oh! another issue: once i refactor the cache/registry interaction a bit, we can make `npm shrinkwrap` provide byte-level security
<isaacs> shesek: ie, if the shasum changes, it'll be considered a shrinkwrap failure.
Owner

isaacs commented Mar 28, 2013

Good discussion here: http://logs.nodejs.org/node.js/latest#22:46:41.061

We went through the major issues point by point.

Bottom line: All of these are mostly great ideas, but require either some refinement, some outside-of-npm work, and some non-trivial inside-of-npm work.

@isaacs isaacs reopened this Mar 28, 2013

@luk- luk- referenced this issue Aug 24, 2013

Closed

Update npm-faq.md #3815

@KenanY KenanY referenced this issue in node-forward/discussions Jan 16, 2015

Open

Signed and certified packages #29

Contributor

othiym23 commented Apr 21, 2016

There are a lot of ideas in this issue, some of them quite good and still relevant, some of them not achievable given the current state of the JS package ecosystem. As currently filed, there's no one thing that the CLI team can act on here, which makes this an awkward thing to have around. I'm going to close this, with the recommendation that people who happen across it (or @shesek) who have requests for the specific feature enumerated in here open new feature requests that can be tracked, discussed (and closed) independently. Thanks for the detailed proposals and discussion, and thanks for your time!

@othiym23 othiym23 closed this Apr 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment