Want to stay on top? Ruby Weekly is a once-weekly e-mail newsletter covering the latest Ruby and Rails news.
     Feed Icon

June 2008 Ruby Security Advisory: A Summary

By Peter Cooper / June 22, 2008

dontpanic.jpg
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.

Comments

  1. Thomas H. Ptacek says:

    I'm not sure you should be citing *** here. Much of his explanation appears to be wrong.

  2. 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.

  3. Peter Cooper says:

    I still stand by it, but I'll update the post to share your concerns.

  4. Thomas H. Ptacek says:

    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.

  5. Peter Cooper says:

    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.

  6. Thomas H. Ptacek says:

    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.

  7. Andrew says:

    Is JRuby affected, too?

  8. Peter Cooper says:

    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).

  9. Mike Breen (hardbap) says:

    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.

  10. Peter Cooper says:

    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.

  11. Ezra says:

    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?

  12. J B says:

    @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.

  13. aimee.mychores.co.uk says:

    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.

  14. Robin Kaarsgaard says:

    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.

  15. Robin Kaarsgaard says:

    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.

  16. Igal Koshevoy says:

    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

  17. Senthil Nayagam says:

    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

  18. Ezra says:

    @Senthil rubinius is not affected by any of these overflows. I'd assume jruby is fine as well but haven't verified.

  19. Hongli Lai says:

    @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.

  20. Igal Koshevoy says:

    @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.

  21. zerohalo says:

    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?

  22. Dave says:

    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

  23. Peter Cooper says:

    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 :)

Other Posts to Enjoy

Twitter Mentions