Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix)

[Thomas Hurst]

Thanks for the information, Thomas. Could you or someone else with
FreeBSD, as a favor, run the Rails and RSpec test suites with this new
version to determine how well these modified versions work?

rspec runs fine, though I needed to modify a regexp to work with my
Oniguruma patched install (an option of the FreeBSD port).

The Rails test suite mostly works; few failures wrt timezone support,
and a couple of odd ActiveRecord ones with sanitizing LIMIT
(add_limit_offset_should_sanitize_sql_injection_for_limit...), but
these could also be Oniguruma related.

However, does anyone know how the FreeBSD maintainers figured out what
to backport and what not to?

Well, you just follow the SVN history and cherry-pick the relevent
commits?

 

[Igal Koshevoy]

rspec runs fine, though I needed to modify a regexp to work with my
Oniguruma patched install (an option of the FreeBSD port).

The Rails test suite mostly works; few failures wrt timezone support,
and a couple of odd ActiveRecord ones with sanitizing LIMIT
(add_limit_offset_should_sanitize_sql_injection_for_limit...), but
these could also be Oniguruma related.

Thanks for the update.

Well, you just follow the SVN history and cherry-pick the relevent
commits?

The intent of my question was to get information so we could evaluate
their selection process, and thus determine whether that process would
effectively included the applicable changes.

We're currently depending on the assumption that one person cherry
picked all the right commits, and we've already identified at least one
potential error from that process. I'm sure that Stanislav Sedov did a
fine job, but I'd like to see someone else do a second, independent pass
through the history to double-check. I wouldn't trust myself to do
something this important on my own in a single pass, so this is in no
way a criticism.

Would anyone like to volunteer?

-igal

 

[Igal Koshevoy]

It's great watching this come together. Thanks to Stanislav and Hongli's
code, and assistance from the rest of you, I think we're getting close
to having a reasonable unofficial patch ready.

I've contacted the following groups and asked them to join the
discussion, and you've already seen some of them join in:
- Ruby Core
- Ruby on Rails blog
- Ruby on Rails core
- RubyInside blog
- Phusion blog
- FreeBSD Ruby maintainer
- Debian Ruby maintainers
- Fedora maintainers
- Portland Ruby Brigade

Are there any other persons or groups that can lend a hand that should
be contacted?

If you can think anyone, please ask them to join the ruby-talk mailing
list or use the online thread at http://www.ruby-forum.com/topic/157034

Thanks!

-igal

 

[Hongli Lai]

Does anybody have access to the CVE details? Selecting patches based on
the CVEs should be easier than guessing based on patches.

 

[Philip Ross]

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.

It looks like a fix for the segmentation faults was committed on 21 June
(revision 17530 in the ruby_1_8 branch):

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=17530

Note that this change is only in the ruby_1_8 branch. It hasn't been
applied to the separate branches for 1.8.5, 1.8.6 and 1.8.7.

I've applied the change to 1.8.6-p230 and I'm no longer getting the
segmentation faults in my Rails app. I haven't tested the change with
1.8.5 or 1.8.7.

The patch I applied to 1.8.6-p230 is available at:

http://files.philross.co.uk/ruby/ruby-1.8.6-p230-fix.patch

This just consists of revision 17530 with the change to ChangeLog
adjusted to apply cleanly.

 

[Robert Thau]

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.

FWIW, I managed to get 1.8.6p230 all the way through a Rails 2.0
app test suite without segfaults or glibc "corrupted memory"
complaints with the patch here:

http://dev.smartleaf.com/misc/p230_fixit_patch.txt

This reverts changeset 17222 from the ruby_1_8_6 branch of the
main svn repository, which doesn't *look* security-related, at
least at first blush (though it may be a failed backport from
another line of development).

As always, your milage may vary --- but I'm hoping this helps
someone with more detailed knowledge of MRI innards figure out
what's going on.

Robert Thau
rst AT {ai,alum}.mit.edu

 

[M. Edward (Ed) Borasky]

It's great watching this come together. Thanks to Stanislav and Hongli's
code, and assistance from the rest of you, I think we're getting close
to having a reasonable unofficial patch ready.

I've contacted the following groups and asked them to join the
discussion, and you've already seen some of them join in:
- Ruby Core
- Ruby on Rails blog
- Ruby on Rails core
- RubyInside blog
- Phusion blog
- FreeBSD Ruby maintainer
- Debian Ruby maintainers
- Fedora maintainers
- Portland Ruby Brigade

Are there any other persons or groups that can lend a hand that should
be contacted?

If you can think anyone, please ask them to join the ruby-talk mailing
list or use the online thread at http://www.ruby-forum.com/topic/157034

Thanks!

-igal

