Live data from Hacker News

Rails SQL injection vulnerability: here are the facts

blog.phusion.nl

51–60 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#51
post #27
post #26

Earlier quoted context omitted.

So you don't have a curl command that exploits it, but you don't believe the authors. That leaves us with what?

Apparently, it leaves you waiting for an upcoming Rails advisory.

Well I should apologize, i didn't realize the comments were from a seasoned security researcher. I don't know the first thing about vulnerability testing, I just make reasonable precautions in code that I write. If you and others have spent time doing actual vulnerability testing, then I have to defer.

Re: Rails SQL injection vulnerability: here are the facts

#52
post #42

Earlier quoted context omitted.

There are also things a specific app could be doing that could unwittingly trigger the vulnerability as well. The core issue is worse than simply requiring the session key to be kept secret (which by itself would probably p0wn most apps much worse than the potential exploit of this vulnerability) because the dynamic finder option handling is unexpectedly a magical mine-field that no one would expect to behave that wa…

I would love to see an example in the wild of someone taking user input, running some logic on it to create a hash with symbols and then passing it to this finder. So far noone can give an example, but Rails developers have proactively found this not very exploitable bug and patched it. Yet the attitude seems to be backwards to me. The attitude should be that an edge cause was proactively fixed and there was no known…

I'm in agreement it's unlikely, but I think it's important to acknowledge that it's conceivable.

Re: Rails SQL injection vulnerability: here are the facts

#53
thanks for this, phusion.

I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention.

The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just led to the current hysteria instead. They would have been better off being taking the extra time to be fully transparent about the nature of the vulnerability -- developers need to know to assess their own risk, as well as to judge the quality of Rails (how stupid was the problem exactly, what does it say about Rails etc?), etc. By being vague about it, Rails core team has just led to everyone assuming the worst, and the current weird hysteria.

Yes, it's a vulnerability which COULD be dangerous, and it's hard to tell FOR SURE if your app is vulnerable (perhaps due to code in gem dependencies), the only safe thing to do is update to a patched version. But the chances that your app is vulnerable are pretty small (if you aren't using AuthLogic; if you are, you can update auth_logic and fix it whether or not you update rails). And past recent vulnerabilities which were actually MORE dangerous have not received this level of attention.

Re: Rails SQL injection vulnerability: here are the facts

#54
I'm starting to wonder if the DRY-uber-alles notion popularized by Rails is turning into a security antipattern. It's just too easy for code like this (intended to "make things work cleanly") to forget all the needed checks and all the constraints on the design.

The end user ends up repeating themselves less, but that means that the library code ends up getting used in lots of places and for lots of purposes that the author didn't necessarily think through...

Re: Rails SQL injection vulnerability: here are the facts

#55
the other thing to note is that if your application is deserializing untrusted input using Marshall.load and calling methods on the deserialized objects then there is a chance that you are vulnerable to arbitrary ruby code execution. in that case an attacker could execute whatever sql he wanted to anyway.

Re: Rails SQL injection vulnerability: here are the facts

#56

Earlier quoted context omitted.

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…

It's unfair to say that the core language is flawed. Maintainability depends on how the language features are utilized. Some code uses monkey-patching gratuitously and that can harm maintainability, but judicious use of monkey patching is not a problem. On the other hand, maintaining a several gigabyte Java project can be a nightmare. Code bloat is certainly a factor here. Java is probably better for larger, more pon…

One man's elegance is another man's obfuscation.

Re: Rails SQL injection vulnerability: here are the facts

#57

Earlier quoted context omitted.

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…

Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.

Well said.

Re: Rails SQL injection vulnerability: here are the facts

#58
post #9

This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote. Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…

Our Rails site successfully served 45k simultaneous requests for the National Moment of Silence two weeks ago. I call that moderate traffic, and we didn't fall over. Please stop assuming that no one can make Rails scale just because there are some popular stories of it not scaling.

Re: Rails SQL injection vulnerability: here are the facts

#59

Earlier quoted context omitted.

This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…

Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.

Thank you, Peter.

Re: Rails SQL injection vulnerability: here are the facts

#60

Earlier quoted context omitted.

Maybe. If so, it's only slightly more bearable than the attitude of many observers towards what or how they think "the Ruby community" collectively believe, do, or act. There's no singular Ruby community anymore than there's a C, PHP or "Linux community" whose behavior can be collectively judged.

Thank you, Peter.

I was convinced of your way of thinking, eventually ;-)
Post reply on HN