Rails SQL injection vulnerability: here are the facts • Hacker News Board

Re: Rails SQL injection vulnerability: here are the facts

#21

Post by rimantas » Thu, Jan 03, 2013, 1:56 PM UTC

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…

  > Yet that's proven not to be the case.

You have a proof of that? Care to share? How does one even prove framework X being more secure than framework Y?

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

Would you mind to reveal, what kind of -ist you are, and why the -ists you represent make only absolutely true claims? Or can we just agree, that this kind of generalization is silly and pointless?

Re: Rails SQL injection vulnerability: here are the facts

#22

Post by jeswin » Thu, Jan 03, 2013, 2:06 PM UTC

tptacek wrote: post #8

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…

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…

There should be a higher bar for libraries shipping with languages, than those shipping with frameworks like Rails.

Re: Rails SQL injection vulnerability: here are the facts

#23

Post by phillc » Thu, Jan 03, 2013, 2:09 PM UTC

FooBarWidget wrote: post #17

mef wrote: 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.

Thank you... I always wondered why that was true.

Re: Rails SQL injection vulnerability: here are the facts

#24

Post by phillc » Thu, Jan 03, 2013, 2:41 PM UTC

If you are scanning your code base for find_by_'s, make sure to look at your find_all_by_'s as well if you have them.

Re: Rails SQL injection vulnerability: here are the facts

#25

Post by bhauer » Thu, Jan 03, 2013, 2:44 PM UTC

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

Re: Rails SQL injection vulnerability: here are the facts

#26

Post by amalag » Thu, Jan 03, 2013, 2:49 PM UTC

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?

Re: Rails SQL injection vulnerability: here are the facts

#27

Post by tptacek » Thu, Jan 03, 2013, 2:51 PM UTC

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?

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

Re: Rails SQL injection vulnerability: here are the facts

#28

Post by dasil003 » Thu, Jan 03, 2013, 2:54 PM UTC

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…

Wow, you have a serious chip on your shoulder. Nothing you're saying here is more than a gross stereotypical generalization that's no better than whatever ignorant flames you read that shaped your opinion. Are you perhaps one of the Java devs that DHH poked in the eye back in the day?

Re: Rails SQL injection vulnerability: here are the facts

#29

Post by dasil003 » Thu, Jan 03, 2013, 3:01 PM UTC

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.

Re: Rails SQL injection vulnerability: here are the facts

#30

Post by judofyr » Thu, Jan 03, 2013, 3:09 PM UTC

tptacek wrote: post #14

judofyr wrote: post #11

Earlier quoted context omitted.

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.

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