I've posted some links to the Gentoo Linux Bugzilla
(https://bugs.gentoo.org/show_bug.cgi?id=225465). I think they'll be the
first distro to actually send out a fix.

 

[M. Edward (Ed) Borasky]

I've posted some links to the Gentoo Linux Bugzilla
(https://bugs.gentoo.org/show_bug.cgi?id=225465). I think they'll be the
first distro to actually send out a fix.

How about openSUSE? I just moved the Linux side of my dual-booted laptop
to openSUSE 11.

 

[Igal Koshevoy]

It looks like a fix for the segmentation faults was committed on 21 June
(revision 17530 in the ruby_1_8 branch):

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=17530

Note that this change is only in the ruby_1_8 branch. It hasn't been
applied to the separate branches for 1.8.5, 1.8.6 and 1.8.7.

I've applied the change to 1.8.6-p230 and I'm no longer getting the
segmentation faults in my Rails app. I haven't tested the change with
1.8.5 or 1.8.7.

The patch I applied to 1.8.6-p230 is available at:

http://files.philross.co.uk/ruby/ruby-1.8.6-p230-fix.patch

This just consists of revision 17530 with the change to ChangeLog
adjusted to apply cleanly.

Phil, thanks for posting the link and patch.

Unfortunately, this patched version fails with segmentation faults when
applied to 1.8.6-p230 and run against RSpec 1.1.4's test suite:

lib/spec/example/example_group_methods.rb:384: [BUG] Segmentation
fault

The 1.8.6-p111 version doesn't segfault.

Therefore, please consider another solution.

-igal

 

[Igal Koshevoy]

I've posted some links to the Gentoo Linux Bugzilla
(https://bugs.gentoo.org/show_bug.cgi?id=225465).

Thanks for contacting them, seems like there's some activity over there
as well. I hope they join in the discussion here too.

-igal

 

[Igal Koshevoy]

We may have a winner!

Can someone with a good understanding of C please audit the patch below?
It seems to make 1.8.6p230 work correctly. It reverts Matz's "should
copy cref as well" patch, and I'm not clear on what that was intended to
do.

FWIW, I managed to get 1.8.6p230 all the way through a Rails 2.0
app test suite without segfaults or glibc "corrupted memory"
complaints with the patch here:

http://dev.smartleaf.com/misc/p230_fixit_patch.txt

This reverts changeset 17222 from the ruby_1_8_6 branch of the
main svn repository, which doesn't *look* security-related, at
least at first blush (though it may be a failed backport from
another line of development).

I ran this against the Rails 2.0 and RSpec 1.1.4 test
suites, no seg faults, no glibc errs, and the same set of tests
succeeded/passed between this patched version and the stock p111. It ran
fine against automateit 0.80607 and the various Rails apps I tried. This
is good.

As always, your milage may vary --- but I'm hoping this helps
someone with more detailed knowledge of MRI innards figure out
what's going on.

Same here. Thanks much for posting this!

Does anyone know how to contact the smartleaf folks and get them into
this discussion?

-igal

 

[Igal Koshevoy]

We have another potential winning solution!

Can someone please review this patch and provide advice of the pros/cons
of using this solution versus the Smartleaf patch described in the
previous email? In a nutshell, Stanislav and Hongli's solution is a
backport of fixes to p111, while the Smartleaf solution fixes the
segfaults in p230.

Also, can anyone get through to the official Ruby maintainers? It's
awesome that we can create two unofficial patches on short notice like
this, but I'd really like to have them involved in this.

The analysis Zed Shaw described in his blog was based on reviewing all
the changes made this month. Although this is more time consuming, it
also seems like the most methodical way of making sure we catch all the
relevant changes.

I ran this against the Rails 2.0 and RSpec 1.1.4 test
suites, no seg faults, no glibc errs, and the same set of tests
succeeded/passed between this patched version and the stock p111.
Excellent.

I also ran this and the smartleaf version against RubySpecs, and got
identical results to those of a stock p111. Excellent.

As far as I can tell, both of these patches provide a working version of
MRI Ruby. Stanislav and Hongli's p111 backport relies on them having
correctly cherry-picked the right fixes. Smartleaf's p230 fix relies on
the rest of that Ruby version to be correct, and I have some concerns
about other lurking bugs if they shipped a version with such an obvious
flaw.

How do we choose between these?

-igal

 

[Phil Ross]

It looks like a fix for the segmentation faults was committed on 21 June
(revision 17530 in the ruby_1_8 branch):

Phil, thanks for posting the link and patch.

Unfortunately, this patched version fails with segmentation faults when
applied to 1.8.6-p230 and run against RSpec 1.1.4's test suite:

lib/spec/example/example_group_methods.rb:384: [BUG] Segmentation
fault

The 1.8.6-p111 version doesn't segfault.

Igal,

Thanks for testing this.

It would appear that there are (at least) two separate areas where
segmentation faults are being raised. Revision 17530 fixes segmentation
faults with string concatenation that was causing my Rails applications
to crash:

http://www.ruby-forum.com/topic/157250

I guess that the root cause must be revision 17222 in the ruby_1_8_6
branch that the smartleaf patch reverts.

Regards,

Phil

 

[Igal Koshevoy]

It would appear that there are (at least) two separate areas where
segmentation faults are being raised. Revision 17530 fixes segmentation
faults with string concatenation that was causing my Rails applications
to crash:

http://www.ruby-forum.com/topic/157250

I guess that the root cause must be revision 17222 in the ruby_1_8_6
branch that the smartleaf patch reverts.

Ah, thanks for the update.

So before we discard the 17222 patch too casually ... can anyone explain
what Matz was trying to do there? He clearly went through a fair amount
of effort to try to copy those crefs, but why? And does anything else
depend on that change?

-igal

 

[Robert Thau]

As far as I can tell, both of these patches provide a working version of
MRI Ruby. Stanislav and Hongli's p111 backport relies on them having
correctly cherry-picked the right fixes. Smartleaf's p230 fix relies on
the rest of that Ruby version to be correct, and I have some concerns
about other lurking bugs if they shipped a version with such an obvious
flaw.

How do we choose between these?

Well, if we want the Japanese team to be more rigorous in applying test
suites in testing their stuff... we've got the test suites too. That
said, coverage is probably less than perfect, and the silence is
somewhat troublesome to me too.

(BTW, in an earlier note, you asked for someone with C expertise to
audit my p230_fixit_patch.txt. Well, it should be fairly easy to verify
that it reverts class.c to an earlier --- and apparently less broken ---
state; it's quite literally the output of "svn diff". Figuring out what
went wrong with the change it reverts is more difficult. It requires
not
only knowledge of C, but also knowledge of the macros and data
structures
of pre-1.9 MRI. And while I'm pretty good with C, I think, I'm not
nearly
so good with MRI internals. I found the problem not by auditing the
code,
but by doing a simple bisection search of the ruby_1_8_6 branch of the
main svn repository, looking for the first revision that blew up
"rake test").

Robert Thau
rst AT {alum,ai}.mit.edu

 

[Robert Thau]

So before we discard the 17222 patch too casually ... can anyone explain
what Matz was trying to do there? He clearly went through a fair amount
of effort to try to copy those crefs, but why? And does anything else
depend on that change?

Well, as noted earlier, really understanding this code requires
a fairly deep grounding in the internal data structures of MRI
1.8, which I haven't got.

But, for what little it's worth...

The code affected by the 17222 patch seems to mostly have to do
with the internal implementation details of "initialize_copy"
methods on Module and Class, and the cloning of an object's
singleton class when the object itself is cloned. The newer,
post-17222 versions seem to copy more... or try to. More,
perhaps, if I've got the time to investigate the details of
MRI 1.8 representations of method tables...

Robert Thau
rst AT {ai,alum}.mit.edu

 

[ChessMess]

Any idea when the Windows one-click installer will be updated to Ruby
1.8.7? The question was asked earlier in the thread but no one
responded to it.

 

[Igal Koshevoy]

Well, if we want the Japanese team to be more rigorous in applying test
suites in testing their stuff... we've got the test suites too.

People have reported that the current versions are broken on every
imaginable Ruby-related site and list for the last four days, so we as
users have done our part in pointing out the problem.

What can we do to lobby the Ruby maintainers to prevent a repeat of this
in the future? How do we get a "red telephone" or something so we can
contact them about critical errors? How do we convince them to respond
back to the community in a timely manner about stuff like this? And how
do we convince them to at least run the RubySpec, Rails and RSpec test
suites before shipping an official version to avoid such a problem in
the future?

really understanding this code requires
a fairly deep grounding in the internal data structures of MRI

Unfortunately, I don't have the expertise to make sense of that code and
can only recognize that something is obviously wrong and try to contact
people that may be able to do something. If ruby-talk and ruby-core
aren't the right places, where do we find someone with this expertise?

the silence is somewhat troublesome to me too.

I've contacted other lists and blogs I mentioned earlier, sent out a
broadcast to ruby-core, sent emails, submitted a RubyForge ticket, and
even tried the #ruby IRC channel. I don't know what else I can do at
this point.

The maintainers published the code for the security patches on the 18th,
thus giving crackers almost a week head start in finding an exploit in
older versions. They then shipped broken releases on the 20th, making it
impossible for anyone to upgrade to an official version. And we haven't
heard anything since. What's going on?

How do we get a hold of the official maintainers?

-igal

 

[Dominic Sisneros]

Maybe you should try posting a issue on the new redmine bug tracker
they have set up for ruby
http://redmine.ruby-lang.org/projects/show/ruby-18

 

[Igal Koshevoy]

Maybe you should try posting a issue on the new redmine bug tracker
they have set up for ruby
http://redmine.ruby-lang.org/projects/show/ruby-18

I've added a ticket on RedMine and it sent out a broadcast to ruby-dev.

Thank you for the suggestion, Dominic.

-igal