Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix)
Urabe Shyouhei
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
Joachim Glauche
> Hi all.
>
> Some vulnerabilities were found on Ruby, one of which allow attackers to
> execute arbitrary codes. These are releases to fix those problems.
>
> 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
--
Posted via http://www.ruby-forum.com/.
Zhukov Pavel
> 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?
check patches?
Mike Perham
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... :-(
Andreas S.
> 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"?
Igal Koshevoy
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
Brian Brian
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?
Thomas Hurst
> 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.
--
Thomas 'Freaky' Hurst
http://hur.st/
Igal Koshevoy
> 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?
Ollivier Robert
Igal Koshevoy <ig...@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/
--
Ollivier ROBERT -=- EEC/RIF/SEU -=-
Systems Engineering Unit
Igal Koshevoy
> 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.
Fred Chingota
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.
Fred Chingota
Zhukov Pavel
saurabh purnaye
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 <fredch...@yahoo.com>
wrote:
> Guys
--
--
Thanks and Regards
Saurabh Purnaye
+91-9922907342
skype: sorab_pune
yahoo & gtalk: saurabh.purnaye
msn: psau...@live.com
Hongli Lai
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. :)
Igal Koshevoy
> 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 Koshevoy
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.
Hongli Lai
> 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. :)
Igal Koshevoy
> ...
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
Hongli Lai
took a look at eval.c but the changes don't look like security fixes to
me, at first glance.
Igal Koshevoy
> 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 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
Thomas Hurst
> 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?
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.
>> 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 Koshevoy
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!
Hongli Lai
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.
--
Phil Ross
http://tzinfo.rubyforge.org/ -- DST-aware timezone library for Ruby
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
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
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 Koshevoy
> (https://bugs.gentoo.org/show_bug.cgi?id=225465).
as well. I hope they join in the discussion here too.
Igal Koshevoy
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
Igal Koshevoy
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?
Phil Ross
> 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):
>
>
> 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.
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?
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
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.
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
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
Thank you for the suggestion, Dominic.
Jason Crystal
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
Marc Heiler
> 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.
Igal Koshevoy
> 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
M. Edward (Ed) Borasky
Igal Koshevoy
Thanks for the reminder.
To put my earlier comments in perspective. I really enjoy working with
Ruby, work hard to promote it, publish multiple open source projects
with it, and want it to succeed.
-igal
Larry Rosenman
using this one.
Igal Koshevoy
> Has anyone ported this "fix patch" to 1.8.5-p231? I get patch errors
> using this one.
>
Do you have a compelling reason to stay with 1.8.5? If you do, you may
be able to use the Smartleaf 1.8.6 patch for p230 as a guide. It
basically reverts one bad commit, so if you can just walk through the
commits in the 1.8.5 SVN branch till you find a conceptually similar
commit, you can try reverting it.
-igal
Larry Rosenman
We have one RoR app that is basically unmaintained. I'll see if it'll
work with 1.8.6 and this patch.
Thanks!
Igal Koshevoy
> We have one RoR app that is basically unmaintained. I'll see if it'll
> work with 1.8.6 and this patch.
1.8.6p111 backport and the Smartleaf 1.8.6p230 revert patches both pass
the Rails 2.0 test suites, so you should be fine. Another alternative is
the Phusion Ruby Enterprise Edition, which uses the p111 backport.
The only thing I can remember being different between 1.8.5 and 1.8.6 is
that the breakpointer feature stopped working, so if you ever need that
feature, just use ruby-debug instead.
-igal
Larry Rosenman
1.8.6-p230 + http://dev.smartleaf.com/misc/p230_fixit_patch.txt
seems to not segfault or give me glibc corruption errors, and the app
works, so I am going to deploy it.
Thanks for the push, and especially the patch.
LER
François Montel
they have the same problems with Rails as the p230 release does?
Mike Berrow
but there hasn't been a peep from the powers that be.
They seem to be maintaining "radio silence".
Why might that be?
-- Mike Berrow
Igal Koshevoy
his latest SVN release, see the ruby-core thread at
http://www.ruby-forum.com/topic/157392#695343
Bad news: The new version in SVN is failing dozens of tests that worked
fine in p111. This is bad because any apps that depend on that old
behavior will break. If you have time, please grab the files from
[http://redmine.ruby-lang.org/issues/show/199] and see if you can figure
out what's going on.
Thanks!
-igal
PS: I've sent email to Brian Ford, the primary author of RubySpec to see
if he can lend a hand in making sense of the errors. Maybe in the
process we can also submit some code to RubySpec to improve its
coverage.
Cheri Anaclerio
Hongli's patches? I too am experiencing glibc segmentation problems and
would like to fix my local copy of rails 1.8.6.
Thanks!
Cheri
Jason Crystal
> Could somebody please explain how to apply the Smartleaf Stanislav and
> Hongli's patches? I too am experiencing glibc segmentation problems and
> would like to fix my local copy of rails 1.8.6.
>
> Thanks!
>
> Cheri
1. Download the 1.8.6p230 source here:
http://www.ruby-lang.org/en/news/2008/06/20/arbitrary-code-execution-vulnerabilities/
2. Download the patch here (and and stick it in the ruby-1.8.6-p230
source directory): http://dev.smartleaf.com/misc/p230_fixit_patch.txt
3. In your terminal:
$ cd ruby-1.8.6-p230
$ patch < ./p230_fixit_patch.txt
4. Then compile per usual. Ex:
$ ./configure
$ make
$ sudo make install
Igal Koshevoy
> 4. Then compile per usual. Ex:
> $ ./configure
> $ make
> $ sudo make install
>
step. Doing step 4 like that will put the files directly into the user's
/usr/local hierarchy, which will make removing or upgrading that versino
difficult.
I'd strongly recommend that you use GNU Stow
[http://www.gnu.org/software/stow/manual.html] and change the steps to:
$ ./configure --prefix=/usr/local/stow/ruby-1.8.6p230smartleaf
$ make
$ sudo mkdir -p /usr/local/stow
$ sudo make install
$ sudo stow -d /usr/local/stow ruby-1.8.6p230smartleaf
With those commands, you'll end up with a symlink at /usr/local/bin/ruby
that points to the installed version deeper within the /usr/local/stow
hierarchy.
Using stow will let you easily install, uninstall and switch between
versions of a compiled applications.
-igal
PS: Another good alternative is to use Ruby Enterprise Edition
[http://rubyenterpriseedition.com/] which already includes the patches
and installs itself by default into directory within /opt.
Jason Crystal
> step. Doing step 4 like that will put the files directly into the user's
> /usr/local hierarchy, which will make removing or upgrading that versino
> difficult.
>
> I'd strongly recommend that you use GNU Stow
Igal,
Good call with that. I just wanted to demonstrate to Cheri that at that
point in the steps, you can do anything you'd normally do with a
functional Ruby source.
Thanks for the additional info!
-Jason
Cheri Anaclerio
when I start the webrick server, Rubygems 0.9.4.1 can't be found even
though it is installed. Looks like the directory I'm pointing to
doesn't know anything about Rubygems. What can I do to fix this?
Thanks! Cheri
(See full trace by running task with --trace)
Rails requires RubyGems >= 0.9.4. Please install RubyGems and try again:
http://rubygems.rubyforge.org
[root@localhost cz]# yum install rubygems
fedora 100% |=========================| 2.1 kB
00:00
updates 100% |=========================| 2.3 kB
00:00
adobe-linux-i386 100% |=========================| 951 B
00:00
Setting up Install Process
Parsing package install arguments
Package rubygems - 0.9.4-1.fc8.noarch is already installed.
Nothing to do
[root@localhost cz]#
>
> I'd strongly recommend that you use GNU Stow
> [http://www.gnu.org/software/stow/manual.html] and change the steps to:
>
> $ ./configure --prefix=/usr/local/stow/ruby-1.8.6p230smartleaf
> $ make
> $ sudo mkdir -p /usr/local/stow
> $ sudo make install
> $ sudo stow -d /usr/local/stow ruby-1.8.6p230smartleaf
>
> With those commands, you'll end up with a symlink at /usr/local/bin/ruby
> that points to the installed version deeper within the /usr/local/stow
> hierarchy.
>
> Using stow will let you easily install, uninstall and switch between
> versions of a compiled applications.
>
> -igal
>
> PS: Another good alternative is to use Ruby Enterprise Edition
> [http://rubyenterpriseedition.com/] which already includes the patches
> and installs itself by default into directory within /opt.
--
Posted via http://www.ruby-forum.com/.
Igal Koshevoy
> Ok, I took the stow route and followed the steps below. However, now
> when I start the webrick server, Rubygems 0.9.4.1 can't be found even
> though it is installed. Looks like the directory I'm pointing to
> doesn't know anything about Rubygems. What can I do to fix this?
> Thanks! Cheri
>
> (See full trace by running task with --trace)
> Rails requires RubyGems >= 0.9.4. Please install RubyGems and try again:
> http://rubygems.rubyforge.org
> [root@localhost cz]# yum install rubygems
>
(/usr/bin/gem) is using your old interpreter (/usr/bin/ruby) and knows
nothing about your new manually-compiled interpreter (/usr/local/bin/ruby).
The solution is to install RubyGems for the new interpreter, e.g.:
wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
tar xvfz rubygems-1.2.0.tgz
cd rubygems-1.2.0
sudo /usr/local/bin/ruby setup.rb --no-ri --no-rdoc
sudo /usr/local/bin/gem install rake --no-ri --no-rdoc
Because the above changes the stowed directory structure, you'll want to
restow it so that the new files are linked into /usr/local, e.g.:
pushd /usr/local/stow; sudo stow --restow ruby-1.8.6p230smartleaf; popd
There's a way to make multiple Ruby interpreters share a copy of the
installed gems by setting the GEM_HOME environmental variable. However,
this seems like a bad idea and you're best off just installing new
copies of the gems you need.
-igal
Cheri Anaclerio
associated gems, would I just delete the stow directory
$ sudo stow -d /usr/local/stow ruby-1.8.6p230smartleaf
I am contemplating the solution of just upgrading to Ruby 1.8.7 and
Rails 2.1 since my project is still in development. However, from
reading the forums it looks like there are many plugins that won't work
with Rails 2.1 and other issues that still need to be resolved. Any
thoughts on the upgrade route?
- Cheri
Igal Koshevoy wrote:
> Cheri Anaclerio wrote:
>>
> The problem is that the copy of RubyGems installed via Yum
> (/usr/bin/gem) is using your old interpreter (/usr/bin/ruby) and knows
> nothing about your new manually-compiled interpreter
> (/usr/local/bin/ruby).
>
> The solution is to install RubyGems for the new interpreter, e.g.:
>
> wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
> tar xvfz rubygems-1.2.0.tgz
> cd rubygems-1.2.0
> sudo /usr/local/bin/ruby setup.rb --no-ri --no-rdoc
> sudo /usr/local/bin/gem install rake --no-ri --no-rdoc
>
> Because the above changes the stowed directory structure, you'll want to
> restow it so that the new files are linked into /usr/local, e.g.:
>
> pushd /usr/local/stow; sudo stow --restow ruby-1.8.6p230smartleaf;
> popd
>
> There's a way to make multiple Ruby interpreters share a copy of the
> installed gems by setting the GEM_HOME environmental variable. However,
> this seems like a bad idea and you're best off just installing new
> copies of the gems you need.
>
> -igal
--
Posted via http://www.ruby-forum.com/.
Igal Koshevoy
> Thanks, Igal! So when I want to go back to using /usr/bin/ruby and it's
> associated gems, would I just delete the stow directory
>
remove the symlinks:
sudo stow -d /usr/local/stow --delete ruby-1.8.6p230smartleaf
And then you can "rm -rf" the "/usr/local/stow/ruby-1.8.6p230smartleaf"
directory. You should keep the "/usr/local/stow directory" though, in
case you need to stow away something else.
However, please note that although the p230smartleaf fixes the
segmentation faults, the p230 version it relies on seems to change the
Ruby API in a number of ways. I'm working with folks in the ruby-core
mailing list to try to make sense of the situation and determine how
significant the breakage is.
For the moment, it may be safest to use one of the backport patches
developed against p111 or p114, or the Ruby Enterprise Edition which
includes these patches. Also note that many OS vendors have shipped new
packages with some of these fixes, including FreeBSD, Ubuntu, and
Fedora. However, it's unclear how good these unofficial patches are, and
it'd be best if the Ruby developers can ship an officially blessed fix
for this in the near future.
> I am contemplating the solution of just upgrading to Ruby 1.8.7 and
> Rails 2.1 since my project is still in development. However, from
> reading the forums it looks like there are many plugins that won't work
> with Rails 2.1 and other issues that still need to be resolved. Any
> thoughts on the upgrade route?
If you don't have to promise availability for your app, it may be worth
trying out 1.8.7 and reporting your experiences. However, please
understand that very few people are using that version and that if
earlier versions of Rails don't run on it, this may indicate deeper
issues, so this will be somewhat adventurous.
I ported a moderate sized Rails app from 2.0.2 to 2.1.0 recently, it
works well and I really liked that it provides built-in solutions for a
number of features we'd implemented on our own and it was nice to
replace those with the much nicer bundled solutions.
-igal
Roland Mai
I run Arch and just upgraded to ruby-1.8.7_p22 but it seems the string
issue is partially fixed.
irb(main):001:0> str = "A"*(2**16); nil
=> nil
irb(main):002:0> while true
irb(main):003:1> str << str
irb(main):004:1> end
(irb):3: [BUG] Segmentation fault
ruby 1.8.7 (2008-06-20 patchlevel 22) [i686-linux]
Aborted
While the following works fine:
irb(main):001:0> str = "A"*(2**16); nil
=> nil
irb(main):002:0> while true
irb(main):003:1> str = str+str
irb(main):004:1> end
ArgumentError: negative string size (or size too big)
from (irb):3:in `+'
from (irb):3
from :0
I have another computer with Ubuntu and ruby 1.8.6 in which both cases
worked fine.
Cheri Anaclerio
Are you sure these are the right steps for installing gems for the
Smartleaf patched interpreter? I've followed all your steps outlined
below, but when I get to
sudo /usr/local/bin/gem install rake --no-ri --no-rdoc,
the command is not found.
i.e.,
[Cheri@localhost rubygems-1.2.0]$ sudo /usr/local/bin/gem install rake
--no-ri --no-rdoc
sudo: /usr/local/bin/gem: command not found
I don't think I'm installing RubyGems in the right directory path.
Thanks in advance for your help.
- Cheri
Igal Koshevoy wrote:
> Cheri Anaclerio wrote:
>>
> The problem is that the copy of RubyGems installed via Yum
> (/usr/bin/gem) is using your old interpreter (/usr/bin/ruby) and knows
> nothing about your new manually-compiled interpreter
> (/usr/local/bin/ruby).
>
> The solution is to install RubyGems for the new interpreter, e.g.:
>
> wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
> tar xvfz rubygems-1.2.0.tgz
> cd rubygems-1.2.0
> sudo /usr/local/bin/ruby setup.rb --no-ri --no-rdoc
> sudo /usr/local/bin/gem install rake --no-ri --no-rdoc
>
> Because the above changes the stowed directory structure, you'll want to
> restow it so that the new files are linked into /usr/local, e.g.:
>
> pushd /usr/local/stow; sudo stow --restow ruby-1.8.6p230smartleaf;
> popd
>
> There's a way to make multiple Ruby interpreters share a copy of the
> installed gems by setting the GEM_HOME environmental variable. However,
> this seems like a bad idea and you're best off just installing new
> copies of the gems you need.
>
> -igal
--
Posted via http://www.ruby-forum.com/.
Doug Alcorn
>
> 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
Our production Rails environment has been having some memory problems
for a while. Once a week or our mongrel daemons swell in memory usage
and it pushes beyond what our box can comfortably handle. We're hunting
for the root cause, but a simple restart of the mongrel processes clears
it up for another week or so.
We installed the smartleaf patched ruby on our production environment on
Monday. Since that time we had our processes balloon at least a dozen
times in two days. After reverting the patch to ruby it has returned to
normal. I don't know if our situation is a corner case or not. I'm
just wanting to let folks know who are trying to decide what to do that
we've had problems with the smartleaf patch.
Igal Koshevoy
I think I see what went wrong. You'll probably need to restow before the newly installed gem command becomes visible. Try these:
wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
tar xvfz rubygems-1.2.0.tgz
cd rubygems-1.2.0
sudo /usr/local/bin/ruby setup.rb --no-ri --no-rdoc
sudo stow -d /usr/local/bin --restow ruby-1.8.6p230smartleaf
sudo /usr/local/bin/gem install rake --no-ri --no-rdoc
sudo stow -d /usr/local/bin --restow ruby-1.8.6p230smartleaf
Basically, whenever new executables, like "gem", are added within the
stowed directory, you need to restow. However, at least on my system,
once gem is installed, it seems to be doing something clever to symlink
things like rake and such into /usr/local/bin automatically without the
need for a restow.
If these commands don't work, can you paste the final results of the
"setup.rb" command? When it finishes installing it on my system, it
prints something like:
RubyGems installed the following executables:
/usr/local/stow/ruby-1.8.6-p230smartleaf/bin/gem
When (re)stowed, the contents of that "bin" directory above are
symlinked into /usr/local/bin, and that's where /usr/local/bin/gem is
supposed to come from.
-igal
Igal Koshevoy
> Our production Rails environment has been having some memory problems
> for a while. Once a week or our mongrel daemons swell in memory usage
> and it pushes beyond what our box can comfortably handle. We're hunting
> for the root cause, but a simple restart of the mongrel processes clears
> it up for another week or so.
>
> We installed the smartleaf patched ruby on our production environment on
> Monday. Since that time we had our processes balloon at least a dozen
> times in two days. After reverting the patch to ruby it has returned to
> normal. I don't know if our situation is a corner case or not. I'm
> just wanting to let folks know who are trying to decide what to do that
> we've had problems with the smartleaf patch.
>
Can you or one of your engineers try to figure out how to trigger this
memory ballooning problem? That'd be really valuable to the Ruby community.
The Smartleaf patch doesn't introduce any new code, merely reverts some
problematic refactoring, so whatever is making your problem worse may
very likely still be in the latest Ruby code that the maintainers plan
to publish soon, so it'd be best to identify the cause ASAP.
-igal
Doug Alcorn
> Can you or one of your engineers try to figure out how to trigger this
> memory ballooning problem? That'd be really valuable to the Ruby
> community.
>
Not only to the community, but also my client. I've been working on it
on and off for several weeks. I'm not sure I have the right skills atm
to do memory profiling. I'd be interested in some good pointers on how
to memory profile ruby/rails apps
Igal Koshevoy
> Igal Koshevoy wrote:
>
>
>> Can you or one of your engineers try to figure out how to trigger this
>> memory ballooning problem? That'd be really valuable to the Ruby
>> community
>
> on and off for several weeks. I'm not sure I have the right skills atm
> to do memory profiling. I'd be interested in some good pointers on how
> to memory profile ruby/rails apps
>
Ruby with patches backported to p111/p114, whereas you're running a
patch against p230. Relatively few people are using that newer release,
but its code is much closer to what the Ruby maintainers plan to ship in
the near future. Because you're closer to the edge, you've likely hit
something the rest of us haven't.
As for identifying the problem, unless someone has a better suggestion,
I think you just have to use each part of your application until you
identify an action that triggers this bug. You should clone your
production environment as closely as possible, including the database
and run the app in production mode, and use that for your testing. You
should also keep a written list of all controllers, actions and logical
paths within actions, and then check these off as you've validated them
so you can be systematic about checking everything. After each action,
glance at the application's memory consumption to see if you caught the
problem. Once you know what sequence of user actions will cause it to
balloon, you can start narrowing down the code causing it by commenting
stuff out and such.
A good way to keep an eye on memory consumption is to start up a
terminal and run a command like this in it:
watch -n1 'ps aux | egrep "ruby|PID" | egrep -v egrep'
The above scans the output of "ps" each second and displays all the
processes matching the "ruby". You may want to substitute
"mongrel_rails" or whatever the name is for your server process, and
then just watch the RSS and VSZ columns.
Another possible way to identify the problem may be NewRelic's RPM
(http://newrelic.com/). Be sure to get the "Production Mode" with the 2
month free trial and enable the feature which uploads reporting data
back to them. Among other useful features, this Rails plugin will help
you quickly identify the actions that are taking a long time to
complete. If lucky, this will help you identify the actions causing
leakage; and if less lucky, you'll know where to prioritize your tuning
efforts later, which is still useful.
Anyone else have ideas on how to identify the problem?
-igal
Igal Koshevoy
> Not only to the community, but also my client. I've been working on it
> on and off for several weeks. I'm not sure I have the right skills atm
> to do memory profiling. I'd be interested in some good pointers on how
> to memory profile ruby/rails app
I've got potentially bad news according to Robin Ward at
http://weblog.rubyonrails.com/2008/6/21/multiple-ruby-security-vulnerabilities:
> I installed the Smartleaf p230 patch above and I can confirm that my
> Ruby app is running fine in production without any segfaults. [...]
> Disregard what I said above about the smartleaf patch: After running
> for a while the memory usage of all my ruby processes climbed through
> the room. There are definitely memory leaks present.
Because the bug isn't in the Smartleaf patch, but rather in the Ruby
interpreter, it's very likely that the problem is still in there.
Can anyone please provide code to reproduce this?
-igal
Igal Koshevoy
There are bugs in the Ruby interpreter that cause it to leak memory.
Please use a Ruby release that's based on a patched version of the p111
or p114 code until this is resolved.
I've put together code which demonstrates this at:
http://pastie.org/226715
-igal
RedMine ticket: http://redmine.ruby-lang.org/issues/show/216
ruby-core thread: http://www.ruby-forum.com/topic/158334#new
M. Edward (Ed) Borasky
"watch" is for wimps ... just about every Linux system has "top". :)
What's *really* nice about "top" is that you can do "top -b > logfile"
and it will do a "top" at the default interval to the log file. Then you
can parse that log file with Ruby and watch your process leak memory.
I'm just about to set up some shell scripts (sorry, all you Rake fans --
my Rakefiles are too ugly so I'm dropping back to bash :) ) to build a
profiling Ruby. I might just take the opportunity to learn how to use
"valgrind" while I'm at it.
M. Edward (Ed) Borasky
I've never used it, but I believe "valgrind" is the tool one uses to
check for memory leaks in C code -- like MRI, for example. :)
Robert Thau
> I've never used it, but I believe "valgrind" is the tool one uses to
> check for memory leaks in C code -- like MRI, for example. :)
In many cases, yes --- but I tried it for the 1.8.6-p230 segfault
problem, and regrettably, MRI's GC confused the hell out of it.
FWIW, I'm the guy who produced the "Smartleaf patch" which eliminates
the immediate segfault problems (though not, apparently, this reported
leak). What this amounted to was identifying the particular patch
(of *many* that went into p230 as released) that was causing the
trouble,
and reverting that one patch (so, the "smartleaf patch" comes straight
from
a reversed "svn diff"). The strategy I used was a little
time-consuming,
but it has the advantage of not requiring expertise in much of anything;
it was bisection search (i.e., binary search among the 1.8.6 patch
stream).
The idea of a bisection search is basically this: There's an ordered
series of svn revisions that turned 1.8.6-p111 into 1.8.6-p230 (or
whatever), and among those, there's going to be a *first* revision that
exhibits the problem. If we assume that nothing else broke in the
course of the stream of revisions, then we can find that first revision
by binary search: Check out the release midway between the two we're
trying to evaluate, and see if that release leaks storage the way p238
does. If the memory leak problem is already there, then it must have
been introduced somewhere in the series of revisions between 1.8.6-p111
and [midpoint]. If not, then it was introduced between [midpoint] and
1.8.6-p230. Either way, we've now bracketed it to within an interval
half the original size. If we skip to the midpoint of *that* interval,
we can cut it in half again, and proceed to the one patch that
introduced
the problem. (The git suite of tools can actually automate a lot of
this,
if you happen to have the relevant history in a local git repo --- see
"git bisect".)
In this case, of course, there's one complication: something else *did*
break in the middle --- in particular, the segfaults that start
happening
at revision 17222. So, if you get to (or past) that point in the
history,
you'd have to revert that particular change to look for the storage
leak.
But if anyone out there can keep track of that complication, and has
time
to evaluate a dozen or so ruby-1.8.6 revisions to see if they have this
problem, that's enough to identify the particular change which first
introduced the problem. It doesn't need to be that many, I believe ---
but I'm allowing for screwups.
(BTW, It's conceivable that there's a subsequent patch which also
introduced
a leak, or depends in some other way on the one that did --- in which
case,
you'll have to root around in the subsequent history to get a more
complete
picture. But the most likely thing is that if you take the patch you
find,
and you revert it against 1.8.6-p238, you'll find the problem goes
away.)
One last note: this quite likely gives you something that you can apply
to p238 to eliminate the problem. It does not give the Japanese
maintenance
team a simple, self-contained piece of code which replicates the problem
---
and if they're reluctant to deal with bug reports that can only be
replicated
by installing tens of thousands of lines of other peoples' code, some
with
native code extensions, I do have a certain degree of sympathy. For the
segfault problem, I was eventually able to produce a short,
self-contained
script which also blew up --- see separate thread here:
http://www.ruby-forum.com/topic/157617
No rocket science there either. I'd identified the revision 17222
patch as a likely culprit, and also figured out what operations were
affected by that patch. So, I wrote a simple script with a long loop,
kept stuffing it with those operations until I saw segfaults, and
then eliminated irrelevant lines from that script until I had the
smallest thing I could which still blew up. (Again, there are no
absolute guarantees here: the suspect patch could conceivably
introduce more than one leak, and a minimal script would replicate
only one. Which is why I said "*may* be the simplest demonstration
in the post linked above. But while this isn't guaranteed to find
the problem, it's generally likely to.)
So, ahem... why am I not doing this? Well, for one thing, I don't
use mongrel, so I can't follow Igal's replication recipe exactly ---
and for another, I'm really pressed for time this week. I may
have time soon, but I'd be happier if someone else gets there
first ;-).
HTH,
rst@{ai,alum}.mit.edu
Robert Thau
[ stuff that got mangled by the line-wrapper at ruby-forum.com. ]
Gotta get a real NNTP client. Sigh...
rst
Rob Funk
>>
>> 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.
I was running Ruby-1.8.6-p230 with this patch for about a week on our
multi-rails-app server, but then came across a problem in an old Rails
app (originally Rails 1.1.6, which we upgraded to 1.2.6 in a failed
attempt at fixing this).
The problem was in file uploads from an Internet Explorer client. The
file object's original_filename method was returning just 'Documents,
and the full_original_filename method was returning just '"C:\Documents'
(including the initial double-quotes, but not including the single
quotes), when someone uploaded a file from under their 'C:\Documents and
Settings\' path.
I switched to Ruby-1.8.6-p111 with the security patches posted above,
and the problem went away.
M. Edward (Ed) Borasky
"I love it when a plan comes together". :) Jessee Hallett was talking
about the theory of patches in our monthly PDX Ruby meeting Tuesday.
This too can be automated in Ruby. :)
BTW, you might want to read the article about binary search in
"Beautiful Code". It turns out to be non-trivial (or, the author found a
way to make it non-trivial -- I haven't quite decided.) :)
barjunk
So I've seen a bunch of different ideas about what folks should
use...but is there a definitive set of sources to use at this point.
Given the short anecdote above and from reading past posts... it seems
like I should give 1.8.6-p111 with the patch above a try.
Any reasons not to?
Mike B.
Larry Kluger
My thanks to all for such great work. I'm trying to figure out from the
msgs which is the right patch for ruby_1.8.6.p111
It seems that it would be
>Posted by Hongli Lai on 23.06.2008 15:40
>
>I've made an updated patch set:
>http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt
But when I run it using patch against ruby-1.8.6-p111, I get the
following:
[code]
$ patch < ../ruby_1.8.6.p111.ee-security-patch-20080623-2.txt
patching file array.c
patching file bignum.c
patching file eval.c
patching file intern.h
patching file io.c
can't find file to patch at input line 207
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/lib/webrick/httpservlet/filehandler.rb b/lib/webrick/httpservlet/filehandler.rb
|index 410cc6f..c8278b7 100644
|--- a/lib/webrick/httpservlet/filehandler.rb
|+++ b/lib/webrick/httpservlet/filehandler.rb
--------------------------
File to patch: EOF [I entered cntrl-d at this point]
Skip this patch? [y] y
Skipping patch.
4 out of 4 hunks ignored
patching file sprintf.c
patching file string.c
$
[/code]
Advice would be much appreciated.
Thanks and regards,
Larry in New York City
Rob Funk
> My thanks to all for such great work. I'm trying to figure out from the
> msgs which is the right patch for ruby_1.8.6.p111
>
> It seems that it would be
>>Posted by Hongli Lai on 23.06.2008 15:40
>>I've made an updated patch set:
>>http://blog.phusion.nl/assets/r8ee-security-patch-20080623-2.txt
I do believe that's the right patch.
> But when I run it using patch against ruby-1.8.6-p111, I get the
> following:
> [code]
> $ patch < ../ruby_1.8.6.p111.ee-security-patch-20080623-2.txt
.. but wrong command line. Since the patch has filename paths starting
with a/ and b/, you need to give -p1 to make patch strip off that part.
(And you need to be in the top of the source directory, but you probably
already are.)
Larry Kluger
> ... but wrong command line. Since the patch has filename paths starting
Yup, that was it.
Thank you for your expertise and time.
Regards,
Larry
Igal Koshevoy
> Rob Funk wrote:
>
>> ... but wrong command line. Since the patch has filename paths starting
>> with a/ and b/, you need to give -p1 to make patch strip off that part.
>>
>
> Yup, that was it.
>
Fedora, Gentoo and some others, you may want to consider using their
updated packages because these contain the patches and will be easier to
install/update.
Rob: Thanks.
-igal
Mike Berrow
have any segfault etc. breakage, what is the current advice?.
Is it p111 plus some patch?
Or might the dust settle soon on an official release?
Thanks much.
-- Mike Berrow
Mike Berrow
> If I want to use a 1.8.6 which solves the security issues but does not
> have any segfault etc. breakage, what is the current advice?.
>
> Is it p111 plus some patch?
> Or might the dust settle soon on an official release?
>
> Thanks much.
>
> -- Mike Berrow
Uhmmm, should I have asked this on core?