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

41–50 of 121 posts

Re: Rails SQL injection vulnerability: here are the facts

#41

Post by amalag »

mikeash wrote: post #35
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?

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

The post states that it is not exploitable through user input via params. They could show you the source code, but I don't know if that would be proof for you. You said that you are assuming it can be exploited, so someone should show it.

Re: Rails SQL injection vulnerability: here are the facts

#42

Post by amalag »

dasil003 wrote: post #39
amalag wrote: post #33

Earlier quoted context omitted.

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 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 exploit of this in the wild.

Re: Rails SQL injection vulnerability: here are the facts

#43

Post by amalag »

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.

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 exploit of this in the wild.

Re: Rails SQL injection vulnerability: here are the facts

#44

Post by numbsafari »

bhauer wrote: post #25

If I understand this correctly, given that a private key is needed to successfully modify the signed HTTP cookie, for a closed-source project using Ruby, Rails, and Authlogic, this vulnerability might be better characterized as an "unintentional backdoor."

Yep, but even if you have a closed-source project you should avoid checking in any secret keys or other credentials to your source control system.

Re: Rails SQL injection vulnerability: here are the facts

#45

Post by tptacek »

judofyr wrote: post #30
tptacek wrote: post #14

Earlier quoted context omitted.

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

I just discovered a related bug that's much more severe than what I initially thought. So yes, man, this is bad :-(

Yeah. I'll post SHA hashes in a bit.

Re: Rails SQL injection vulnerability: here are the facts

#46

Post by judofyr »

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 can confirm that @charliesome has found a loop-hole in Rails' parameters processing that makes it possible to do some really nasty stuff. I also know that other have discovered the same bug independently. I don't think anything has leaked to the public yet.

Based on Charlie's PoC I managed to sneak a SQL-injection into some really basic ActiveRecord queries. It's not entirely obvious how to accomplish this, but it wouldn't surprise me if other people who discovered the same bug will find similar exploits.

This has been reported to Rails' security team and I expect patches to be released pretty soon.

For now I don't have an easy-to-apply workaround that doesn't disclose the gist of the exploit.

Re: Rails SQL injection vulnerability: here are the facts

#47

Post by bstar77 »

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…

How on earth is the article smug? The author responded to the controversy with clear and concise examples demonstrating that the issue is relatively minor and very easy to address if you think you are susceptible. Additionally, most people seem to be using Devise over Authlogic now-a-days. Not saying it's ok to have bugs surfaced in less popular gems, but this thing isn't going to bring the internet down.

Re: Rails SQL injection vulnerability: here are the facts

#48

Post by tptacek »

amalag wrote: post #41
mikeash wrote: post #35

Earlier quoted context omitted.

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

The post states that it is not exploitable through user input via params. They could show you the source code, but I don't know if that would be proof for you. You said that you are assuming it can be exploited, so someone should show it.

Respectfully, what do I care what the author thinks of this vulnerability? Even if they had found the SQLI condition originally (they didn't), that wouldn't mean they fully understood the exposure.

Re: Rails SQL injection vulnerability: here are the facts

#49

Post by tptacek »

judofyr wrote: post #46
amalag wrote: post #31

Earlier quoted context omitted.

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 can confirm that @charliesome has found a loop-hole in Rails' parameters processing that makes it possible to do some really nasty stuff. I also know that other have discovered the same bug independently. I don't think anything has leaked to the public yet. Based on Charlie's PoC I managed to sneak a SQL-injection into some really basic ActiveRecord queries. It's not entirely obvious how to accomplish this, but it…

I think we are talking about two different conditions. Wee!

Re: Rails SQL injection vulnerability: here are the facts

#50

Post by catfish »

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.

Meet the new boss, same as the old one...
Post reply on HN