June 2008 Ruby Security Advisory: A Summary
Photo by JL2003 - CC 2.0 Attribution License
The official Ruby blog is reporting "multiple vulnerabilities" in the official Ruby interpreter (MRI). A significant number of versions are affected:
- All versions prior to 1.8.5
- All 1.8.5 versions prior to patch 231
- All 1.8.6 versions prior to patch 230
- All 1.8.7 versions prior to patch 22
- All 1.9.0 versions prior to 1.9.0-2
Jeremy Kemper, at the official Rails blog, advised upgrading immediately, but with the warning that Ruby 1.8.7 only works with Rails 2.1 and later. Numerous commenters, however, have noted significant issues with Rails applications once they've upgraded to Ruby 1.8.6p230 and 1.8.5p231. A poster on RubyFlow suggests Ruby 1.8.6-p230 is not compatible with Rails at all, although others have reported success.
What are the problems?
*** **** has put together a pretty detailed look at what the actual defects are (mostly "general buffer overflow defects, signed integer problems, and path traversal problems").
Eric Monti has posted code examples to demonstrate some issues.
Is it urgent?
It appears that while this is a significant security advisory, and you should be paying attention, there's no 0-day urgency on this as Eric Wong highlights. Walk, but don't run, to the exit. Eric Monti, on the other hand, seems to be quite worried by the security vulnerabilities.
If you're only running your own scripts on your own local machine (that is, not a public-facing Web app), you might be better off waiting for your operating system's packaging system to update Ruby for you (whether on Linux or OS X). The security issues were discovered by Drew Yao of Apple who has suggested a OS X update for this will be going out soon, so it's reasonable to wait for that if you're on OS X.
My personal advice (which is, as noted by Thomas H. Ptacek, "spectacularly bad") is that unless you're already itching to upgrade out of panic, just make sure you're familiar with where all your Ruby deployments are, what versions they're running now, and that you have a good idea of how to upgrade them. Then unless you're confident about upgrading and running tests straight away, I'd wait until a lot more positive noises are coming out of Rails developers upgrading to the latest versions, especially surrounding Ruby 1.8.6p230.
Update: In comments, Thomas H. Ptacek says:
The “walk don’t run” sentiment is dead wrong. You do not need to handle multi-gigabyte strings to trip these vulnerabilities; you just need code that can be coerced into using broken indices. It’s spectacularly bad advice to suggest that people should continue to run code with known memory corruption vulnerabilities.
Quite why anyone would have code that relies on any unchecked / unsanitized data is beyond me, but it's worth keeping in mind if you do. So, panic if you want, but even if you don't, you'll probably still be alive and this news will be forgotten within a week or two.
June 22, 2008 at 5:43 am
I'm not sure you should be citing *** here. Much of his explanation appears to be wrong.
June 22, 2008 at 5:45 am
The "walk don't run" sentiment is dead wrong. You do not need to handle multi-gigabyte strings to trip these vulnerabilities; you just need code that can be coerced into using broken indices. It's spectacularly bad advice to suggest that people should continue to run code with known memory corruption vulnerabilities.
June 22, 2008 at 5:46 am
I still stand by it, but I'll update the post to share your concerns.
June 22, 2008 at 6:24 am
Peter --- Ruby devs don't check integer indices because Ruby is an EAFP language (ask forgiveness, not permission) --- it throws exceptions or returns "nil" when you get things like array indexes wrong. Lots of Ruby code is written to handle errors, instead of checking for them.
You really don't want to be in a position of vouching for every dependent line of code in your project to get this right to ensure that someone can't run native code on your servers. It would be a hard thing to explain to your users, your customers, or your PCI auditors.
June 22, 2008 at 6:29 am
It's not necessarily a case of checking the indices, but more that you shouldn't allow unsanitized data to have any direct effect on low level (as low level as Ruby gets anyway) operations within code (unless you're running within some sort of sandbox, in which case the advisory would be even less significant).
Of course, a database entry (assuming it was put there by a third party or you weren't using validations), an erroneous response from a search/indexing library, or the like, /could/ trigger large string indices like this, so there are no hard and fast rules and if you're in a big budget production environment, upgrading is clearly a good idea.
If you were using fuzz testing (or even good unit testing) on your application, this particular part of the advisory would almost be a non issue since such you'd already be familiar with what your application does when given such crazy data.
June 22, 2008 at 7:27 am
Doubt that fuzz testing will catch these. For instance, to trip the Bignum integer overflow, you need an integer whose backing store is many hundreds of megabytes long.
June 22, 2008 at 8:57 am
Is JRuby affected, too?
June 22, 2008 at 9:26 am
Without giving a definitive answer, on the array index issue in particular, it doesn't appear so. I get a "ArgumentError: index too big" exception, rather than either a hang (as I get on my older Ruby 1.8.6) or a segfault (as some users are getting).
June 22, 2008 at 10:36 am
My suggestion that Ruby 1.8.6-p230 is incompatible with Rails was based only on the comments in Jeremy's post (including his own). I haven't upgraded or done any testing of my own as of yet to confirm this. My posting on RubyFlow should have explained this, sorry about that.
June 22, 2008 at 11:32 am
The varying results seem to indicate that perhaps a certain plugin or specific technique used by some Rails developers can cause issues on p230, but not Rails per-se (unless it's a version specific issue). Still worth keeping in mind though.
June 22, 2008 at 6:20 pm
It is pretty lame IMHO that the ruby core developers pushed out this 'security' patch that also includes breaking feature changes in a minor patch level release. This puts folks between a rock and a hard place. Either you risk it and keep running the old version, or you upgrade to p230 and break your apps with segfaults. Neither of these is a fun option. Where is the patch for 1.8.6p114 that *only* fixes the security bugs?
June 22, 2008 at 7:36 pm
@ezra you're exactly right. ruby has become mainstream, yet it seems the ruby maintainers are still stuck with a hobbyist mentality...sad. they should be more thoughtful.
June 22, 2008 at 9:36 pm
We can has a good build now please?! :)
I did a brand new Rails 2.1 scaffold and Ruby 1.8.6 patch 230 broke at the first page i tried to load. There was no specific plugin to speak of. Maybe it's an incompatibility with the operating system (Debian Etch?) or the way i linked the dependencies ...?
I'm surprised there is no update from Ruby yet.
June 22, 2008 at 9:59 pm
To be completely honest, I don't see much of a choice in this issue, and being paranoid about it is being too anal for your own good. It sucks for sure to know that evil hacker people have an easy and well documented shot at bringing your applications to their knees, but what is the alternative?
No matter what you do, chances are it will end in misery and segfaults. If you don't upgrade, it might if you're unlucky and get attacked - and if you do upgrade, it probably will.
June 23, 2008 at 2:00 am
Another thing is that it seems that the Phusion guys already managed to integrate 1.8.6p230 into Ruby Enterprise Edition. One must assume that it works with Rails (although there is one report of segfaults with Rails 1.2.6), but they haven't published anything official about which version(s) it supports.
June 23, 2008 at 2:03 am
There's a thread on ruby-talk for this topic, which may be a better place to discuss this: http://www.ruby-forum.com/topic/157034
Here's a copy of my post from that thread regarding this topic:
All versions of MRI Ruby that claim to fix the vulnerabilities are either failing with segmentation faults or change the API in ways that make it impossible to run vital libraries such as Rails 2.0.x and RSpec. These broken versions include: 1.8.5p231, 1.8.6p230, 1.8.7p22, and 1.9.0-2. Unfortunately, the source code describing some of the proposed fixes has been publicly available now for four days for crackers to write their attacks, so we're in a race with the bad guys to deliver a solution.
Is anyone working on fixing these bugs? If not, can we rally the community to get a bounty and/or code sprint going?
Is there a way to convince the Ruby maintainers to run new code against the publicly-available test suites provided by RubySpec, Rails and Rspec before they ship a new version to avoid these problems in the future?
Is there anything else that those of us which lack the necessary C expertise to fix these problems can do to help with this effort?
Thank you.
-igal
June 23, 2008 at 3:35 am
I also want answers to Andrew's question, are other Ruby distributions affected?,I hope they are not, but a definitive answer would be very nice, it will be kind of continuity planning measure
June 23, 2008 at 6:00 am
@Senthil rubinius is not affected by any of these overflows. I'd assume jruby is fine as well but haven't verified.
June 23, 2008 at 11:44 am
@Igal Koshevoy: Phusion has just released a new version of Ruby Enterprise Edition, which is based on Ruby 1.8.6-p111, with the security patches backported. This version should be compatible with all your apps.
See http://blog.phusion.nl/2008/06/23/ruby-186-p230187-broke-your-app-ruby-enterprise-edition-to-the-rescue/ for details.
June 23, 2008 at 12:03 pm
@Hongli Lai: Thanks for comment, I've replied on your blog. Here's a copy of the relevant portion of my reply for everyone else's sake:
I cannot figure out how to get a diff of the changes you’ve made between [your two recent Ruby Enterprise] releases because your download.php program makes it impossible to access old versions of your code.
Can you please publish a diff of your backport against p111 [without the Ruby Enterprise changes]?
Thank you.
June 24, 2008 at 2:50 pm
Those of us on FreeBSD are fine thanks to Stanislav, but does anyone know whether the Ruby team is planning to release a version with the security patches that runs with Rails?
June 27, 2008 at 12:09 pm
How long do we have to see this "Don't Panic" image! It feels up half of the browser screen and it requires me to scroll.
Cheers
June 27, 2008 at 12:12 pm
Dave: If you can see that image, you don't need to scroll, as new items appear on top, so if you've already read what's below it, no need to scroll :)