23
The recently-announced vulnerabilities in Ruby have put many of us administering Rails applications in a production space between a rock and a hard place.
To recap, there are three major “lines” of Ruby interpreters, the 1.8.6 line, the 1.8.7 line, and the 1.9 line. All of these show the vulnerability, so nearly everyone needs to update their Ruby. (I’ll get to the exceptions later.) Rails introduces a new line of complication, because the 1.8.7 only works for Rails 2.1 and newer; if the Rails apps in question aren’t ready for Rails 2.1, or already running it (unlikely), the best route would be to continue to update in the 1.8.6 line. So there’s the rock: we need to update our Ruby.
The “hard place” is that the only patches so far released by the Ruby maintainers tend to produce segmentation faults, according to many who have tried them so far. That’s a long way of saying, “They don’t work.”
As a Rails-supporting sysadmin with, you’re left with several options, none of them comfortable. You can, in order of increasing riskiness:
- Wait out the Ruby maintainers and hope they release a working 1.8.6 patchlevel before your app is compromised.
- Do crash-priority Rails upgrades on all your apps and switch to Rails 2.1, then move your Ruby to the 1.8.7 line.
- Switch to an entirely different Ruby interpreter, like Rubinius or JRuby. (This hinges on the idea that Ruby is an interpreted language, and as long as the language is interpreted consistently there is room for any number of interpreters. Apparently JRuby and Rubinius are not affected by these vulnerabilities, only MRI, Matz’s Ruby Interpreter, which is the “standard” implementation.)
- Switch to a different production stack entirely. For example, we’re currently using Apache 2.2 as a proxy for a Mongrel cluster in front of Rails 2.0.2 apps, a not-uncommon configuration. This could be the pressure we’d need to jump to Phusion Passenger, given that their Ruby Enterprise Edition claims to have applied the security patches to MRE 1.8.6 p111, and thus doesn’t introduce the segfault-inducing breaking features that the most-recent patchlevel does.
I don’t know which way we’re going yet, but I’m not interested in waiting too long, and the upgrade to Rails 2.1 is going to happen sometime anyway, so Option #2 seems most likely for us.
Update: Hongli Lai from Phusion assures us (in the comments) that Ruby Enterprise Edition can be used as a drop-in replacement for MRE without replacing the entire stack, moving REE up to the front of the line in the “different interpreter” option. Discussion seems to suggest to me that new official patches from the Ruby maintainers will not be coming in a timely fashion, but we are beginning to see “contributed” patched distributions emerge for e.g. FreeBSD and Debian.
filed under: Ruby on Rails, System Administration | permalink
2 Responses to “Solutions for Ruby vulnerabilities”
-
Hongli Lai Says:
June 23rd, 2008 at 11:26 amYou don’t have to switch production stack. You can use Ruby Enterprise Edition with your existing Mongrel setup. It’s just a matter of running ‘/opt/ruby-enterprise…./bin/mongrel_rails cluster::start’ instead of ‘mongrel_rails cluster::start’.
-
Rails asset hosts and SSL » Common Media, Inc. Says:
July 15th, 2008 at 12:45 pm[...] two gotchas here, though: First, you need to be using Rails 2.1.0 or better. (This, combined with the Ruby problems that came up last month, pushed La Cucina to Rails 2.1.) The example in the documentation, however, [...]