Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news.

Two Security Vulnerabilities Force 3 New Releases of MRI Ruby 1.8.7, 1.9.1, and 1.9.2

By Peter Cooper / February 19, 2011

It's been a dies horribilis for MRI Ruby today with two new security vulnerabilities forcing the release of 3 new recommended production versions of the de facto official Ruby interpreter. The first, a vulnerability in FileUtils.remove_entry_secure affects both 1.8 and 1.9 branches, while the second, a $SAFE mode vulnerability, affects only 1.8.

The FileUtils Vulnerability (1.8 and 1.9)

Urabe Shyouhei of the Ruby core team has announced that FileUtils is vulnerable to symlink race attacks and he's not talking about hate crimes. Ruby versions including and prior to Ruby 1.8.6p420, Ruby 1.8.7p330, Ruby 1.9.1p430 and Ruby 1.9.2p136 are affected so you're almost guaranteed to be affected.

The problem is FileUtils#remove_entry_secure, a method that was meant to be more secure than its sibling FileUtils#remove_entry. What the remove_entry* methods do is to 'remove' an entry in the local file system. The problem, though, is that remove_entry_secure's security wasn't quite good enough and it could be used by local users to delete arbitrary files and directories. Not a great feature.

The $SAFE Vulnerability (1.8 only)

Ruby's "safe levels" provide a way for you to make the Ruby interpreter more "paranoid" about operations it can perform and the data it can process. There are five levels and they progressively lock down what Ruby will accept - particularly useful if it's necessary to consider all data to be tainted, for example.

This recent vulnerability plays on the fact that the Exception class can both accept and return a string. The bad part is that Exception wasn't respecting the safe level in terms of keeping the string tainted. Urabe Shyouhei provides this example:

$secret_path = "foo"

proc do
    $SAFE = 4
    Exception.new($secret_path).to_s
    $secret_path.replace("/etc/passwd")
end.call

open($secret_path) do
  # do the dirty here
end

Thankfully, it only affects Ruby 1.8 (not Ruby 1.9) in the shape of Ruby 1.8.6p420 and earlier and Ruby 1.8.7p330 and earlier. The downside? That covers most Ruby 1.8 installs out there, including the default one with OS X. Get upgrading.

The Solution - New Releases of Ruby

Undoubtedly you have your own ways and means of doing upgrades (using RVM, for example) but Urabe has provided links to the latest builds on the official MRI Ruby site if you want them. Repeated here:

Ruby 1.8.7-p334: http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p334.tar.gz
Ruby 1.9.1-p431: http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p431.tar.gz
Ruby 1.9.2-p180: http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p180.tar.gz

Last but not least, if you've been wondering why Ruby Inside hasn't updated for two weeks, I have some explaining to do and.. it'll be in a post of its own very soon ;-) Meanwhile, check out RubyFlow's snazzy new design!

Comments

  1. Pingback: Tweets that mention Two Security Vulnerabilities Force 3 New Releases of MRI Ruby 1.8.7, 1.9.1, and 1.9.2 -- Topsy.com

  2. postmodern says:

    RVM users:

    $ rvm upgrade ruby-1.8.7-p334 ruby-1.8.7-p330
    $ rvm upgrade ruby-1.9.2-p180 ruby-1.9.2-p136

  3. Matthew Jacobs says:

    Is there a good way to upgrade my ubuntu 10.04 ruby versions
    without reinstalling them from source?

    (I like my package installs)

  4. werter says:

    another one in rails

    http://www.securityfocus.com/bid/46423/info

  5. Jérémie says:

    @postmodern I would suggest this way:

    rvm upgrade 1.9.2-p136 1.9.2-p180

Other Posts to Enjoy

Twitter Mentions