...which further proves my point that Ruby is a bad, bad platform choice for production applications right now. You just can't have this level of insecurity, sloppiness, and unresponsiveness among the developers in a platform you would use for serious applications. Maybe one day Ruby, Rails, et al. will be ready for prime time, but it's just not now, IMO.
update: by Ruby I mean the standard Matz codebase.
So apps written in C never segfault? Proprietary platforms always have great tech support? Other programming languages always have same-day fixes? I won't make any particular claims about Ruby, but I have yet to see The Perfect Language. Every language in the world is "bad, bad platform choice" given some criteria.
Moreover, from reading the advisories and comments, the only thing I can tell for certain is that you can kill a Ruby process with something like "Array.new[0x7fffffff]=0". The only way that's going to take down a Rails app is if you're putting unchecked user input directly into array indices -- but then, if you're doing that, you're probably in trouble anyway.
Or if you're running a setup like Heroku, and you let users run a Ruby console. (Maybe. I don't actually know how Heroku works.) To the nearest percent, that describes 0% of Rails apps.
Can anybody describe how this would actually be used to attack a typical website running Rails?
String is vulnerable too. You'd be hard pressed to write a useful program that didn't put user-provided data into Strings.
An attacker could study the code paths of popular ruby based open-source projects to craft special attack inputs that exploit the weaknesses in Array and/or String.
That sounds a little out of place for Hacker News.
As a hacker with the freedom to be creative with how I work on web applications, I can choose Ruby because I'm not an enterprise architecture astronaut working on Serious Applications.
The ruby thing was annoying but hasn't stopped me writing and deploying web apps in Rails. Hopefully it won't happen again.
Its completely open. I have the source code and the commit logs for the project. I can read the vulnerable code myself and make up my own mind about the potential attack vectors.
Right. Open source languages become popular not by describing and fixing security holes promptly, but by having their super-users analyze patch notes for vulnerabilities, and code around them. The sure fire path to widely used, production ready releases.
All languages and their libraries have vulnerabilities, many not yet discovered.
Instead of living in perpetual fear of being hacked, I'm out there doing what is more important to me: creating great web applications that users want to use, in a language I love using.
[from a quick skim of the patch:] The changes to array.c and string.c look pretty worrying, seems like there are unchecked error conditions that aren't too hard to exploit, possibly allowing buffer overflows in String.... e.g. any code where the attacker could specify the right-hand-side argument to the in-place string concatenation operators (String#concat and String#<<) may be affected. Most string concatenations probably aren't in-place (using String#+ instead), but there's probably at least a handful of in-place string concats in popular packages like Rails.
The "Ruby Enterprise Edition" team has backported their patches too.
Watch out if you have a non-standard directory though. For some strange reason --with-prefix= didn't work for me and I had to manually change the prefix in the configure script.
update: by Ruby I mean the standard Matz codebase.