Live data from Hacker News

Ruby gems are still not safe to use

cristianobetta.com

1–10 of 45 posts

Re: Ruby gems are still not safe to use

#3
"Stop running code on gem install."

- this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha...

as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions....

Seeing how many references exist to "sudo gem install blah"... this is very serious as it's a high reward if you're able to get your remote code executing with root privileges (assuming as most would not limit sudo access e.g. user ALL=(ALL) ALL )...

Re: Ruby gems are still not safe to use

#4
post #3

"Stop running code on gem install." - this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha... as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions.... Seeing how m…

I don't see the big gain in stopping to run code on install. By definition, we install gems to run code. If we don't trust the gem author not to mess with our system on install, how can we trust him not to mess with our system when we use the gem? Granted, there might be some people that install gems as root and run them as unprivileged user only, but even as a non-root user it's a problem to run code you don't trust.

Re: Ruby gems are still not safe to use

#5
The call to action in this post is not strong enough - RubyGems and RubyGems.org are completely volunteer-run, open source projects. If you want to fix these problems, please get involved and stick around.

Re: Ruby gems are still not safe to use

#6
post #3

"Stop running code on gem install." - this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha... as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions.... Seeing how m…

You don't have to install with root permissions. If you run as normal user it will install to the home directory instead. But many people want to install gems system-wide so they install with sudo.

The real problem is executable code. Building C extensions typically require invoking arbitrary commands. The problem is also not unique to RubyGems: RPMs and DEB packages have preinstall and postinstall scripts, and they require root privileges.

I think a good solution would be to to run C extension compilation code as a sandboxed non-root user. If a RubyGem is being installed as a normal user, the compilation code should still be run as a separate, sandboxed user, to prevent it from messing with the user's home directory. Any build products that the compilation process generates will be copied over the destination directory. The sandbox user's home directory would be wiped after every installation.

This would severely limit the C extension building system's power (they can't generate files outside the gem directory etc without being wiped) but I think that's acceptable. Use cases that require more power can rely on external user-invoked commands, e.g. passenger-install-apache2-module.

Re: Ruby gems are still not safe to use

#7
post #4
post #3

"Stop running code on gem install." - this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha... as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions.... Seeing how m…

I don't see the big gain in stopping to run code on install. By definition, we install gems to run code. If we don't trust the gem author not to mess with our system on install, how can we trust him not to mess with our system when we use the gem? Granted, there might be some people that install gems as root and run them as unprivileged user only, but even as a non-root user it's a problem to run code you don't trust…

You're right, I totally didn't think about that. Securing the C compilation system could give a false sense of security.

What we should have instead is a good signing infrastructure to detect when trusted gems have been tampered by a third party.

Re: Ruby gems are still not safe to use

#8
post #4
post #3

"Stop running code on gem install." - this is a real issue. I've used rpm shell execution to modify sshd as well as other system components in order "install" additional software. http://web.archive.org/web/20090211040821/http://www.idle-ha... as you can see from that archived post, it's very important to have trust of what you are installing. especially when you have to install with root permissions.... Seeing how m…

I don't see the big gain in stopping to run code on install. By definition, we install gems to run code. If we don't trust the gem author not to mess with our system on install, how can we trust him not to mess with our system when we use the gem? Granted, there might be some people that install gems as root and run them as unprivileged user only, but even as a non-root user it's a problem to run code you don't trust…

Well... you would have to trust both the gem author and those who might have compromised an author's credentials. And my understanding is that the install can easily be running under a different set of credentials than normal use. (not a Ruby or Rails user here)

Re: Ruby gems are still not safe to use

#10
Removing the ability to run code on gem install would be quite disruptive. I think that establishing a universal gem signing policy and/or some form of whitelist/blacklist strategy would be a better solution. Consumers need to be able to trust the installations of the tools they use. The same risks apply to any other installation process. Think of how we install RVM or Homebrew.
Post reply on HN