Ruby Security Patches Lead to Segfaults(ruby-forum.com)
ruby-forum.com
Ruby Security Patches Lead to Segfaults
http://www.ruby-forum.com/topic/157034#693698
4 comments
freebsd apparently agrees with you. They back ported the security fixes instead of syncing up with the latest version.
http://www.freshports.org/lang/ruby18/
Maybe this is a lesson not to blindly use ruby without going through a trusted distributor. Not unlike linux?
http://www.freshports.org/lang/ruby18/
Maybe this is a lesson not to blindly use ruby without going through a trusted distributor. Not unlike linux?
Not just freebsd, of course. Backporting patches is standard practice for all the serious Linux distributors as well.
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?
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.
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.
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.
It's in place for Hacker News because when your site gets owned by a cracker, you can't do much hacking, can you? :)
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.
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.
So then, in your opinion, IS there a difference between a language that is "production," ready, and one that is not? And if so, what is it?
would this strengthen the case for jruby and ironruby (at least for server/app code, perhaps not for quick scripts) ?
What doesn't kill Ruby should hopefully make it stronger.
"Ruby Enterprise Edition" has a copy of the relevant patch here: http://blog.phusion.nl/assets/r8ee-security-patch-20080623.t...
[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.
[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.
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.