4 ms·

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

by dsl 14y ago

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 http://nadiana.com/python-pickle-insecure

FooBarWidget 14y ago
> 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.
- dsl 14y ago
  Thanks. Sorry, that was a freudian slip from just reading a rage tweet about Ruby vs. Rails.
mileszs 14y ago
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.
tptacek 14y ago
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.
- dsl 14y ago
  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.
  - freshhawk 14y ago
    You referred to it as a "boondoggle" which, if it wasn't even a bug, it also was not.
- jeswin 14y ago
  There should be a higher bar for libraries shipping with languages, than those shipping with frameworks like Rails.
dasil003 14y ago
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.
- amalag 14y ago
  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.
  - dasil003 14y ago
    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.
    - amalag 14y ago
      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.
      - 14y ago
amalag 14y ago
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.

by dsl 14y ago

FooBarWidget 14y ago

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

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

mileszs 14y ago

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.

tptacek 14y ago

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.

dsl 14y ago
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.
- freshhawk 14y ago
  You referred to it as a "boondoggle" which, if it wasn't even a bug, it also was not.
jeswin 14y ago
There should be a higher bar for libraries shipping with languages, than those shipping with frameworks like Rails.

dasil003 14y ago

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.

amalag 14y ago
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.
- dasil003 14y ago
  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.
  - amalag 14y ago
    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.
    - 14y ago

amalag 14y ago

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.