Hi all. Some vulnerabilities were found on Ruby, one of which allow attackers to execute arbitrary codes. These are releases to fix those problems. Also note this is the last official release of ruby 1.8.5. No support are provided for it by us any longer. Detailed information should be found at: http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities Released tarballs are available at: ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-2.tar.bz2 ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-2.tar.gz ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-2.zip ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p22.tar.bz2 ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p22.tar.gz ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p22.zip ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p230.tar.bz2 ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p230.tar.gz ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p230.zip ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.5-p231.tar.bz2 ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.5-p231.tar.gz ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.5-p231.zip And checksums: MD5(ruby-1.8.7-p22.tar.gz)= fc3ede83a98f48d8cb6de2145f680ef2 SHA256(ruby-1.8.7-p22.tar.gz)= d2e4e6a9f170066846304797d39e8f388edb06206b40c9ef5ec2d657ff22c072 SIZE(ruby-1.8.7-p22.tar.gz)= 4799242 MD5(ruby-1.8.7-p22.tar.bz2)= 2d57acee0d80531e14ec0f6826a1f9fb SHA256(ruby-1.8.7-p22.tar.bz2)= 477968408e27d067ef56f552d7fc2a9e6f5cae2d1a72f17cd838ebf5e0d30149 SIZE(ruby-1.8.7-p22.tar.bz2)= 4121532 MD5(ruby-1.8.7-p22.zip)= 978ac396582a071f8df84913f40612f1 SHA256(ruby-1.8.7-p22.zip)= eb4de293a3e8ec0d4e277a839a5018b8bcebfde06d151cea1fd5cd1ad3631c2f SIZE(ruby-1.8.7-p22.zip)= 5849764 MD5(ruby-1.8.6-p230.tar.gz)= 5e8247e39be2dc3c1a755579c340857f SHA256(ruby-1.8.6-p230.tar.gz)= 7f22b603aadc247a513ac72e479609435d7d9b6542a250db2a28a70b77cda7c9 SIZE(ruby-1.8.6-p230.tar.gz)= 4583204 MD5(ruby-1.8.6-p230.tar.bz2)= 3eceb42d4fc56398676c20a49ac7e044 SHA256(ruby-1.8.6-p230.tar.bz2)= 603708301fc3fd7ef1c47bb4a24d7799c26e28db08d69cda240adcbdbff514d7 SIZE(ruby-1.8.6-p230.tar.bz2)= 3948498 MD5(ruby-1.8.6-p230.zip)= 7a392262e2777d352bd4af197916146e SHA256(ruby-1.8.6-p230.zip)= 311d9a7e97fd8419a8056a4971e957d99dd6a986496119b40731035472e8e8dd SIZE(ruby-1.8.6-p230.zip)= 5599077 MD5(ruby-1.8.5-p231.tar.gz)= e900cf225d55414bffe878f00a85807c SHA256(ruby-1.8.5-p231.tar.gz)= 9091ee606c89ebd94b3ced9a6c1bba8e56a8e5807091c14e81798690cb7e76ca SIZE(ruby-1.8.5-p231.tar.gz)= 4519838 MD5(ruby-1.8.5-p231.tar.bz2)= 327f5aa6573787432222e96195cffd1e SHA256(ruby-1.8.5-p231.tar.bz2)= b31a8db0a3b538c28bca1c9b08a07eb55a39547fdaad00c045f073851019639c SIZE(ruby-1.8.5-p231.tar.bz2)= 3890561 MD5(ruby-1.8.5-p231.zip)= 14236e90cd419faa3c51e972485f44f6 SHA256(ruby-1.8.5-p231.zip)= 28e1b6d86720f3932a24fbebbec7fbcb474c494604a909a440689cdf9484e017 SIZE(ruby-1.8.5-p231.zip)= 5527843
on 20.06.2008 14:57
on 21.06.2008 14:48
Urabe Shyouhei wrote: > Hi all. > > Some vulnerabilities were found on Ruby, one of which allow attackers to > execute arbitrary codes. These are releases to fix those problems. > > Detailed information should be found at: > http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities Any chance to get more detailed information about the security vulnerabilities? How severe is it? Which calls, libraries are involved? Best Regards, Joachim Glauche
on 21.06.2008 14:53
On Sat, Jun 21, 2008 at 4:47 PM, Joachim Glauche <jg@connection-net.de> wrote: > vulnerabilities? > > How severe is it? Which calls, libraries are involved? check patches?
on 21.06.2008 17:32
The new 1.8.6 release does not appear to work with Rails (2.0.2 in our case). See several reports of errors or segfaults here: http://weblog.rubyonrails.com/2008/6/21/multiple-ruby-security-vulnerabilities So a large portion of the Ruby world will remain unpatched until ruby-core turns another release... :-(
on 22.06.2008 13:24
Urabe Shyouhei wrote: > Some vulnerabilities were found on Ruby, one of which allow attackers to > execute arbitrary codes. These are releases to fix those problems. > > Also note this is the last official release of ruby 1.8.5. No support > are provided for it by us any longer. > > Detailed information should be found at: > http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities "Detailed"?
on 23.06.2008 03:50
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
on 23.06.2008 04:38
When will the binaries for the latest 1.8.7 patchlevel be available for Windows users? Maybe I'm looking in the wrong place, but they aren't here: ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32. If that is the right place, then is there some reason for the delay in publishing them?
on 23.06.2008 05:31
* Igal Koshevoy (igal@pragmaticraft.com) wrote: > 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. FreeBSD backported the relevent patches to 1.8.6 p111, perhaps use those? I've certainly not had any problems with my Rails apps with it.
on 23.06.2008 06:12
Thomas Hurst wrote: > FreeBSD backported the relevent patches to 1.8.6 p111, perhaps use > those? I've certainly not had any problems with my Rails apps with it. 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? If we can create a patch against the official 1.8.6p111 source code, we can distribute that as a temporary solution until there's an official fix. That'd be great. However, does anyone know how the FreeBSD maintainers figured out what to backport and what not to? Can you or someone more familiar with FreeBSD explain how to get the diff for their patches so someone can start building a backport patch based on theirs? I found the FreeBSD page that refers to these at http://www.freshports.org/lang/ruby18/ but can't get it to give me code. For example, if I scroll down, locate the first change set, click the misleading MS Notepad icon, scroll down, click on any of the listed files, scroll down, tell it to do diff, it just returns a zero-length file. Thoughts? -igal
on 23.06.2008 11:35
In article <b4734d2c636e7e0cabf04a53be206ebc@ruby-forum.com>, Igal Koshevoy <igal@pragmaticraft.com> wrote: >Can you or someone more familiar with FreeBSD explain how to get the >diff for their patches so someone can start building a backport patch >based on theirs? I found the FreeBSD page that refers to these at >http://www.freshports.org/lang/ruby18/ but can't get it to give me code. Try this instead: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/
on 23.06.2008 12:21
Ollivier Robert wrote: > Try this instead: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/ Thanks for the assistance. That FreeBSD web site's UI sucks. Their "Get diffs" button is broken and always returns nothing. To get a diff on a file, one must click the "text" next to the revision number. FreeBSD's backported patch seems insufficient and vulnerable. I come to this conclusion because they only modified two files (sprintf.c and string.c) -- but the Ruby changelog for this fix mentions other files (e.g., array.c), and Zed Shaw identifies about a dozen files potentially involved in the fix at http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html So we still need to come up with either a backport for one of the working versions of Ruby, or a fix to one of the currently released but broken versions. I've sent email to Stas, the FreeBSD maintainer of Ruby to warn them of the potential security hole in their release and in hopes that they may join this discussion. -igal
on 23.06.2008 13:32
Guys I need some tutorial on Ruby. It seems to be very interesting package. advise what do i do so that i become an expert? am already good at MS Access, FrontPage, DreamWeaver and a bit of DotNetNuke.
on 23.06.2008 13:33
Guys I need some tutorial on Ruby. It seems to be very interesting package. advise what do i do so that i become an expert? am already good at MS Access, FrontPage, DreamWeaver and a bit of DotNetNuke.
on 23.06.2008 13:34
On Mon, 23 Jun 2008 19:20:00 +0900 Igal Koshevoy <igal@pragmaticraft.com> mentioned: > string.c) -- but the Ruby changelog for this fix mentions other files > (e.g., array.c), and Zed Shaw identifies about a dozen files potentially > involved in the fix at > http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html > You're not fully correct. All the relevant changes were in array.c and string.c sources, I've backported both. I'm not aware of other security problems in the code. I'll check the link later.
on 23.06.2008 13:41
hi Fred, You can refer to these, http://www.digitalmediaminute.com/article/1816/top-ruby-on-rails-tutorials http://www.maxkiesler.com/index.php/weblog/comments/learning_ruby_a_guide_to_online_tutorials_examples_and_downloads/ http://soylentfoo.jnewland.com/articles/2005/08/05/learning-ruby-on-rails On Mon, Jun 23, 2008 at 4:59 PM, Fred Chingota <fredchingota@yahoo.com> wrote: > -- -- Thanks and Regards Saurabh Purnaye +91-9922907342 skype: sorab_pune yahoo & gtalk: saurabh.purnaye msn: psaurabh@live.com
on 23.06.2008 13:41
On Mon, 23 Jun 2008 19:20:00 +0900 Igal Koshevoy <igal@pragmaticraft.com> mentioned: > > Thanks for the assistance. That FreeBSD web site's UI sucks. Their "Get > diffs" button is broken and always returns nothing. To get a diff on a > file, one must click the "text" next to the revision number. > You rocks! The file you trying to get has only a single revision, and you obviously requesting the diff between the 1.1 and 1.1 version - that's empty of course. It's better to look at the text fields before pressing the button and claiming it doesn't work - isn't it?
on 23.06.2008 13:43
On Mon, 23 Jun 2008 20:30:10 +0900 Fred Chingota <fredchingota@yahoo.com> mentioned: > Guys > > I need some tutorial on Ruby. It seems to be very > interesting package. advise what do i do so that i > become an expert? am already good at MS Access, > FrontPage, DreamWeaver and a bit of DotNetNuke. > Try to get one of best ruby books: The Ruby Way, Pragmatic Programmers' "The Ruby Language" and other. There're also a lot of tutorials on the web available.
on 23.06.2008 14:14
Hi guys. Igal invited me to join this discussion. We at Phusion have just released Ruby Enterprise Edition (pardon the name ;-) 1.8.6-20080623, which is based on Ruby 1.8.6-p111, and includes the relevant security patches backported. Details here: http://tinyurl.com/5bmgtp The relevant patch is available at: http://tinyurl.com/5b493c It's based on the FreeBSD patch set. Thanks FreeBSD. :)
on 23.06.2008 14:24
Stanislav Sedov wrote: > All the relevant changes were in array.cand string.c sources, I've backported both. According to http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/ you only patched sprintf.c and string.c but not array.c, which was specifically mentioned in the changelog as having a vulnerability. Furthermore, Zed Shaw mentioned many other files that seemed affected by security fixes at http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html > Can you prove that the port is still vulnerable? No, I only know C well enough to tell that your patch didn't seem to match up with what was described elsewhere. > It's better to look at the text fields before pressing > the button and claiming it doesn't work - isn't it? I did. The text fields read "1.1" and "1.2". These fields are wrong, the first should be something like "1.0" or "initial", and the second should be "1.1". Setting the first field to "1.0" fails because this is a forbidden field in your version control system, and version "1.2" doesn't exist. I see no way to get a diff by clicking the "Get diffs" button, therefore it doesn't work. Either don't show the button for newly imported files, or provide sensible behavior, like displaying the initial version so that the user doesn't get confused. -igal
on 23.06.2008 14:36
Hongli Lai wrote: > The relevant patch is available at: http://tinyurl.com/5b493c Thanks for the quick response and for publishing the patch. However, are you sure you got all the files? Your patch is the most comprehensive I've seen, but isn't it missing the fixes to things like eval.c, file.c and bignum.c? > It's based on the FreeBSD patch set. As far as I can tell, you and Stas at FreeBSD were patching different files. E.g., you patched io.c, while he didn't seem to. However, I feel like I don't understand how to use the FreeBSD website because I can only see find his patches to string.c and sprintf.c, but none of the others, so if someone can explain how to find the rest, that'd be great. -igal PS: And many thanks for the awesome work on Phusion Passenger and Ruby EE.
on 23.06.2008 15:39
On Mon, 23 Jun 2008 21:23:01 +0900 Igal Koshevoy <igal@pragmaticraft.com> mentioned: > Stanislav Sedov wrote: > > All the relevant changes were in array.cand string.c sources, I've backported both. > According to > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/ you only > patched sprintf.c and string.c but not array.c, which was specifically > mentioned in the changelog as having a vulnerability. Furthermore, Zed > Shaw mentioned many other files that seemed affected by security fixes > at http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html All the files you see at this dir are applied to ruby during packages building and port install. The fresh ones are array.c and string.c. sprintf.c patch is required for correct string.c operation as it adds the required function backported from 1.9. The file in question is availble at http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/patch-array.c?rev=1.1;content-type=text%2Fplain > I did. The text fields read "1.1" and "1.2". These fields are wrong, the > first should be something like "1.0" or "initial", and the second should > be "1.1". Setting the first field to "1.0" fails because this is a > forbidden field in your version control system, and version "1.2" > doesn't exist. I see no way to get a diff by clicking the "Get diffs" > button, therefore it doesn't work. Either don't show the button for > newly imported files, or provide sensible behavior, like displaying the > initial version so that the user doesn't get confused. > The GUI only reflects what CVS has. The file is question is of 1.1 revision (first in CVS) and you obvously can't get a diff between nothing and first. CVS tracks only files, not the entire repository.
on 23.06.2008 15:40
Igal Koshevoy wrote: > Thanks for the quick response and for publishing the patch. However, are > you sure you got all the files? Your patch is the most comprehensive > I've seen, but isn't it missing the fixes to things like eval.c, file.c > and bignum.c? Now that you mention it, Keita Yamaguchi sent me an eval.c security patch a while back. Upon closer inspection it seems that this patch is not included in the FreeBSD patch set, and neither is bignum.c. I've made an updated patch set: http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt Was file.c vulnerable? I see a number of Windows fixes for file.c, but it's not immediately clear whether the changes also include security fixes. > As far as I can tell, you and Stas at FreeBSD were patching different > files. E.g., you patched io.c, while he didn't seem to. However, I feel > like I don't understand how to use the FreeBSD website because I can > only see find his patches to string.c and sprintf.c, but none of the > others, so if someone can explain how to find the rest, that'd be great. I grabbed the patches from the FreeBSD ports tree. Here's a tarball with all the patches in FreeBSD's ruby18 port: http://blog.phusion.nl/assets/freebsd-ruby18-patches.tar.gz I excluded some irrelevant (i.e. FreeBSD-specific) patches from my patch set. > PS: And many thanks for the awesome work on Phusion Passenger and Ruby > EE. Thanks. :)
on 23.06.2008 16:00
On Mon, 23 Jun 2008 22:38:40 +0900 Hongli Lai <hongli@phusion.nl> mentioned: > Now that you mention it, Keita Yamaguchi sent me an eval.c security > patch a while back. Upon closer inspection it seems that this patch is > not included in the FreeBSD patch set, and neither is bignum.c. eval.c doesn't pose a security fix as safe_level isn't secure by design. It's just a couple of checks around some functions, nothing more. The patch adds another one in eval.c bignum.c fixes an integer overflow at some operations - this can't cause security problems as I could see. It worth applying, though, thanks for info. webrick patches isn't relevant to freebsd in any way, since it fixes a well known security holes in webrick on windows. These holes were worked out a while ago (in fact several month or so).
on 23.06.2008 16:28
Stanislav Sedov wrote:
> ...
Thanks for the updates.
I also figured out what I was missing with the patch listing at the
FreeBSD site. When I was hitting page down to get to the files, I ended
up only looking at the last four files and jumped to the incorrect
conclusion that the listing was sorted by chronological order, and thus
thought that you only patched two files based on the dates listed.
However, the listing is actually alpha sorted and I can now see that you
patched other files. Sorry for the silly mistake, it's been a long
night. :)
-igal
on 23.06.2008 16:35
So is my patch set now complete, or is there still something missing? I took a look at eval.c but the changes don't look like security fixes to me, at first glance.
on 23.06.2008 16:38
On Mon, 23 Jun 2008 23:27:08 +0900 Igal Koshevoy <igal@pragmaticraft.com> mentioned: Sorry for the silly mistake, it's been a long N/p, rest a bit:-)
on 23.06.2008 16:39
Hongli Lai wrote: > Now that you mention it, Keita Yamaguchi sent me an eval.c security > patch a while back. Upon closer inspection it seems that this patch is > not included in the FreeBSD patch set, and neither is bignum.c. 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've made an updated patch set: > http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt Excellent, thank you. > Was file.c vulnerable? I see a number of Windows fixes for file.c, but > it's not immediately clear whether the changes also include security > fixes. If I recall correctly, a blog post (which I can't find at the moment) suggested that some of this addressed general buffer overflow issues and Windows-specific traversal attacks. So these may be worth considering. -igal
on 23.06.2008 17:58
* Igal Koshevoy (igal@pragmaticraft.com) wrote: > Thomas Hurst wrote: > > FreeBSD backported the relevent patches to 1.8.6 p111, perhaps use > > those? I've certainly not had any problems with my Rails apps with it. > > 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?
on 23.06.2008 18:20
Thomas Hurst wrote: > 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. >> 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? 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
on 23.06.2008 18:27
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 :p 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
on 23.06.2008 22:45
Does anybody have access to the CVE details? Selecting patches based on the CVEs should be easier than guessing based on patches.
on 24.06.2008 00:11
Igal Koshevoy wrote: > 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.
on 24.06.2008 01:29
Igal Koshevoy wrote: > 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
on 24.06.2008 03:42
Igal Koshevoy wrote: > - Phusion blog > > 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. :)
on 24.06.2008 05:00
M. Edward (Ed) Borasky wrote: >> - RubyInside blog >> 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. :) How about openSUSE? I just moved the Linux side of my dual-booted laptop to openSUSE 11.
on 24.06.2008 09:59
Phil Ross wrote: > 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
on 24.06.2008 10:00
M. Edward (Ed) Borasky wrote: > 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
on 24.06.2008 10:31
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. Robert Thau wrote: > 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
on 24.06.2008 11:13
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. > Hongli Lai wrote: >> Now that you mention it, Keita Yamaguchi sent me an eval.c security >> patch a while back. Upon closer inspection it seems that this patch is >> not included in the FreeBSD patch set, and neither is bignum.c. > 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've made an updated patch set: >> http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt 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
on 24.06.2008 14:57
Igal Koshevoy wrote: > 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
on 24.06.2008 15:58
Phil Ross wrote: > 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
on 24.06.2008 16:31
Igal Koshevoy wrote: > > 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
on 24.06.2008 16:49
Igal Koshevoy wrote: > > 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
on 24.06.2008 17:35
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.
on 25.06.2008 01:43
Robert Thau wrote: > 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
on 25.06.2008 02:48
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
on 25.06.2008 03:08
Dominic Sisneros wrote: > 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
on 25.06.2008 22:39
Just wanted to say that we all appreciate those fixes you guys have been able to hack together so quickly, and thanks for your efforts in getting through to the Ruby maintainers. There are a lot of folks out here looking to re-stabilize their apps. Cheers, -Jason
on 26.06.2008 11:35
> How do we convince them to respond back to the community in a > timely manner about stuff like this? Please don't speak for everyone. I personally rather not want to be grouped to people like Mr. Shaw that use every opportunity to lash out at something they dislike. Different use cases will remain different - for me these issues are simply not important at all, for example. And I don't want to give the ruby devs the feeling that the "community" as such is an angry mob. I'd rather see more effort to improve the docu of ruby, API docs as such are boring and not that helpful, but there are also many examples of people who went to great length to make their docu usable. We are individuals with individual opinions, it is only polite to speak primarily merely for yourself, not for, or in the name of, others. I however want to say one thing - the original team (or dev) that reported the security problem(s) should have either described exactly what the problem was (including giving patches), or simply shut up. This whole issue is blown out of proportion by being repeated over and over again. The way to "handle" security-related problems seems inherently unfair to people who don't have the time to dig for the patches or find the problem. And some people did invest their time to find out which patches were applied, which changes were done etc... etc... I still dont care about the security-related problems, but to be honest this would be the only way to handle security related problems in a fair manner for everyone - by telling what exactly was the problem. I am quite sure that professional crackers will collect all information anyway, can glance at patches and changes, and they will have more knowledge and resources to make any real use of this anyway, no matter if a problem is kept secret or not. So I do not understand at all why the original reporter did not reveal the info as well. There is no valid use case that makes sense for keeping things secret, but loudly proclaiming that there are problems at the same time.
on 26.06.2008 15:40
Marc Heiler wrote: > for me these issues are simply not important at all [...] I still dont care about the security-related problems > That's nice. I have companies that depend on me to deliver applications on a platform they can rely on, so I do care. >> How do we convince them to respond back to the community in a >> timely manner about stuff like this? >> > Please don't speak for everyone. I personally rather not want to be > grouped to people like Mr. Shaw that use every opportunity to lash out > at something they dislike. > What's this have to do with Zed? Six days ago we were told by the maintainers that, "Multiple vulnerabilities in Ruby may lead to a denial of service (DoS) condition or allow execution of arbitrary code." They still haven't shipped a working fix or said a single word to us regarding this topic. I've personally posted on every list and every bug tracker they have, so they couldn't have missed it, and still silence. I'm disappointed. In contrast, I was really impressed by how professionally Stanislav, Hongli and Robert handled the situation and how quickly they delivered working solutions. > I do not understand at all why the original reporter did not reveal the info as well. Because that's not the reporter's responsibility. Drew Yao reported the bug to the maintainers, and Dominique Brezinski claims that he reported the same problems two years ago but was ignored. Taking action on reports and dealing with public relations is the responsibility of the official maintainers, not the reporter. -igal
on 26.06.2008 15:46
Igal Koshevoy wrote: >> grouped to people like Mr. Shaw that use every opportunity to lash out > In contrast, I was really impressed by how professionally Stanislav, > > -igal > > http://www.retrospectives.com/pages/retroPrimeDirective.html
on 26.06.2008 16:57
M. Edward (Ed) Borasky wrote:
> http://www.retrospectives.com/pages/retroPrimeDirective.html
Thanks for the reminder.
To put my earlier comments in perspective. I really enjoy working with
Ruby, work hard to promote it, publish mult