Multiple vulnerabilities in Ruby may lead to a denial of service (DoS) condition or allow execution of arbitrary code.
Igal Koshevoy
Shawn Balestracci
getting segfaults on 1.8.6-p230 and 1.8.5.p231
Ragav Satish
--Cheers
--Ragav
Ragav Satish
I'm seeing segfaults now with 1.8.5.p231. Intermittent
--Cheers
--Ragav
On Fri, 2008-06-20 at 23:34 -0700, Shawn Balestracci wrote:
Igal Koshevoy
> Apparently I spoke too soon ;-).
>
> I'm seeing segfaults now with 1.8.5.p231. Intermittent
http://weblog.rubyonrails.com/2008/6/21/multiple-ruby-security-vulnerabilities
> # Shawn Balestracci on 21 Jun 06:10:
> I’m getting segfaults on 1.8.5-p231 as well.
>
> # Jay on 21 Jun 06:18:
> Segfaults on both 1.8.5-p231 and 1.8.6-p230. So I’m stuck between a
> serious security vulnerability and a patched version that brings my
> site down within two requests. Wonderful!
On the bright side, I've figured out (again) the needlessly awkward
steps needed to build these as debian/ubuntu packages so I can release
them when a working version is shipped.
-igal
Igal Koshevoy
an update.
SUMMARY: All patched versions of MRI Ruby are broken and it's not
clear whether anyone's trying to resolve this. If you know C and think
you can fix them, I'll be glad to reserve space for your code sprint,
buy food and drink, and do whatever to help you be productive. If you
work for a company that relies on Ruby, consider putting up a bounty
for the fix. If you don't know C, you basically have to wait on the
sidelines until someone else releases a fix. Porting your apps to
JRuby is an option, but is sufficiently involved that it's not a
realistic short-term option for most large Ruby apps.
DETAILS:
1. DO NOT UPGRADE YET, all the new versions of MRI Ruby that claim to
patch the vulnerability are broken because they either fail with
segfaults or change the API in ways that break Rails 2.0.x, RSpec and
lots of other Ruby code. The new-yet-broken versions include:
1.8.5p231, 1.8.6p230, 1.8.7p22, and 1.9.0-2.
2. DO NOT JUST MANUALLY COMPILE AND INSTALL ANOTHER RUBY FROM SOURCE,
please learn to use GNU Stow so that you can easily uninstall, replace
and switch between it and other programs you manually compiled/
installed. Having to figure out how to remove a broken, manually-
installed copy of Ruby really sucks. The Stow manual is at
http://www.gnu.org/software/stow/manual.html
3. DO WORRY, the Ruby team committed code to their repository about 4
days ago that basically gives crackers all the information needed to
write attacks, although so far the only things folks have been able to
come up with are denial of service attacks. Zed Shaw provides a nice
analysis of potential problem areas and how to find them at
http://www.zedshaw.com/rants/the_big_ruby_vulnerabilities.html
What can you do if you have publicly-accessible Ruby apps?
1. NOTHING. Wait until someone else ships a working version.
2. FIX RUBY. If you know C and have time, please see if you can figure
out how to make the current releases of Ruby stop segfaulting. Also be
sure to try your fixes against the lovely RubySpec suite that Brian
Ford and his team built to define the correct behavior of a compliant
Ruby implementation, which should catch bugs and implementation
errors, as well as testing against RSpec and Rails test suites. I
haven't heard any comments on the ruby-talk or ruby-core mailing lists
suggesting that anyone is working on resolving these bugs, so get on
there if you think you can help.
3. SWITCH TO JRUBY. JRuby is the only other version of Ruby that's
currently ready for production use. It should not be vulnerable to
these attacks because it relies on Java's implementations of String,
Array, File and such. Unfortunately, porting a non-trivial Ruby app to
JRuby requires effort and infrastructure rework. JRuby cannot use gems
that require native C extensions, so you'll have to reimplement them
or find alternatives -- for example, you can't use SQLite as an
ActiveRecord adapter for JRuby on Rails. And if you're writing web
apps, you can't use Mongrel or Thin, but must instead deploy to Java
application servers like Glassfish, which can be quite tricky even for
someone that knows Java.
4. REMEMBER THE VULNERABILITY-HANDLING LESSON. If you're in a position
of authority in a software project affected by a vulnerability, please
either keep the problem quiet until you've fixed it quickly and worked
with distributors so they can ship updates, OR announce it publicly
and work actively with the community to integrate their fixes.
5. REMEMBER THE QUALITY-MANAGEMENT LESSON. If you're in a position of
authority in a software project that others depend on, please validate
your new code against the test suites of popular projects. Every
current version of MRI Ruby available is effectively broken because
their new releases are not validated against publicly available tests
suites from projects like RubySpec, Rails and RSpec.
For additional details, see http://www.rubyinside.com/june-2008-ruby-security-vulnerabilities-927.html
Feel free to post corrections and thoughts on what else we can do.
-igal
Igal Koshevoy
I propose that interested folks here and on, RubyInside,com,
RubyOnRails.com and such go discuss this further on the ruby-talk
mailing list's thread or via its web-based front-end at
http://www.ruby-forum.com/topic/157034
-igal
nicholau...@gmail.com
-----Original Message-----
From: Igal Koshevoy <ig...@pragmaticraft.com>
Date: Sun, 22 Jun 2008 19:18:03
To:pdxruby <pdx...@googlegroups.com>
Subject: [pdxruby] Re: Multiple vulnerabilities in Ruby may lead to a denial
of service (DoS) condition or allow execution of arbitrary code.
Jesse Hallett
Ruby Enterprise Edition is a fork of Ruby MRI created by Phusion, the
makers of Passenger aka mod_ruby. They have backported the security
fixes from ruby-1.8.6-p230, so they claim that EE is not affected by
these vulnerabilities. But EE is based on ruby-1.8.6-p111, so it
shouldn't break any applications. And they offer a deb package that
installs EE in parallel with MRI.
The main downsides of running EE are that you may have to reinstall
all of your gems; and the garbage collector is less efficient than the
one in included in MRI if you are not using Passenger to serve your
app.
Ben Munat
that patches the vulnerabilities without causing a bunch of segfaults
(at least as far as I've seen so far). It's ruby-1.8.6.230-3.fc9 and I
found it here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=54190
Note that you have to install all the same version dependency RPMs along
with it.
b
Igal Koshevoy
Matz says the bug isn't exploitable enough to be able to cause arbitrary
code execution after all, but it's still worth upgrading if you have a
publicly exposed Ruby-based server.
Ruby Enterprise Edition is great, and worth experimenting with.
However, if you're running a reasonably modern OS, your distributor has
probably shipped a patched version. Unfortunately, because the Ruby
maintainers have thusfar refused to provide an official fix or review
the patches, the different variants being shipped have different issues.
For instance, Ruby 1.8.6p230 and later versions break Ruby API
compatibility and thus any patch based on these may fail to run your
existing apps, which is affecting Fedora's version. You're much better
off sticking to the p111 and p114 derived variants, like Ruby Enterprise
Edition and those shipped by FreeBSD, Gentoo, Ubuntu and Debian.
-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
See also:
* RedMine ticket: http://redmine.ruby-lang.org/issues/show/216
* ruby-core thread: http://www.ruby-forum.com/topic/158334
* ruby-talk thread: http://www.ruby-forum.com/topic/157034
Jeremy d
have you tried the recently released ubuntu patch? It did not mention
using the p230 so I'm assuming they put it together by hand.
-Jeremy
Igal Koshevoy
> have you tried the recently released ubuntu patch? It did not mention
> using the p230 so I'm assuming they put it together by hand.
>
for a while. It seems fine.
Current releases of FreeBSD, Ruby Enterprise, Ubuntu, Debian have
shipped patched versions based on p111 with between 6 to 11 total
unofficial patches. Older releases of Ubuntu and Debian ship a patched
version based on p36 with 15 unofficial patches. I believe that Gentoo
is shipping a patched version based on p114. These should all be okay.
However, Fedora was using p230 with the Smartleaf patch to fix segfauls,
but it looks like they'll have to rollback to an backport because of the
memory leak.
The different patch levels and mismatched numbers of total unofficial
patches are problematic because no one has a clear idea of which
combination is "right". The Ruby maintainers have thusfar refused to
review any of these patches and really want us to switch to their latest
versions, which have been plagued with segfaults, incompatible API
changes that no longer run typical Ruby code, memory leaks, etc.
As far as I can tell, the patched versions based on p111 and p114 are
most likely to have the best balance of being compatible, secure and
stable. However, it's worth keeping an eye on ruby-talk and ruby-core
to keep track of what's going on because the situation is rapidly evolving.
-igal
Bob Lehman
Last year we did Really Radical Ruby
This years theme so far as I am aware
Really Ought to do something
P.S That was a joke - as I tell my kids it is quantity of humor not
quality !
Anyway if you are interested in helping out can you drop me a note. I
know there were some others interesting in maybe taking lead roles so I
hope I am not stepping on any toes by sending this out, but people have
been asking what we are going to do. So I thought I would at least see
what is happening.
At Rails I did ask the About Us folks if they would be willing to host
the event at their building, and they were open to the idea. If we want
to do that we should probably start getting coordinated with them.
Other suggestions for venue are of course welcome.
Can you respond back to the list if you are interested. If there gets
to be to much chatter we can take it off line or to some other mechanism.
if you want to reach me directly you can send to bleh...@comcast.net
--Bob
M. Edward (Ed) Borasky
do a half an hour on the latest updates to
https://rubyforge.org/docman/view.php/977/2705/Slides.pdf
I am going to be attempting some C-level profiling on Rubinius this
weekend, and at some point in the not-too-distant future I'm going to
post a HowTo on profiling Ruby interpreters compiled by GCC on a Linux
system. If I get *really* ambitious I'll integrate the whole mess with
Komodo. ;)
Speaking of IDEs, has anybody here done anything significant in Ruby
with Anjuta? Now that I'm running my laptop on openSUSE 11 with a
Gnome desktop, I've been wanting to fool around with Ruby/Gnome
integration.
It doesn't look like I'm going to RubyConf in Orlando -- I may be
going to something else in December.
M. Edward (Ed) Borasky
Igal Koshevoy wrote:
> I believe that Gentoo is shipping a patched version based on p114. These should all be okay.
https://bugs.gentoo.org/show_bug.cgi?id=225465
"------- Comment #48 from r...@gentoo.org 2008-07-03 00:21 0000
-------
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"
Igal Koshevoy
> Guess again on Gentoo: apparently there is another issue. From
> https://bugs.gentoo.org/show_bug.cgi?id=225465
>
Can you please get them to interact with the rest of us on the ruby-core
mailing list? Their patches aren't doing the rest of the Ruby community
any good if they're living in their little silo.
-igal
Igal Koshevoy
> This years theme so far as I am aware
>
> Really Ought to do something
>
I'd be glad to assist. However, I missed the earlier ones and have a
rather limited understanding of what goes on and into these events. Can
you or someone else that's been to previous events give us a rundown of
the sorts of tasks that need to bed done? Having that list will be
helpful because we'll be able to more easily assign smaller,
clearly-identifiable tasks to interested individuals, because right now
it's a bit amorphous. :>
Also, sharing and tracking tasks and planning information on FOSCON may
be a good use of 37Signals Backpack [http://www.backpackit.com/].
> Can you respond back to the list if you are interested. If there gets
> to be to much chatter we can take it off line or to some other mechanism.
>
If traffic gets to heavy, the pdxruby-business may be a good list for
that sort of thing.
-igal
M. Edward (Ed) Borasky
did. Hans de Graaf, to be specific:
[ruby-core:17457] Ruby status on Gentoo
So at least we know they are *reading* ruby-core and occasionally
posting. I'll post a request on the Gentoo bug that they keep the
status flowing to ruby-core. Meanwhile, I'm also going to follow the
latest link and post that.
Do you know if anyone has set up some kind of "continuous
integration?" What would be really nice would be some kind of setup
that continuously downloaded the latest SVN Ruby 1.8.6, compiled it
with debug options and "GCOV" tracing, ran the tests, posted the
coverage results, test results and tracebacks for any crashes. I'm
thinking about attempting this, but if somebody else has already done
it, I'll go back to my profiling stuff (which is similar anyhow).
It's times like this when I wish I knew Rails. :)
Audrey Eschright
On Jul 3, 2008, at 6:23 AM, Igal Koshevoy wrote:
> I'd be glad to assist. However, I missed the earlier ones and have a
> rather limited understanding of what goes on and into these events.
> Can
> you or someone else that's been to previous events give us a
> rundown of
> the sorts of tasks that need to bed done? Having that list will be
> helpful because we'll be able to more easily assign smaller,
> clearly-identifiable tasks to interested individuals, because right
> now
> it's a bit amorphous. :>
I'm too busy to help organize things this year, but here's the basic
outline:
* Date: an evening during OSCON, preferably one without other highly
enticing events
* Venue: somewhere we can drink, eat, and set up a projector. Past
locations have been Free Geek and Holocene. Free Geek is probably not
big enough to handle current demand. Holocene was comfy but we lacked
blackout curtains needed to have a projector in the front room before
dusk last year.
* Format: Short (20 min.) talks on interesting things people are
doing with Ruby. Emphasis on recruiting from OSCON speakers
(practicing scheduled talk or giving alternate that was rejected),
and other interesting guests from out of town.
* Sponsors: to pay for pizza and perhaps a round of beer.
* Advertising and getting people to the venue: we've done walking
tours and taxi service from the convention center in the past. We
were listed in the O'Reilly user group program email last year--I
think Thomas contacted Marsee about that. We also spread the word on
mailing lists and pdx.rb-ers' blogs.
* Door prizes: various publishers have been happy to donate books in
the past.
Audrey
Igal Koshevoy
> So at least we know they are *reading* ruby-core and occasionally
> posting. I'll post a request on the Gentoo bug that they keep the
> status flowing to ruby-core. Meanwhile, I'm also going to follow the
> latest link and post that.
>
> Do you know if anyone has set up some kind of "continuous
> integration?"
I've used Hudson, which is a bit hefty. We've gotten a recommendation to
use CruiseControl.rb. Any others?
> What would be really nice would be some kind of setup
> that continuously downloaded the latest SVN Ruby 1.8.6, compiled it
> with debug options and "GCOV" tracing, ran the tests, posted the
> coverage results, test results and tracebacks for any crashes. I'm
> thinking about attempting this, but if somebody else has already done
> it, I'll go back to my profiling stuff (which is similar anyhow).
>
The script I'm preparing provides much of the wrapping, basically
dumping the results of all the different test suites into a reports
directory. Can you send me instructions on how to get the debug, gcov
tracing, coverage, and whatever else stuff? All I know how to do is
compile Ruby.
> It's times like this when I wish I knew Rails. :)
If you can tell us what shell commands to run, I'm sure we'll figure out
how to wrap them somehow. :)
-igal
M. Edward (Ed) Borasky
On Jul 3, 6:23 am, Igal Koshevoy <i...@pragmaticraft.com> wrote:
>
> If traffic gets to heavy, the pdxruby-business may be a good list for
> that sort of thing.
M. Edward (Ed) Borasky
Then do your "make". This
a. Puts symbols in the object files, so the tools can track down line
numbers.
b. Generates ".gcno" and ".gcda" files in your source tree.
c. Disables all optimizations. So your stuff will run slower than
normal, but if you're profiling, the profiles will be able to find the
lines of code where you're spending the most time.
Then run your tests/benchmarks. The code will update the counters in
the "gcno" and "gcda" files. If you get crashes, you'll probably want
to run the specific tests that crash again using "gdb". You can also
get core dump files and post-analyze them with "gdb", but most people
have a "ulimit" set to prevent core dump files. The counters
accumulate; if you invoke your compiled Ruby multiple times they
represent the total of all those invocations.
After you've run everything, run "gcov". There are a lot of options
for this, but the ones I use are (from a Rakefile)
require 'find'
desc "Make gcovs"
task :make_gcovs do
dest = "#{Dir.getwd}/benchmark_gcovs"
summ = "#{dest}/summary"
mkdir_p dest
rm summ if File.exist?(summ)
cd "/source/directory/where/you/built/ruby"
GCOV="gcov -a -b -l -f "
Find.find(".") do |file_name|
sh "#{GCOV} #{file_name} >> #{summ}" if file_name =~ /\.c$/
end
Find.find(".") do |file_name|
cp "#{file_name}", dest if file_name =~ /\.gcov$/
end
cd ".."
end
M. Edward (Ed) Borasky
export CFLAGS='-g -fprofile-generate -ftest-coverage -O0'
Lennon Day-Reynolds
I'm running ruby-1.8.6-p114, with the 'array', 'intern', 'sprintf',
and 'string' patches from the FreeBSD ports tree
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/) on
our production Rails app cluster, and haven't seen any stability
issues. The patches applied cleanly to my source tree, as well.
I suspect that the Debian/Ubuntu packages are based on a similar set
of patches, but for those running on other platforms (or using their
own Ruby build) this might be an easy way to get the basic security
updates.
-Lennon
P.S.: There are also a number of newer patches in the ports tree that
I haven't had a chance to evaluate. Has anyone else tried the patches
for 'bignum', 'parse', and 'regex'?
M. Edward (Ed) Borasky
since that's one of the things I do quite a bit.
But I think the wider issue is that the BSD ports, Linux distros,
etc., should be getting their source from a tree maintained by the
Ruby community as automatically as humanly possible, rather than the
Ruby community getting its source from BSD ports or Linux distros. :)
Hmmm ... "automatically as humanly possible?" Have I created a new
oxymoron? :)
Igal Koshevoy
>
>> Just to add a data point to the discussion:
>>
>> I'm running ruby-1.8.6-p114, with the 'array', 'intern', 'sprintf',
>> and 'string' patches from the FreeBSD ports tree
>> (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/) on
>> our production Rails app cluster, and haven't seen any stability
>> issues. The patches applied cleanly to my source tree, as well.
>>
>> I suspect that the Debian/Ubuntu packages are based on a similar set
>> of patches, but for those running on other platforms (or using their
>> own Ruby build) this might be an easy way to get the basic security
>> updates.
>>
>> -Lennon
>>
>> P.S.: There are also a number of newer patches in the ports tree that
>> I haven't had a chance to evaluate. Has anyone else tried the patches
>> for 'bignum', 'parse', and 'regex'?
>>
>
> I haven't ... I probably should look at the "bignum" one, though,
> since that's one of the things I do quite a bit.
>
provide working patches for the p111 and p114 series, and most of the
distros are now using their code. The only one distro I know that didn't
was Fedora, which used the Smartleaf patch against p230, but that
solution has been deprecated because the base code of p230 and all
subsequent releases are known to leak memory.
Anyway, I recommend we take these discussions to ruby-core where they'll
help the Ruby community at large. :)
> But I think the wider issue is that the BSD ports, Linux distros,
> etc., should be getting their source from a tree maintained by the
> Ruby community as automatically as humanly possible, rather than the
> Ruby community getting its source from BSD ports or Linux distros. :)
>
Absolutely. Random distro admins should not have to individually decide
which of dozens of unofficial patches to apply.
-igal
Lennon Day-Reynolds
> Anyway, I recommend we take these discussions to ruby-core where they'll
> help the Ruby community at large. :)
I wouldn't presume to have much to offer the Ruby core team with my
anecdotal experiences running an old release of Ruby and unofficial
FreeBSD patchset. If anything, I'd prefer to stay out of the way of
Matz + co. so they can stick to the important business of implementing
my favorite programming language.
> Absolutely. Random distro admins should not have to individually decide
> which of dozens of unofficial patches to apply.
Actually, it's entirely normal for distributions to maintain their own
patches for upstream software. There are a variety of reasons:
packagers don't always have or want upstream commit privs; patches can
be distro or OS-specific in a way that the upstream folks don't want;
security updates get backported to unsupported releases; etc., etc.
I actually tend to agree with Matz that the current Ruby release
process is fine. If you want rock-solid reliability for every update,
or never want to be surprised by API changes, then it's up to you to
do (or pay someone to do) a full QA round on new releases before
rolling them out into production. That may be your Linux distribution,
or Phusion, or someone else, but the point is, it isn't going to be
Matz and the ruby-core team any time soon.
Anyway, I'm happy enough to move on to other topics on this list.
--
Lennon Day-Reynolds <rco...@gmail.com>
http://rcoder.net/
Ben Bleything
> On Thu, Jul 3, 2008 at 1:42 PM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:
> > Anyway, I recommend we take these discussions to ruby-core where they'll
> > help the Ruby community at large. :)
>
> I wouldn't presume to have much to offer the Ruby core team with my
> anecdotal experiences running an old release of Ruby and unofficial
> FreeBSD patchset. If anything, I'd prefer to stay out of the way of
> Matz + co. so they can stick to the important business of implementing
> my favorite programming language.
Amen. This whole "zomg secruity!" episode has resulted in a lot of
people showing up on ruby-core and trying to get Matz et al to change
their procedures. We often forget that there is a strong, established
community of Japanese developers, and what we see on ruby-core is only a
small section of what's actually going on.
I, for one, would be much happier if everyone would chill out and let
the people who are actively working on the language continue to do so as
they see fit. Frankly, all the freaking out on ruby-core has left me
feeling embarassed to be a member of the US Ruby community.
Ben
Igal Koshevoy
Ben and Lennon, I respect you and your opinions, but absolutely can't agree.
Describing the community response as "zomg security", "freaking out" and
"embarrassing" is baffling to me. The maintainers told us that Ruby was
vulnerable to denial of service and arbitrary code execution attacks,
published all the code needed for writing an exploit, then vanished for
over a week without a word or working solution, and still haven't
provided an official fix or reviewed the unofficial patches. These sorts
of failures are enough to get people to switch to other implementations
or languages. I used and loved Perl for 10 years, but had to abandon
ship because of those kinds of mistakes, and I don't want to see that
happen to Ruby.
If you're currently running a patched version of Ruby, it's thanks to
the random new people that showed up and decided to get "in the way" to
create unofficial patches on ruby-talk and ruby-core. If the Ruby code
had been exploitable, their efforts would have been your only defense.
If these folks hadn't let the maintainers do as they "see fit", you'd
have also seen two dead-on-arrival official releases shipped recently
that suffered from memory leaks, bugs, and compatibility breakages.
I'm very glad that these people got in "the way" because they helped
resolve problems and made Ruby healthier. They began publishing fixes
within hours and collaborated to come up with the two patches that most
of us are using. They provided RubySpec, a volunteer effort to describe
the behavior of Ruby, which caught countless bugs and API errors that
would have otherwise made it impossible to run existing code. The
alternative implementation teams jumped in to lend a hand. Folks
transformed vague hearsay off blogs into reproducible tests that the
Ruby maintainers then used to fix bugs. They delivered automated build,
testing, and profiling systems to make it easy for the maintainers and
others to assert the quality their code. Matz, Shyouhei and the other
Ruby developers are better off because they have more tools, test
suites, and people to help them. They're working more closely with the
community to review code and changes before these are shipped. They've
expressed their intent to deliver compatible, quality Ruby releases. All
of this happened thanks to this community response.
> Frankly, all the freaking out on ruby-core has left me
> feeling embarassed to be a member of the US Ruby community.
Sorry to hear that. Frankly, all the recent contributions on ruby-talk
and ruby-core have left me feeling inspired by the English-speaking Ruby
community, and upbeat about Ruby and MRI's future.
-igal
Ben Bleything
> Ben and Lennon, I respect you and your opinions, but absolutely can't agree.
>
> Describing the community response as "zomg security", "freaking out" and
> "embarrassing" is baffling to me. The maintainers told us that Ruby was
> vulnerable to denial of service and arbitrary code execution attacks,
> published all the code needed for writing an exploit, then vanished for
> over a week without a word or working solution, and still haven't
> provided an official fix or reviewed the unofficial patches. These sorts
> of failures are enough to get people to switch to other implementations
> or languages. I used and loved Perl for 10 years, but had to abandon
> ship because of those kinds of mistakes, and I don't want to see that
> happen to Ruby.
The only mention of arbitrary code execution I saw was one of the Ruby
maintainers (can't remember if it was Matz or not) saying that they
believed it was *not* an issue. I still haven't seen it demonstrated.
Too often a vulnerability is discovered and people leap to the
conclusion that it is an execution vulnerability.
Do you watch ruby-dev? Was that list silent during the quiet period?
I don't read Japanese so I don't know the answer to that question. I
did scan the subject lines for a few days and it looked like there was
plenty of discussion.
We seem to forget that we're using a language that is actively being
developed by Japanese people, in Japanese, in Japan. We assume that
if we're not made aware of something by Matz himself that it is not
happening. In my experience, that has never been the case. There is a
cultural difference there, and we shouldn't expect Ruby's maintainers to
necessarily behave the way that we want.
> If you're currently running a patched version of Ruby, it's thanks to
> the random new people that showed up and decided to get "in the way" to
> create unofficial patches on ruby-talk and ruby-core. If the Ruby code
> had been exploitable, their efforts would have been your only defense.
> If these folks hadn't let the maintainers do as they "see fit", you'd
> have also seen two dead-on-arrival official releases shipped recently
> that suffered from memory leaks, bugs, and compatibility breakages.
Let me be clear: I don't have any problem with people reporting bugs and
submitting patches. You're absolutely right that it was solely due to
community effort that there are patches out there for these problems.
What bothers me is the attitude of entitlement displayed by a number
of people on the ruby-core list. Clamoring for new release management
policies, demanding that certain patches be applied or reverted,
requesting that releases be delayed... all of these things have happened
in the last two weeks on ruby-core, ruby-talk, IRC, blogs, twitter,
etc. These are examples of the presumptiveness that I think Lennon was
talking about, and that is what embarasses me.
Igal, it's important to me that you know that I'm not talking
specifically about you, because I know that it seems that way from the
context. It's everybody who has, for lack of a better phrase, been all
talk and no code in these threads. It's not that I don't understand or
am not sympathetic to the issues at hand. It's also not that I'm the
kind of guy who ignores issues and shouts "patches welcome!"
It's just that I perceive(d) a strong sense of indignation that the
needs of the community were not being met. This, of course, is up for
interpretation... it is my (perhaps vain) belief that Matz & Co. are
always diligently working to make Ruby the best it can be. They are all
much smarter than I am, and I trust that when issues like these come up,
they are being handled.
I'm aware that many other people do not share that attitude, but until
it's been proven to be wrong I'm going to continue believing :)
> I'm very glad that these people got in "the way" because they helped
> resolve problems and made Ruby healthier. They began publishing fixes
> within hours and collaborated to come up with the two patches that most
> of us are using. They provided RubySpec, a volunteer effort to describe
> the behavior of Ruby, which caught countless bugs and API errors that
> would have otherwise made it impossible to run existing code. The
> alternative implementation teams jumped in to lend a hand. Folks
> transformed vague hearsay off blogs into reproducible tests that the
> Ruby maintainers then used to fix bugs. They delivered automated build,
> testing, and profiling systems to make it easy for the maintainers and
> others to assert the quality their code.
I too am thankful for the people who stepped up and contributed. I
should point out, though, that all of the things you mentioned are
things that have either already existed for some time or have been asked
for in the (sometimes distant) past and just didn't happen until now.
Don't get me wrong, I'm glad they're here and whatever the impetus,
they're still valuable.
What I object to is people who complain and don't contribute... and
I don't mean just code contributions. As a convenient example, the
work that you (Igal) did on determining which patchsets were good and
which needed love, and tracking down the memory leaks were very helpful,
there's no doubt about it. In fact, for all I know you did a bunch more
after that, but I stopped paying attention because the threads were
making me angry.
> Matz, Shyouhei and the other Ruby developers are better off because
> they have more tools, test suites, and people to help them. They're
> working more closely with the community to review code and changes
> before these are shipped. They've expressed their intent to deliver
> compatible, quality Ruby releases.
Very true. I just don't think that this was ever *not* the case.
> Sorry to hear that. Frankly, all the recent contributions on ruby-talk
> and ruby-core have left me feeling inspired by the English-speaking Ruby
> community, and upbeat about Ruby and MRI's future.
I'm sorry if my original email seemed like an attack. It wasn't meant
to be directed at anyone in particular.
Ben
Igal Koshevoy
> The only mention of arbitrary code execution I saw was one of the Ruby
> maintainers (can't remember if it was Matz or not) saying that they
> believed it was *not* an issue. I still haven't seen it demonstrated.
> Too often a vulnerability is discovered and people leap to the
> conclusion that it is an execution vulnerability.
>
to the Ruby homepage announcement whose title is "Arbitrary code
execution vulnerabilities". This same announcement has been linked at
most Ruby news sources. As for Matz's follow-up, he admitted that there
were severe problems but not as critical as originally announced,
however, he made that 11 days after the first information came out.
> Do you watch ruby-dev? Was that list silent during the quiet period?
I did, and there was silence for about a week. Admittedly, they began
discussing it a day after it occurred to me to post to ruby-dev. I don't
know if they simply didn't think this was a big deal until then, or
whether they didn't know about the problem because they weren't
monitoring the two official English-language Ruby bug trackers, nor the
mailing lists, news sources, etc.
> We assume that if we're not made aware of something by Matz himself that it is not happening.
I think that most people, including me, just wanted someone from the
official team tell us that they were aware of the problem and were
working on it. There was great relief when Shyouhei appeared.
> What bothers me is the attitude of entitlement displayed by a number
> of people on the ruby-core list. Clamoring for new release management
> policies, demanding that certain patches be applied or reverted,
> requesting that releases be delayed... all of these things have happened
> in the last two weeks on ruby-core, ruby-talk, IRC, blogs, twitter,
> etc. These are examples of the presumptiveness that I think Lennon was
> talking about, and that is what embarasses me.
>
> It's just that I perceive(d) a strong sense of indignation that the
> needs of the community were not being met. This, of course, is up for
> interpretation... it is my (perhaps vain) belief that Matz & Co. are
> always diligently working to make Ruby the best it can be. They are all
> much smarter than I am, and I trust that when issues like these come up,
> they are being handled.
>
I apologize for the misunderstanding. I didn't catch those distinctions
in your earlier message.
I'm grateful to Matz and his team, but many people are relying on them
to provide stable, backwards-compatible releases and timely responses to
critical problems. If they don't have the resources to provide this,
they should consider asking for donations, accepting volunteers, or
endorsing some 3rd party effort
Because the p230 release failed, many people got involved -- some were
more helpful than others. The folks suggesting process improvements
offered ideas that would make future releases smoother. The folks that
asked to delay releases had identified critical bugs that the
maintainers hadn't noticed or prioritized. I felt that most of these
comments were well-meaning requests and suggestions, maybe you
interpreted them as orders?
> What I object to is people who complain and don't contribute... and
> I don't mean just code contributions. As a convenient example, the
> work that you (Igal) did on determining which patchsets were good and
> which needed love, and tracking down the memory leaks were very helpful,
> there's no doubt about it. In fact, for all I know you did a bunch more
> after that, but I stopped paying attention because the threads were
> making me angry.
>
Thanks. However, you may have been frustrated because many of those that
got involved -- including me -- lacked the context, time and ability to
contribute enough, so you saw more half-baked opinions thrown around
than fully-featured solutions. Thankfully, despite these limitations and
scattered bits of knowledge, I was impressed by how people in those
lists were able to work together and created solutions greater than they
could have made on their own.
-igal