5 ms·

Ruby gems are still not safe to use

58 points by cbetta 14y ago

helloamar 14y ago
Then y many are giving lot of hype?
- tr4656 14y ago
  Because Ruby is something they use and they want to fix the problem. If they don't highlight the problems, nothing will get solved.
taf2 14y ago
"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-hacking.com/2008/05/i-say-cap-you-say-rpm-i-cap-your-rpm/ 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 )...
- Xylakant 14y ago
  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.
  - FooBarWidget 14y ago
    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.
  - h_r 14y ago
    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)
    - FooBarWidget 14y ago
      You don't need root to do serious damage. Even if you secure the gem installation process, the code inside the game can just do damage later. I think a signing system to prevent third party tampering of gems is the best that any developer packaging system can do.
    - Xylakant 14y ago
      It's more standard to have rails apps run under a dedicated and lower privileged user than not. It's also a common option to use vendored dependencies for a variety of reasons: You (a) avoid conflicts with other installed gems on the system and (b) don't need elevated privileges to install the app. But let's not just talk about rails: There's a ton of tools that use ruby to manage stuff, some of them running as root by default - both chef and puppet are written in ruby and sometimes distributed as gems. In any case, they use gems. So all it needs is to have one binary exploited to start a shell and then you have an entry point from where you can escalate privileges and obtain root. So if you don't trust rubygems you can't install anything in ruby.
- FooBarWidget 14y ago
  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.
- wildchild 14y ago
  There is also Gemfile that can FileUtils#rm_rf
qrush 14y ago
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.
- PommeDeTerre 14y ago
  Another approach is to completely move away from using Ruby, Ruby on Rails and related software. I think that the recent security issues are evidence of many systemic problems within the Ruby community, and with their approach and attitude toward software development. Security should be inherent and considered from the very start, rather than brought on over time by an endless stream of patches and updates. Furthermore, the focus should not be on cranking out libraries and code as quickly as possible, especially when said code is rife with security holes. There are many other programming languages, libraries and communities that take a far more sensible approach to software development. We see far fewer of these kinds of issues arise when things are not done the "Ruby" way.
  - phillc 14y ago
    Your philosophies are sound for banking software. There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.
    - PommeDeTerre 14y ago
      That's a very dangerous attitude to have. Security is not something that should be traded off just to reduce development time or effort slightly. Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.
hopsoft 14y ago
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.
grandalf 14y ago
Even if 5% of the rubygems ecosystem contained malware, the biggest danger to most projects is the inclusion of gems that are sloppily maintained. Just because something is released as a gem does not mean it has good code quality or that good development practices were used to create it. The default behavior of bundler is to grab the latest compatible gem version, and in many cases this breaks things bc of little or no QA on the part of some gem maintainers. The top 10% of gems are well maintained but the rest should generally be avoided.
nicholasjarnold 14y ago
Is it safe to install rails with something like 'gem install rails' right now? I'm totally new to Ruby and to the Rails framework, but I was going to start a side project with it this weekend (today). Any advice on how I can safely get setup while the community is figuring out how to cope with the intrusion?
- oscardelben 14y ago
  yes, all gems have been verified.
  - nicholasjarnold 14y ago
    Thank you.
curcumin 14y ago
This hyperbole is very silly! Weaknesses appear in everything when it becomes popular. There needs to be something like the "app store" and I don't mean specifically apples' own. But we need some of the big corps using ROR to step forward and provide complete support for this type of project.
mark_l_watson 14y ago
Sorry in advance for being off topic, but: I rely a lot on Clojure repos like clojars.org and I in addition to checking my few Rails and Sinatra apps in the last few days, I have become a little concerned about the same sort of thing happening with clojars, main mavin repos, etc.
ef4 14y ago
Worrying about code execution at install is silly. The whole point of installing a gem is to download code that you're going to execute. So the whole gem (install code and runtime code) needs to be trusted, and should be verifiably signed by somebody you can trust.
- Turing_Machine 14y ago
  Right. Some of these are legitimate issues, but not that one. Given that the Ruby code in the gem has full access to the file system with the privileges of whoever is running it, I don't see how this makes things any worse (assuming you're not installing the gems as root or whatever).
- static_typed 14y ago
  I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems. Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but what about when he pulls in a dependency, that pulls in another dependency, and suddenly you have gems from developer B, who loves to stick a Yaml parser out there for all to compromise. The whole design needs a rethink.
  - Xylakant 14y ago
    But isn't that a problem where no good solutions exist? We share code to reuse code. If we insist to allow only one level of dependencies, then we restrict code reuse which is bad in other ways: you promote reimplementation of functionality, more often bad than good.

