Live data from Hacker News

Rails SQL injection vulnerability: here are the facts

blog.phusion.nl

11–20 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#11
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.

I'm not quite sure what you're hinting at. I know there's been found a DoS-exploit related to the parameter handling (expect a new security release soon), but at least it seems to be safe to say that this bug can't be triggered from `params`.

Re: Rails SQL injection vulnerability: here are the facts

#12
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 quite apparent that Ruby code is much less maintainable, over the long term, than Java code is.

This same attitude was shown when it came to Ruby's performance. Many of us had serious misgivings about just how poorly it performed, and the suitability of Ruby on Rails for anything beyond simple sites. Then when some Ruby on Rails sites started facing moderate traffic, they basically collapsed. The answer from the Rails advocates was to "throw more hardware at it".

We even saw this same attitude when it came to this very issue. We'd heard about how Ruby on Rails is far more "secure" than alternatives. Yet that's proven not to be the case.

When Rubyists make claims, it's best to doubt what they're saying, and to question every single detail about it. They have given themselves a bad reputation for making incorrect statements.

Re: Rails SQL injection vulnerability: here are the facts

#13
This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails.

Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.

Re: Rails SQL injection vulnerability: here are the facts

#14
post #11
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.

I'm not quite sure what you're hinting at. I know there's been found a DoS-exploit related to the parameter handling (expect a new security release soon), but at least it seems to be safe to say that this bug can't be triggered from `params`.

We may be talking about the same parameter handling condition, or two different ones.

Re: Rails SQL injection vulnerability: here are the facts

#15
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…

I wasn't making a language war claim. Every platform has security bugs.

Re: Rails SQL injection vulnerability: here are the facts

#16
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…

Not sure where you got the idea that it's a "smug attitude". The article explains the facts and adds some commentary, nowhere did it claim that the bug does not exist or that one should not upgrade. Its intention is provide the facts and details of the exploit to counter the FUD coming from incomplete information and knee-jerk reactions. The bug is taken very seriously.

Re: Rails SQL injection vulnerability: here are the facts

#17
post #13

This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails. Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.

Early versions of Rails explicitly made the decision to never symbolize user inputted hashes because symbols are never garbage collected. This would allow memory to grow unbounded. As a result Rails stores all user hash keys as strings.

Re: Rails SQL injection vulnerability: here are the facts

#18
post #8
post #4

The author wastes a lot of breath refuting claims that this is a huge Rails bug, then finally comes clean 3/4 of the way in: Other exploitable scenarios Your code is vulnerable if you call Foo.find_by_whatever(bar), where bar can be an arbitrary user-specified hash with symbol keys. This is a fundamental flaw that requires a very specific set of circumstances (which the Rails community is clinging to as a get out of…

Python's Pickle is insecure by design. It causes application-specific vulnerabilities the way bad crypto libraries do, by giving developers a tool to blow their feet off with. It's hard to blame Python too much for that; languages are going to provide unsafe libraries. This, on the other hand, is just a Rails bug. It has a simple fix. That fix is provided transparently by Rails. It isn't going to cause "lots of appli…

Note that I didn't refer to the Pickle issue as a bug. I think its quite a useful feature, but it's still a pointy stick that many have fallen on.

Re: Rails SQL injection vulnerability: here are the facts

#19
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…

I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own.

I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?

Re: Rails SQL injection vulnerability: here are the facts

#20
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…

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 ponderous, enterprisey projects. Ruby is designed for rapid, agile development. So we don't need a "war" here; they serve different, equally important niches.

I agree that there are performance issues with Ruby implementations such as the MRI. That's really part and parcel of an immature implementation, that is, it hasn't received the millions of developer man hours spent fine-tuning it, such as the Java ecosystem has received. However, I would observe that it's still easy to get Java performance very wrong. It turns out that efficient GC is hard -- really, really hard.

Post reply on HN