New Vulnerabilities Discovered in Ruby (August 2008)
Photo by JL2003 - CC 2.0 Attribution License
In June, a serious security advisory was put out about the official (MRI) Ruby interpreter for all versions prior to 1.8.5, 1.8.6 prior to patch 231, 1.8.7 prior to patch 22, and 1.9.0 prior to 1.9.0-2. Now (August 8, 2008) a new set of vulnerabilities have been discovered and announced. They affect all 1.8.5 releases, 1.8.6 patch 285 and prior, 1.8.7 patch 70 and prior, and Ruby 1.9 r18423 and prior. This almost certainly means an upgrade is required for most users as all but very recent versions are affected.
The vulnerabilities discovered this time around aren't, on the surface, quite as serious as those last time around. Several vulnerabilities in safe level have been discovered (essentially there are some clever ways of getting around a few safe level restrictions), WEBrick's default file handler has a bug that results in certain operations taking exponential time, resolv.rb is open to the recently popularized DNS spoofing tactics, and dl doesn't check whether variables used in calling functions are tainted or not. These issues are all covered on the official Ruby news page about the vulnerabilities, along with some advice on how to upgrade.
Upgrading to the latest stable version is always a good idea (assuming you check if your apps will still work - Rails had/has problems with certain 1.8.6/1.8.7 versions) but if you're sure you (and your libraries!) are not using any of the features mentioned above, this set of vulnerabilities doesn't present any reason to panic, unless you're heavily reliant on safe mode or allow tainted variables to even reach something as powerful as dl.
August 9, 2008 at 4:32 am
This time we are better prepared, we had hardly forgotten the last experience, including compiling on windows(with msys).
Another couple of incidents of this sort will scaring the customers, this will be bad for the community
I strongly believe all code including core libraries need to have unit tests. I am willing to offer one developer full time to write tests, review memory leaks and performance issues, if MRI moves to github.
August 9, 2008 at 11:43 am
Quite an offer, that! :)
However, while I do agree that security issues like these are bad for business, and that all code should have unit tests to help prevent this sort of thing, the question is if it's really worth putting all that much energy into MRI at this time, seeing as YARV and Rubinius are gaining maturity by the minute, and many of the memory and performance issues of MRI have been addressed by Ruby Enterprise Edition. Perhaps your resources are better spent supporting one of these projects?
Speaking of Ruby Enterprise Edition - will we see a backport of these security fixes in the near future?
August 9, 2008 at 1:04 pm
I think this could be the ideal time for the Phusion guys to set out what they want to ultimately achieve with REE and perhaps attempt to get a lot more people involved and turn it into the de-facto MRI replacement (rather than as a mere side option). Okay, it'd effectively be forking MRI, but perhaps MRI needs to be forked?
I know the Phusion guys read Ruby Inside, so they might want to comment, but I'd certainly be interested in supporting an effort to encourage MRI over to Github and to have better tests. Whether this is achieved on MRI-proper or REE is a matter of argument. The proactiveness of the REE guys encourages me to support them more, but this might also be because they're English-speakers and the Japanese-led development of MRI feels a little alien to me.
August 9, 2008 at 5:43 pm
+1 for Phusion guys to be officially included into ruby CDT, otherwise all this will screw up the rails biz sooner as we expect. We switched with our servers to phusion after the first advisory.
August 9, 2008 at 10:33 pm
I like what Phusion does and use both Passenger and REE, but I really hate their branding choices - Phusion looks hackerish with the "ph", REE mimics Java EE and for good or bad the Java style is "considered harmful" in the Ruby land, and last, but not least... Passenger, modpassenger, modrails, modrack... why not stick with one single name and remove the references to the rest even from their website as it's confusing?
August 10, 2008 at 9:54 am
Thanks for the encouraging words, people.
We're already aware of these security vulnerabilities, and we've already been busy preparing a new Ruby Enterprise Edition release because of this. Previous Ruby releases had crash bugs and compatibility problems, so we're testing the latest release to ensure that there are no crashers or incompatibilities.
Yesterday we had tested Ruby 1.8.6-p286 against the Rails test suite and the RubySpec test suite. The results are very promising: all tests pass. In fact, Ruby 1.8.6-p286 passes more RubySpec tests (read: all of them) than 1.8.6-p114 (the version that the current Ruby Enterprise Edition release is based on). We'll do some final QA testing today before releasing a new Ruby Enterprise Edition version.
@Nikolay: I'm sorry if you're confused by the branding. Phusion Passenger is just Phusion Passenger: the name "mod_rails" is only for marketing purposes because everybody who reads it will immediately know what it is. On the other hand, Phusion Passenger isn't "mod_rails" anymore because it also supports Rack and WSGI now. Rack support was planned from the beginning, which is why we had constantly been calling it "Phusion Passenger (mod_rails)" ("mod_rails" between brackets): the message that we want to give to the outside world is that "Phusion Passenger" is the name, while "mod_rails" is its primary function. We advice you to use the name Phusion Passenger from now on. Thank you.
August 10, 2008 at 5:50 pm
@Hongli Lai: I'm not personally confused by the branding; I think it's confusing to the mass audience. No comment on Ruby Enterprise Edition? :-) "Enterprisey" is a bad bad word in the Rails!
Anyway, I'm looking forward to the new REE release and I hope everybody switches to it soon making MRI less significant as their recent fiascos are unhealthy for Rails and Ruby in general.
August 10, 2008 at 7:39 pm
"Enterprisey" might be a bad word in Rails, but it's accepted with Ruby. My parent company (in Japan) has one of the top Ruby people (don't know if I can say) consult on a frequent basis on how to make Ruby more acceptable in the enterprise (I'm guessing this is where some of the talk of ISO standardization is coming from).
Not that you're saying this, Nikolay. :) I just wanted to clarify.
August 10, 2008 at 9:40 pm
A new Ruby Enterprise Edition version based on 1.8.6-p286 has been released: http://tinyurl.com/6x36ad
August 11, 2008 at 12:54 am
@Nikolay: history may not be the judge of future to come, enterprise is not a bad word or bad market to be in. I am evangelising ruby in enterprise and answering their concerns. We have a long way to go before we see mass adoption.
@Hongli Lai: thanks , it was re-assuring.
I had heard good things about passenger and ruby enterprise, ease of install, memory optimizations from my team members and ruby friends.
the way I percieve ruby enterprise is a MRI ruby fork which gets the enhancements, which would get back into MRI
Are you planning public access to your SCM for ruby enterprise edition, that is one benchmark I have for "participatory" open source, and thats why I was never on Java platform.
August 11, 2008 at 4:35 am
@Senthil: I'm talking about buzzwords, not the meaning behind them. Enterprise grade, industrial strength, bulletproof, 24x7, etc. are buzzwords from the previous cycles. I personally like the buzz-neutral Phusion Ruby much better than REE, but I might be totally wrong as the Fortune 100/500 folks might be requiring their double E's. :-)
August 11, 2008 at 8:22 am
@Senthil: The code is on Github so one doesn't really need to have write access to our repository. That said, if anyone wants write access and have a good reason, then please contact me and we'll work something out.
It's our long-term goal to get the changes integrated back into upstream Ruby. In the short term we're considering integrating useful patches, such as the Bleakhouse's patches and some patch which allows one to print the backtraces of all threads.
August 28, 2008 at 8:32 am
Thank you so much for notifying us with the vulnerabilities of ruby. It is somewhat amazing because i was thinking that this new version of ruby had not any vulnerability