Matasano Chargen - Latest Comments in Ruby’s Vulnerability Handling Debacle

Re: Ruby’s Vulnerability Handling Debacle

Max Caceres — Wed, 02 Jul 2008 17:57:08 -0000

@Chris: ruby has release branches. My understanding is that by the time the security fixes were applied there were other unreleased changes in them. In trying to respond quickly to the vulnerabilities the releases were cut with these other changes in them.

Re: Ruby’s Vulnerability Handling Debacle

Carey — Wed, 02 Jul 2008 17:54:02 -0000

Chris, it’s really easy to create a branch or tag from an arbitrary Subversion revision, without needing to roll back the checked out copy at all. See the example at the end of: http://svnbook.red-bean.com...

I have to admit that this has made me a bit lax about tagging releases on internal projects.

Re: Ruby’s Vulnerability Handling Debacle

Chris — Wed, 02 Jul 2008 17:21:55 -0000

Did I read that correctly? Ruby maintainers didn't have a release branch, so they patched the latest dev build and threw it out there, thinking there would be no problems?

Even without a branch, couldn't they have just rolled back to whatever revision corresponded to the release date, created a branch after the fact, and patched from there?

While Ruby is no Java in terms of maturity, it's still been around for long enough where there should be a more robust development/test process.

Re: Ruby’s Vulnerability Handling Debacle

Stephane Grenier — Wed, 02 Jul 2008 14:16:27 -0000

Hi Max,

You're right, I'm not implying that going mainstream is a bad idea, it's a good thing! :) And they've done a good job so far.

All I'm saying is that getting to the next level means that you'll lose a lot of your flexibility and speed. The more adoption a language has, the more luggage it needs to support. And don't forget that if Ruby supports Rails, Rails supports other websites.

Something else I'd like to quickly note, I believe that a lot of the excitement about RoR also stems from the fact that most RoR implementations are new, and they don't have to support legacy monsters. Give it another 5 years and it will be in the same boat as all the other more "mature" languages.

And this is not a bad thing, it's just something we all need to be aware of. Getting to that stage is a very good thing, it means you have a great product/language that's benefiting many people!

Re: Ruby’s Vulnerability Handling Debacle

Max Caceres — Wed, 02 Jul 2008 12:46:31 -0000

@Stephane: agreed, although I don't think becoming more mainstream is a bad thing (not that you were implying that). The fact that there's a substantial level of attention highlights the fact that the Ruby team has done a great job so far.

@Adam: I don't know, and it is surprising in a number of ways. Testing seems to be ingrained within the Ruby ethos, most Ruby projects come with great test suites that can be run very easily.

To be clear though, I think Ruby releases do get tested before GA, the problem is that Rails is not part of these tests.

Re: Ruby’s Vulnerability Handling Debacle

Adam — Wed, 02 Jul 2008 11:06:50 -0000

Since 2 of your three are targeted at software creators, I'm surprised that you don't list "test the hell out of your releases" or "be transparent about your test process."

Why isn't Rubyonrails part of the Ruby test suite?

Re: Ruby’s Vulnerability Handling Debacle

Stephane Grenier — Wed, 02 Jul 2008 11:04:55 -0000

This seems to be something that needs to be learned, relearned, and relearned again. People complain that they want a fast and agile system, and that's great. However as a system becomes more mainstream, some processes have to be built to verify that it still works for everyone.

When Ruby existed before Rails (RoR) it didn't matter that much. However now that you have more and more people jumping in, the speed of changes must slow down.

It's interesting to see the parallels between Ruby and Java. Early on Java was able to make bigger and quicker changes because it had a smaller community. Now, after over a decade, changes take more time, require more testing, and better adoption by the whole community.

Don't think this won't eventually happen to Ruby if it becomes mainstream. Eventually the speed of change will have to slow down to make sure nothing gets broken along the way. Breaks like this will become unacceptable.

Bleeding edge is great, but it has its costs. As long as the benefits outweigh the costs, it's all great!

Re: Ruby’s Vulnerability Handling Debacle

Yeah — Wed, 02 Jul 2008 04:50:32 -0000

This is why meta meta meta meta self hacked on hacked object building helper do it all syntax fletching projects fail.

Re: Ruby’s Vulnerability Handling Debacle

Drew Yao — Tue, 01 Jul 2008 17:23:57 -0000

That test case would have triggered a different bug, an integer overflow, prior to Mac OS X 10.5.4.

In the patched official version of ruby, it would trigger a separate bug (dangling pointer after realloc). This bug never existed in the Apple-shipped version of Ruby.

Re: Ruby’s Vulnerability Handling Debacle

Eric Monti — Tue, 01 Jul 2008 16:12:01 -0000

@Drew

May want to double check that. The string concatenation segfault I pasted into my post (http://www.matasano.com/log... was created using the stock ruby interpreter on OS X Leopard.

Re: Ruby’s Vulnerability Handling Debacle

Drew Yao — Tue, 01 Jul 2008 15:53:33 -0000

"In fact, one of the test cases showed that the official release missed one of Drew’s patches."

To clarify, that(crash when concatenating a string to itself) was a regression introduced in the latest version. It's fixed by http://svn.ruby-lang.org/cg...
which is not yet in a released official version.

The version of Ruby shipped with Mac OS X is not affected because it never had that regression.

Re: Ruby’s Vulnerability Handling Debacle

mac — Tue, 01 Jul 2008 14:57:35 -0000

Guess this is why metasploit has started segfaulting.