Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails SQL injection vulnerability: here are the facts

blog.phusion.nl

Post reply on HN
Print view View original

31–40 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#31

Post by amalag »

tptacek wrote: post #27
amalag wrote: 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.

Apparently some people don't like Rails and love to see an obscure bug that requires the secret session key, therefore they think their cherished and strongly held dislike will finally bask in smug glory.

Edit: I shouldn't have been so harsh since the author is a security researcher and is probably not doing it out of some grudge. But even from a security researcher, saying he has doubts about a software doesn't make something insecure.

If he can prove his statement that he thinks regular user input is insecure (without requiring the secret session key), then I will happily be convinced of his prowess in finding exploits.

Re: Rails SQL injection vulnerability: here are the facts

#32

Post by amalag »

dsl wrote: 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…

Yes except that bar cannot be from params since params will never return symbols as keys.

So it is pretty obscure unless you take user input and do something pretty special to make it return symbols and then run find_by_whatever on it.

Re: Rails SQL injection vulnerability: here are the facts

#33

Post by amalag »

dasil003 wrote: post #29
dsl wrote: 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…

It's not a matter of anyone egotistically "clinging" to something. The fact is that user params come in with string keys, so an app has to be doing something unusual to be vulnerable. This drastically cuts down the number of vulnerable apps. It is what it is.

The fact of the matter is people don't know enough about Rails to know what this means and like to go with the easier to spread story: "Rails vulnerability found in all versions related to user input"

Sounds much more sexy and they can do more Rails bashing that way. The fact is true as you and the article says, it's pretty obscure. In addition to being obscure, you need the secret session key.

Re: Rails SQL injection vulnerability: here are the facts

#34

Post by petercooper »

PommeDeTerre wrote: post #12
tptacek wrote: 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…

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.

Re: Rails SQL injection vulnerability: here are the facts

#35

Post by mikeash »

amalag wrote: post #26
tptacek wrote: 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.

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

This leaves us with assuming that remotely triggered bugs can be exploited until proven otherwise, the way a sane person would.

Re: Rails SQL injection vulnerability: here are the facts

#37

Post by why-el »

Jgrubb wrote: post #2

I swear I saw this same bug discussed on Reddit from some security mailing list last week, unless this is another SQL injection vulnerability with Authlogic.

It was also emailed to the Rails Core mailing list, thats where I read about it first.

Re: Rails SQL injection vulnerability: here are the facts

#38

Post by alinajaf »

amalag wrote: post #31
tptacek wrote: post #27

Earlier quoted context omitted.

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

Apparently some people don't like Rails and love to see an obscure bug that requires the secret session key, therefore they think their cherished and strongly held dislike will finally bask in smug glory. Edit: I shouldn't have been so harsh since the author is a security researcher and is probably not doing it out of some grudge. But even from a security researcher, saying he has doubts about a software doesn't make…

I'm a full time rails developer and member of the "ruby community" and have nothing against rails. I am also strongly inclined to take tptacek at his word when he speaks on issues of security, even if he's light on the details. It's quite literally free consulting.

EDIT in response to upsteam edit: He did imply that you should wait for the upcoming Rails advisory, so you'll get your proof then.

Re: Rails SQL injection vulnerability: here are the facts

#39

Post by dasil003 »

amalag wrote: post #33
dasil003 wrote: post #29

Earlier quoted context omitted.

It's not a matter of anyone egotistically "clinging" to something. The fact is that user params come in with string keys, so an app has to be doing something unusual to be vulnerable. This drastically cuts down the number of vulnerable apps. It is what it is.

The fact of the matter is people don't know enough about Rails to know what this means and like to go with the easier to spread story: "Rails vulnerability found in all versions related to user input" Sounds much more sexy and they can do more Rails bashing that way. The fact is true as you and the article says, it's pretty obscure. In addition to being obscure, you need the secret session key.

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 way.

So I'd characterize it as a serious problem, but not widespread in the wild, and also with some unknown risk that another major gem like AuthLogic could be as-of-now unknowingly extending the footprint of the vulnerability.

Re: Rails SQL injection vulnerability: here are the facts

#40

Post by amalag »

phillmv wrote: post #19
PommeDeTerre wrote: post #12

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…

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?

It all depends on the writing style of the app. If someone writes the entire app as learning exercise in metaprogramming, then I am guessing it will be a nightmare to maintain.
Post reply on HN