Hacker News Reader

Comment by dsl | Hacker News Reader

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 jail free card), similar to the Python Pickle boondoggle [1], which will result in lots of application specific vulnerabilities down the road.

1. http://nadiana.com/python-pickle-insecure

View on HN

> The author wastes a lot of breath refuting claims that this is a huge Ruby bug

Get your facts right first. It's not a Ruby bug. It's a Rails bug. Ruby != Rails.

Many words are used to explain how it works. That is not a refute, nowhere did I claim the bug does not exist. But the requirement for specific circumstances is a fact.

The Python pickle example is not only totally irrelevant, it is also not a security vulnerability. Pickle does exactly what it is supposed to do. You weren't supposed to unpickle arbitrary untrusted data in the first place. If you require a safer alternative, use JSON or something, but don't expect as many features as pickle provides.

In the end, whether this is a "bug" or a "huge bug" is left as an opinion. The article provides hard facts, and a little bit of commentary. Fact is, we've written a ton of Rails apps that all use find_by_* quite extensively but none turned out to be vulnerable because the case where 'foo' is a symbol hash is rare. Whether you think this is an excuse or not, I'll let you decide.

Thanks. Sorry, that was a freudian slip from just reading a rage tweet about Ruby vs. Rails.

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 application specific vulnerabilities" because nobody is going to care about it 6 months from now, except as yet another reason to keep Rails at the most recent version. This is a problem no different from that faced by people on J2EE stacks.

So I disagree with both of your points.

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.

You referred to it as a "boondoggle" which, if it wasn't even a bug, it also was not.

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

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.

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.

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

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.

I don't see it as a "huge Ruby bug". Could you elaborate, please?

I would understand "huge Ruby on Rails bug", though, by convention, it is still a fairly unlikely case.

Edit: I think your edit answers my "Could you elaborate" question somewhat, as you relate a Python library issue to this issue.

Reply on news.ycombinator.com