58 points by cbetta 14y ago

helloamar 14y ago

Then y many are giving lot of hype?

tr4656 14y ago
Because Ruby is something they use and they want to fix the problem. If they don't highlight the problems, nothing will get solved.

taf2 14y ago

"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-hacking.com/2008/05/i-say-cap-you-say-rpm-i-cap-your-rpm/ 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 )...

Xylakant 14y ago
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.
- FooBarWidget 14y ago
  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.
- h_r 14y ago
  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)
  - FooBarWidget 14y ago
    You don't need root to do serious damage. Even if you secure the gem installation process, the code inside the game can just do damage later. I think a signing system to prevent third party tampering of gems is the best that any developer packaging system can do.
  - Xylakant 14y ago
    It's more standard to have rails apps run under a dedicated and lower privileged user than not. It's also a common option to use vendored dependencies for a variety of reasons: You (a) avoid conflicts with other installed gems on the system and (b) don't need elevated privileges to install the app. But let's not just talk about rails: There's a ton of tools that use ruby to manage stuff, some of them running as root by default - both chef and puppet are written in ruby and sometimes distributed as gems. In any case, they use gems. So all it needs is to have one binary exploited to start a shell and then you have an entry point from where you can escalate privileges and obtain root. So if you don't trust rubygems you can't install anything in ruby.
FooBarWidget 14y ago
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.
wildchild 14y ago
There is also Gemfile that can FileUtils#rm_rf

qrush 14y ago

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.

PommeDeTerre 14y ago
Another approach is to completely move away from using Ruby, Ruby on Rails and related software. I think that the recent security issues are evidence of many systemic problems within the Ruby community, and with their approach and attitude toward software development. Security should be inherent and considered from the very start, rather than brought on over time by an endless stream of patches and updates. Furthermore, the focus should not be on cranking out libraries and code as quickly as possible, especially when said code is rife with security holes. There are many other programming languages, libraries and communities that take a far more sensible approach to software development. We see far fewer of these kinds of issues arise when things are not done the "Ruby" way.
- phillc 14y ago
  Your philosophies are sound for banking software. There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.
  - PommeDeTerre 14y ago
    That's a very dangerous attitude to have. Security is not something that should be traded off just to reduce development time or effort slightly. Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.

hopsoft 14y ago

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.

grandalf 14y ago

Even if 5% of the rubygems ecosystem contained malware, the biggest danger to most projects is the inclusion of gems that are sloppily maintained. Just because something is released as a gem does not mean it has good code quality or that good development practices were used to create it. The default behavior of bundler is to grab the latest compatible gem version, and in many cases this breaks things bc of little or no QA on the part of some gem maintainers. The top 10% of gems are well maintained but the rest should generally be avoided.

nicholasjarnold 14y ago

Is it safe to install rails with something like 'gem install rails' right now? I'm totally new to Ruby and to the Rails framework, but I was going to start a side project with it this weekend (today). Any advice on how I can safely get setup while the community is figuring out how to cope with the intrusion?

oscardelben 14y ago
yes, all gems have been verified.
- nicholasjarnold 14y ago
  Thank you.

curcumin 14y ago

This hyperbole is very silly! Weaknesses appear in everything when it becomes popular. There needs to be something like the "app store" and I don't mean specifically apples' own. But we need some of the big corps using ROR to step forward and provide complete support for this type of project.

mark_l_watson 14y ago

Sorry in advance for being off topic, but: I rely a lot on Clojure repos like clojars.org and I in addition to checking my few Rails and Sinatra apps in the last few days, I have become a little concerned about the same sort of thing happening with clojars, main mavin repos, etc.

ef4 14y ago

Worrying about code execution at install is silly. The whole point of installing a gem is to download code that you're going to execute. So the whole gem (install code and runtime code) needs to be trusted, and should be verifiably signed by somebody you can trust.

Turing_Machine 14y ago
Right. Some of these are legitimate issues, but not that one. Given that the Ruby code in the gem has full access to the file system with the privileges of whoever is running it, I don't see how this makes things any worse (assuming you're not installing the gems as root or whatever).
static_typed 14y ago
I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems. Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but what about when he pulls in a dependency, that pulls in another dependency, and suddenly you have gems from developer B, who loves to stick a Yaml parser out there for all to compromise. The whole design needs a rethink.
- Xylakant 14y ago
  But isn't that a problem where no good solutions exist? We share code to reuse code. If we insist to allow only one level of dependencies, then we restrict code reuse which is bad in other ways: you promote reimplementation of functionality, more often bad than good.