Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Drew Yao of Apple Product Security reported multiple vulnerabilities in Ruby. All versions in our tree are affected. 1) Integer overflows in rb_str_buf_append() 2) Integer overflows in rb_ary_store() 3) Integer overflows in rb_ary_splice() 4) Unsafe use of alloca in rb_str_format() leads to memory corruption
I will attach patches as soon as upstream confirmed them.
Created an attachment (id=156407) [details] ruby-1.8.6-CVE-2008-2662+3+4.patch Upstream provided patches, I had to mangle whitespace and hope that did not break anything.
Sorry, the previous filename was misleading. Actually, CVEs were assigned as follows: CVE-2008-2662 - ruby 1.9 CVE-2008-2663 - ruby 1.8 CVE-2008-2664 - issue (4)
I've just applied this patch to a local test version and will be using it to run my services in the next few days. I'll try to do a bit more testing in the weekend as well. Was there any word as to how this applies to ruby 1.8.7? We have a rc version of that in the tree and a pending version bump as well.
Adding Caleb since he bumped ruby 1.8.7 last Tuesday.
(In reply to comment #4) > Was there any word as to how this applies to ruby 1.8.7? We have a rc version > of that in the tree and a pending version bump as well. All of these also affect 1.8.7, and patches should apply there. Hans, can you add ebuilds to this bug so we can do prestable testing, since the issue will go public sometime this week.
Created an attachment (id=157467) [details] ruby-1.8.6_p114-r1.ebuild
Created an attachment (id=157469) [details] ruby-1.8.7-r1.ebuild
Here are updated ebuilds that work with the patch already included in the bug. Note that only the ruby-1.8.6_p114-r1 ebuild will be a stable candidate. ruby-1.8.7 is currently package.masked in the tree pending testing and I've included it just so that we won't forget later and re-open the security issue. Right now I'm satisfied that the patch applies and compiles. Caleb, perhaps you can do further testing on this?
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug. Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release s390 sh sparc x86" CC'ing current Liaisons: alpha : yoswink amd64 : welp hppa : jer ppc : dertobi123 ppc64 : corsair release : pva sparc : fmccor x86 : opfer
[.....andmanymoredots] Finished in 208.084053 seconds. 1665 tests, 16968 assertions, 0 failures, 0 errors OK for HPPA. :)
1.8.6_p114-r1 looks good on ppc64
1.8.6 series good to go on x86.
1.8.6_p114-r1 looks good on sparc.
Good to go on amd64! Rawr!
ack, somehow I've completely this this bug until now.
Note the version numbers: etailed 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
As noted by caleb, this issue is now public. Ruby used a different patch, and the one tested by us seems to not fix the issues completely. Please note that the CVE identifiers as noted in this bug are also messed up, and I hope the Security team can resolve this shortly. Until then, we need to either backport their fixes to our 1.8.6 release or bump to their latest release.
So far from what I've seen, 1.8.6_p230 has broken most Rails apps.
You might want to verify that the fixes actually work properly and/or talk to upstream again before requesting stabilization, I just got some notice about a #ruby-lang discussion, which apparently was about the patch not fixing all issues properly. Sadly I don't have any details or log excerpts, so just consider this a heads-up. It could also be possible that someone simply confused the in-released-version fix with the previous fix (as mentioned by rbu), but well, better safe than sorry.
The link in the url lists <1.9.0-2 being affected and the additional CVEs CVE-2008-2725, CVE-2008-2726 plus, a bit lower, CVE-2008-1891 (WEBrick vulnerability). Shouldn't the severity be raised, given that, from the mentioned DoS to arbitrary code execution, it is to assume that the latter may be triggered remotely?!
Last word I heard (comments from a local Rubyist attached) all of the patched versions from upstream break Rails. So the call is out for C programmers, which, sadly, I am not. :( http://groups.google.com/group/pdxruby/browse_thread/thread/85e18ef452fa1c7a?hl=en#
*** Bug 229041 has been marked as a duplicate of this bug. ***
*** Bug 229053 has been marked as a duplicate of this bug. ***
Hi Today it is official: http://www.matasano.com/log/1070/updates-on-drew-yaos-terrible-ruby-vulnerabilities/ Can one help in testing? Best Zeno
ruby team, can you point out a resource that documents the rails bug that we can follow?
Sorry, I missed the link pointed out by Edward Borasky. Is there any official statement by the ruby upstream then?
Reportedly, this also fixes bug 219085 (CVE-2008-1891).
Here's another link for the discussion of this issue. http://www.ruby-forum.com/topic/157034
It seems to me that the smartest thing to do is to follow upstream, rather than trying to gather a bunch of patches ourselves without a deeper understanding of the issues. As for the rails issues, I've just tried running ruby-1.8.6_p230 on two of my major rails projects, and both crash within seconds on starting the test suite: *** glibc detected *** /usr/bin/ruby18: double free or corruption (out): 0x0000000000c3ca30 *** ======= Backtrace: ========= /lib/libc.so.6[0x2b31cb3ddaad] /lib/libc.so.6(cfree+0x76)[0x2b31cb3df796] /usr/lib64/libruby18.so.1.8[0x2b31cb0a7f34] /usr/lib64/libruby18.so.1.8(ruby_xmalloc+0x7c)[0x2b31cb0a84cc] /usr/lib64/libruby18.so.1.8[0x2b31cb089b8d] /usr/lib64/libruby18.so.1.8[0x2b31cb08bdaa]
(In reply to comment #30) > It seems to me that the smartest thing to do is to follow upstream, rather than > trying to gather a bunch of patches ourselves without a deeper understanding of > the issues. > > As for the rails issues, I've just tried running ruby-1.8.6_p230 on two of my > major rails projects, and both crash within seconds on starting the test suite: > > > *** glibc detected *** /usr/bin/ruby18: double free or corruption (out): > 0x0000000000c3ca30 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x2b31cb3ddaad] > /lib/libc.so.6(cfree+0x76)[0x2b31cb3df796] > /usr/lib64/libruby18.so.1.8[0x2b31cb0a7f34] > /usr/lib64/libruby18.so.1.8(ruby_xmalloc+0x7c)[0x2b31cb0a84cc] > /usr/lib64/libruby18.so.1.8[0x2b31cb089b8d] > /usr/lib64/libruby18.so.1.8[0x2b31cb08bdaa] > "upstream" is just as confused as we are, I think. :( It was all cut and dried -- somebody found some vulnerabilities, rolled out patches, and then stuff started crashing. The good thing that will come from this is that from now on, patches will get run through the automated test suites. I don't know if there's an automated Rails test suite, though, and I think most of the crashes have been reported in Rails. Bah!
If you patch this http://bugs.gentoo.org/attachment.cgi?id=157467 (copy to /usr/portage/dev-lang/ruby/) with this http://bugs.gentoo.org/attachment.cgi?id=156407 (copy to /usr/portage/dev-lang/ruby/files) then you should be save. Also note that Ruby uses _a_lot_ less memory when compiled with ptmalloc3: LDFLAGS='-lptmalloc3' ebuild /usr/portage/dev-lang/ruby/ruby-1.8.6_p114-r1.ebuild digest install qmerge Further information about that: http://zdavatz.wordpress.com/2007/07/18/heap-fragmentation-in-a-long-running-ruby-process/
(In reply to comment #32) > If you patch this > http://bugs.gentoo.org/attachment.cgi?id=157467 (copy to > /usr/portage/dev-lang/ruby/) with this > http://bugs.gentoo.org/attachment.cgi?id=156407 (copy to > /usr/portage/dev-lang/ruby/files) then you should be save. As mentioned in comment 18 these patches do not seem to address all the issues.
(In reply to comment #33) > (In reply to comment #32) > > If you patch this > > http://bugs.gentoo.org/attachment.cgi?id=157467 (copy to > > /usr/portage/dev-lang/ruby/) with this > > http://bugs.gentoo.org/attachment.cgi?id=156407 (copy to > > /usr/portage/dev-lang/ruby/files) then you should be save. > > As mentioned in comment 18 these patches do not seem to address all the issues. I do not understand. Which _exact_ issues do they not address? Thank you for your Feedback. Best Zeno
Created an attachment (id=158505) [details] Security fixes backported to a Ruby version that works with Rails The patch is here: http://takk.webreakstuff.com/~tmacedo/r8ee-security-patch-20080623-2-1.8.6p114.txt It was backported by the guys from phusion ( http://blog.phusion.nl/2008/06/23/ruby-186-p230187-broke-your-app-ruby-enterprise-edition-to-the-rescue/ ) to p111. I just removed the unneeded parts of the diff (because one of the issues fixed there was already fixed in 114) and turned it into an ebuild.
I tested it with the stable Rails versions (2.1, 2.0 and 1.2) (In reply to comment #35) > Created an attachment (id=158505) [edit] [details] > Security fixes backported to a Ruby version that works with Rails > > The patch is here: > > http://takk.webreakstuff.com/~tmacedo/r8ee-security-patch-20080623-2-1.8.6p114.txt > > It was backported by the guys from phusion ( > http://blog.phusion.nl/2008/06/23/ruby-186-p230187-broke-your-app-ruby-enterprise-edition-to-the-rescue/ > ) to p111. I just removed the unneeded parts of the diff (because one of the > issues fixed there was already fixed in 114) and turned it into an ebuild. >
Created an attachment (id=158513) [details] ruby-1.8-revert15856.patch If someone is able to reproduce the rails breakage, please try reverting the changeset 15856 from _p230. Does it help? The ebuild to test can be taken from here: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/ruby/ruby-1.8.6_p230.ebuild?hideattic=0&rev=1.2&view=log
*** Bug 229683 has been marked as a duplicate of this bug. ***
CVE-2008-2662 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2662): Multiple integer overflows in the rb_str_buf_append function in Ruby 1.8.4 and earlier, 1.8.5 before 1.8.5-p231, 1.8.6 before 1.8.6-p230, 1.8.7 before 1.8.7-p22, and 1.9.0 before 1.9.0-2 allow context-dependent attackers to execute arbitrary code or cause a denial of service via unknown vectors that trigger memory corruption, a different issue than CVE-2008-2663, CVE-2008-2664, and CVE-2008-2725. NOTE: as of 20080624, there has been inconsistent usage of multiple CVE identifiers related to Ruby. This CVE description should be regarded as authoritative, although it is likely to change. CVE-2008-2663 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2663): Multiple integer overflows in the rb_ary_store function in Ruby 1.8.4 and earlier, 1.8.5 before 1.8.5-p231, 1.8.6 before 1.8.6-p230, and 1.8.7 before 1.8.7-p22 allow context-dependent attackers to execute arbitrary code or cause a denial of service via unknown vectors, a different issue than CVE-2008-2662, CVE-2008-2664, and CVE-2008-2725. NOTE: as of 20080624, there has been inconsistent usage of multiple CVE identifiers related to Ruby. The CVE description should be regarded as authoritative, although it is likely to change. CVE-2008-2664 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2664): The rb_str_format function in Ruby 1.8.4 and earlier, 1.8.5 before 1.8.5-p231, 1.8.6 before 1.8.6-p230, 1.8.7 before 1.8.7-p22, and 1.9.0 before 1.9.0-2 allows context-dependent attackers to trigger memory corruption via unspecified vectors related to alloca, a different issue than CVE-2008-2662, CVE-2008-2663, and CVE-2008-2725. NOTE: as of 20080624, there has been inconsistent usage of multiple CVE identifiers related to Ruby. The CVE description should be regarded as authoritative, although it is likely to change. CVE-2008-2725 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2725): Integer overflow in the rb_ary_splice function in Ruby 1.8.4 and earlier, 1.8.5 before 1.8.5-p231, 1.8.6 before 1.8.6-p230, and 1.8.7 before 1.8.7-p22 allows context-dependent attackers to trigger memory corruption via unspecified vectors, aka the "REALLOC_N" variant, a different issue than CVE-2008-2662, CVE-2008-2663, and CVE-2008-2664. NOTE: as of 20080624, there has been inconsistent usage of multiple CVE identifiers related to Ruby. The CVE description should be regarded as authoritative, although it is likely to change. CVE-2008-2726 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2726): Integer overflow in the rb_ary_splice function in Ruby 1.8.4 and earlier, 1.8.5 before 1.8.5-p231, 1.8.6 before 1.8.6-p230, 1.8.7 before 1.8.7-p22, and 1.9.0 before 1.9.0-2 allows context-dependent attackers to trigger memory corruption, aka the "beg + rlen" issue. NOTE: as of 20080624, there has been inconsistent usage of multiple CVE identifiers related to Ruby. The CVE description should be regarded as authoritative, although it is likely to change.
ruby 1.8.6_p230 with the revert15856 patch seems to work ok for me, at least I can run the test suites for both my large rails projects.
Maybe we can try that combination in the tree, and get it stable after a week? I don't know how Ruby folks care to proceed with the Rails breakage, but Shugo Maeda pointed out this changeset might be the cause. We will have to bump to updated versions eventually, and I would like us using a later version with one revert rather than an old version with 5 security issues backported. I have to add that I am unsure about the status of CVE-2008-2727 and CVE-2008-2728, they have not been filled in by CVE and the Ruby pages states them as "removed".
(In reply to comment #41) > I have to add that I am unsure about the status of CVE-2008-2727 and > CVE-2008-2728, they have not been filled in by CVE and the Ruby pages states > them as "removed". CVE-2008-2727 and -2728 were intended for Ruby 1.6, and probably are dupes of -2725 and -2726, so no bother for us.
The discussion is continuing on the ruby-core mailing list. See http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17438 or http://groups.google.com/group/ruby-core-google/browse_thread/thread/d994a9dbbf119f8d
(In reply to comment #41) > Maybe we can try that combination in the tree, and get it stable after a week? > > I don't know how Ruby folks care to proceed with the Rails breakage, but Shugo > Maeda pointed out this changeset might be the cause. We will have to bump to > updated versions eventually, and I would like us using a later version with one > revert rather than an old version with 5 security issues backported. Agreed, althought I'm not entirely sure about stabling it in a week. I really hope that upstream will produce a better patchlevel within that timeframe. In any case, I've just added ruby-1.8.6_p230 to the tree, with the revert patch. We'll see how much stuff that breaks. :-/
According to this message on the ruby-core list the bugs only can cause a denial of service attack: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/17427
Sorry but the guys at Apple are _total_ Morons! And the Japanese as polite as they are, are just too kind! Thank you Matz! Apple deserves a slap across the face for this one!
It seems that the problems mentioned in at least one of the CVE's were not properly fixed in 1.8.6_p230, according to the ruby-core mailing list. 1.8.6_p256 seems to fix this ommision, but this version is not yet released. In any case this makes 1.8.6_p230 not a stable candidate.
There has yet another integer overflow been reported. I hope this will be fixed in a new patchlevel, CVE-2008-2376 http://www.openwall.com/lists/oss-security/2008/07/02/3
(In reply to comment #48) > There has yet another integer overflow been reported. I hope this will be fixed > in a new patchlevel, CVE-2008-2376 > http://www.openwall.com/lists/oss-security/2008/07/02/3 > It was mentioned on the ruby-core list so I assume this is/will be fixed in the forthcoming release. That was originally planned for today, but some issues were discovered during wider testing so the release has been postponed a bit.
(In reply to comment #49) > It was mentioned on the ruby-core list so I assume this is/will be fixed in the > forthcoming release. That was originally planned for today, but some issues > were discovered during wider testing so the release has been postponed a bit. Yes ... supposedly the fix for this one has been in the SVN repository for some time, but there are a few die-hards wanting to make sure all the test suites run and Rails doesn't crash before they will bless the upstream source. I'm on the edge of the die-hards at the moment, since I'm just running this stuff to get profiles. :) >
Hans, are there any updates as to a new release?
Nope, no news yet, although people have been testing the current head for 1.8.6 and finding and fixing a few issues. Hopefully that means that there will be an official and properly working release soon.
Apparently this issue has finally been fixed upstream - see http://redmine.ruby-lang.org/issues/show/199 . I assume we can follow them and finally release a fixed version.
(In reply to comment #53) > Apparently this issue has finally been fixed upstream - see > http://redmine.ruby-lang.org/issues/show/199 . I assume we can follow them and > finally release a fixed version. > I hope it's fixed ... I have a test case that segfaults with p230 if anyone cares. :)
2008.0 is out, so no need to keep release on the CC list.
A new release is now scheduled for August 8th.
I have just added ruby 1.8.6_p286 to CVS, which as far as I can tell fixes all security issues reported on this bug. My proposal is to test this version for a week and mark it stable if no regressions have been found in that time.
Thanks Hans, we'll be adding arches on this bug on Aug. 17 then. Please leave a note here if bugs come popping up.
These are the issues covered by http://www.ruby-lang.org/en/news/2008/08/08/multiple-vulnerabilities-in-ruby/ They are fixed in the ebuild to be stabled. CVE-2008-3655 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3655): Ruby 1.8.5 and earlier, 1.8.5 through 1.8.6-p286, 1.8.7 through 1.8.7-p71, and 1.9 through r18423 does not properly restrict access to critical variables and methods at various safe levels, which allows context-dependent attackers to bypass intended access restrictions via (1) untrace_var (2) $PROGRAM_NAME, and (3) syslog at safe level 4, and (4) insecure methods at safe levels 1 through 3. CVE-2008-3656 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3656): Algorithmic complexity vulnerability in WEBrick::HTTP::DefaultFileHandler in WEBrick in Ruby 1.8.5 and earlier, 1.8.5 through 1.8.6-p286, 1.8.7 through 1.8.7-p71, and 1.9 through r18423 allows context-dependent attackers to cause a denial of service (CPU consumption) via a crafted HTTP request that is processed by a backtracking regular expression. CVE-2008-3657 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3657): The dl module in Ruby 1.8.5 and earlier, 1.8.5 through 1.8.6-p286, 1.8.7 through 1.8.7-p71, and 1.9 through r18423 does not check "taintness" of inputs, which allows context-dependent attackers to bypass safe levels and execute dangerous functions by accessing a library using DL.dlopen.
Hans, there are bug 234877 and bug 230748 open that are specific to this version. Should they block stabling?
I would like to see #234877 fixed first, but #230748 should not hold of stabilizing the package. The stabilization target will also be at least ruby 1.8.6_p287-r1 since we fixed another security issue in #236060.
Given that there has not been any feedback on #234877 and we can't seem to reproduce it, I propose that we start stabling ruby 1.8.6_p287-r1 so that we can finally close a number of security bugs for ruby and get the GLSA's underway. Robert, will you add the arches or do you want me to do this?
Arches, please test and mark stable: =dev-lang/ruby-1.8.6_p287-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Stable for HPPA.
ppc64 stable
Sparc stable (I've been using it for a couple weeks now anyway).
alpha/ia64/x86 stable
amd64 stable
CVE-2008-2727 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2727): ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2008-2725. Reason: This candidate is a duplicate of CVE-2008-2725. Notes: All CVE users should reference CVE-2008-2725 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. CVE-2008-2728 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2728): ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2008-2726. Reason: This candidate is a duplicate of CVE-2008-2726. Notes: All CVE users should reference CVE-2008-2726 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. CVE-2008-3905 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3905): resolv.rb in Ruby 1.8.5 and earlier, 1.8.6 before 1.8.6-p287, 1.8.7 before 1.8.7-p72, and 1.9 r18423 and earlier uses sequential transaction IDs and constant source ports for DNS requests, which makes it easier for remote attackers to spoof DNS responses, a different vulnerability than CVE-2008-1447.
ppc stable
GLSA request filed.
GLSA 200812-17, thanks everyone, sorry about the delay.
