Not-quite-full disclosure

[bascule]

The core team behind the Ruby language just found some rather pathetic security vulnerabilities in their array implementation. It seems the maximum size of arrays was being checked improperly and could be exploited through an integer overflow.

Keeping with their standard retarded practices though, the exact nature of the vulnerability was not disclosed:

http://www.ruby-lang.org/en/news/200...lnerabilities/

Instead the announcement contains vague references to "a denial of service (DoS) condition or allow execution of arbitrary code."

Of course, then someone else looks at what they patched, and you can get the real story:

http://www.zedshaw.com/rants/the_big...abilities.html

Doesn't it seem silly not to spell this out in the first place?

That's not to mention: one guy committed all the patches and no one else modified them. Knowing the core Ruby developers, it's pretty likely no one bothered to even look at the patches, much less QA them. Are the vulnerabilities even fixed? Who knows...

[d.fi]

Re: Not-quite-full disclosure

The real groaner is that since at least 04.05.2006 the core ruby community has known there are serious security problems with the way memory allocations are handled in the interpreter. They choose to largely ignore them in the 1.8.X code. In general the coding practices in the ruby implementation leave a lot to be desired with regard to security.

Around the same time an unsung security guy (me) tried to get the core ruby community to embrace full disclosure, but they choose to attack and reject me from their community rather than do the right thing. I think the only reason they created the security contact for ruby was so vulnerability reports would not be posted to ruby-core, that way they could keep the details private. Nice.

[bascule]

Re: Not-quite-full disclosure

To further complicate things, there are two lists for core maintainers: ruby-core, which is in English, and ruby-dev, which is the inner sanctum of Ruby development and all conversations occur in Japanese.

[jedi]

Re: Not-quite-full disclosure

A company that focuses on static analysis of code has an effort for using their tool for open source projects.

http://scan.coverity.com/index.html

Apparently, they ran ruby through their software as a part of the initial effort to demonstrate what they can offer to the open source community:

http://scan.coverity.com/first-year.html

and though there apparently was some initial interest in addressing these issues:

http://on-ruby.blogspot.com/2006/04/...-and-ruby.html

it doesn't look like there's been any work towards resolving issues since they were first scanned:

http://scan.coverity.com/rung1.html

This lack of interest in solving known issues is another reason why ruby is not a language I choose to write in.

[d.fi]

Re: Not-quite-full disclosure

Coverity's scanner only picks up certain classes of vulnerabilities, and in fact it did not find the integer wrap issues that are the basis of most the recent vulnerabilities. I know this because I commented on ruby-core that it was amusing that the scan did not turn up these known issues. Many of the issues flagged by Coverity were non-issues, but I am sure there were a few that were not fixed but should have been.

Ruby is a fantastic, highly productive language. However, the core community behind it and rails need to come into this decade with regard to security.

A company that focuses on static analysis of code has an effort for using their tool for open source projects.

http://scan.coverity.com/index.html

Apparently, they ran ruby through their software as a part of the initial effort to demonstrate what they can offer to the open source community:

http://scan.coverity.com/first-year.html

and though there apparently was some initial interest in addressing these issues:

http://on-ruby.blogspot.com/2006/04/...-and-ruby.html

it doesn't look like there's been any work towards resolving issues since they were first scanned:

http://scan.coverity.com/rung1.html

This lack of interest in solving known issues is another reason why ruby is not a language I choose to write in.

[jedi]

Re: Not-quite-full disclosure

Coverity's scanner only picks up certain classes of vulnerabilities, and in fact it did not find the integer wrap issues that are the basis of most the recent vulnerabilities. I know this because I commented on ruby-core that it was amusing that the scan did not turn up these known issues. Many of the issues flagged by Coverity were non-issues, but I am sure there were a few that were not fixed but should have been.

Ruby is a fantastic, highly productive language. However, the core community behind it and rails need to come into this decade with regard to security.

Coverity's product does require some level of integration in order to use some of it's more advanced features. Look at the Rung 2 results as an example. Taking the opportunity to address the known problems and do some integration work would allow them to get better results out of the scans. I'm not championing Coverity as the best tool, just pointing out that the ruby folks didn't take the effort behind the scan seriously imho.

And I agree with you about it being a productive language, but I also feel that way about other languages. Just expressing a preference for not using it.

[bascule]

Re: Not-quite-full disclosure

To make things even worse, I've been hearing reports of people experiencing VM segfaults with their Rails applications after upgrading to the new release that supposedly fixes the vulnerabilities... always a good sign.

[d.fi]

Re: Not-quite-full disclosure

Seems the only working combination is ruby 1.8.7 p22 and rails 2.1, other than a few package managers that have hacked some work-around patches.

Yes, it is an excellent sign of the little care the core group has for its primary user base.

I have to say, my first attempt to fix the integer wrap issues in the allocation macros back in 2006 seemed to work, but I actually found some odd cases where it caused problems. The real problem is the allocation macros should be functions, so they can have sanity checks without the high risk of side affects you get in C macros. Macros are actually the devil in 99% of the cases where they are used. However, I am not saying that is what is causing all the segfaults in the current set of patches. I have not bothered to look.

[bascule]

Re: Not-quite-full disclosure

Seems the only working combination is ruby 1.8.7 p22 and rails 2.1, other than a few package managers that have hacked some work-around patches.

Yes, it is an excellent sign of the little care the core group has for its primary user base.

Let me reiterate what a truly shitty situation this is to be in. The version of Ruby 1.8.6 the supposed security fixes were applied to includes some untested and broken changes. When you try to run Rails, it triggers the bug and crashes the interpreter. AWESOME! So Ruby 1.8.6 is out if you want the security fixes...

Ruby 1.8.7 introduced many changes which broke backwards compatibility. Ruby calls point releases "TEENY" but 1.8.6 -> 1.8.7 was anything but. The Ruby core team backported all sorts of changes to the core language from Ruby 1.9 to begin "encouraging" people to make their programs compatible.

Rails 2.1 also introduces backwards incompatibilities, particularly in the plugin architecture.

So, your choices are: Run a vulnerable version of Ruby, or update your code to be Ruby 1.8.7 / Rails 2.1 compatible.

Ugh...