5 ms·

It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work w

It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work with hashes that have strings as keys, only symbols. EDIT: Just to be clear, tenderlove (Ruby/Rails committer) confirms that you do not need to edit the session to exploit this (http://news.ycombinator.com/item?id=4999767 http://news.ycombinator.com/item?id=4999767). It's still unclear how it is possible otherwise though, I assume he's being purposefully vague.

latortuga 14y ago
Rails param parsing automatically converts all param keys to symbols.
- oomkiller 14y ago
  If I submit a form where the param is "login[select]=* from users limit 1 --" when I inspect params[:login] I get {"select"=>"* from users limit 1 --"}. Is there a different way of submitting things that converts it to symbols? params[:login] works due to it being a HashWithIndifferentAccess
  - mnarayan01 14y ago
    Yea I'm not seeing it either. Maybe if someone explicitly called `params.symbolize_keys!`? If that's the only time its vulnerable it seems like less of a big deal, though still obviously something that should be patched ASAP. edit: Above sandstrom posts the link to https://github.com/binarylogic/authlogic/pull/341 https://github.com/binarylogic/authlogic/pull/341 so I guess maybe you can use the session to do this, though you would need access to the secret_token.
- charliesome 14y ago
  The param keys remain strings underneath.
- mnarayan01 14y ago
  Just to expand on what others have already said...Rails converts params to http://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html http://api.rubyonrails.org/classes/ActiveSupport/HashWithInd... which means that `params[:foo]` and `params["foo"]` will both return the same thing. The function [`assert_valid_keys`](http://api.rubyonrails.org/classes/Hash.html#method-i-assert_valid_keys http://api.rubyonrails.org/classes/Hash.html#method-i-assert...), which is called in [`apply_finder_options`](http://api.rubyonrails.org/classes/ActiveRecord/SpawnMethods.html#method-i-apply_finder_options http://api.rubyonrails.org/classes/ActiveRecord/SpawnMethods...) does not, however, treat symbol and string keys as the same, even if given a `HashWithIndifferentAccess`.
  - xentronium 14y ago
    To expand on your expansion: when a hash with indifferent access is asserted over a list of symbols (as is the keys) it will always fail. 1.9.3p327 :025 > {:a => "b"}.with_indifferent_access.assert_valid_keys([:a]) ArgumentError: Unknown key: a
- waffle_ss 14y ago
  No, it's a bit more elaborate than that. If what you said were strictly true you could DoS any Rails app as symbols are never garbage collected - you could just continue sending new param keys to the app until it runs out of memory.
deleted 14y ago
[deleted]
xentronium 14y ago
Patch is quite small, here are the tests: + def test_find_by_id_with_hash + assert_raises(ActiveRecord::StatementInvalid) do + Post.find_by_id(:limit => 1) + end + end + + def test_find_by_title_and_id_with_hash + assert_raises(ActiveRecord::StatementInvalid) do + Post.find_by_title_and_id('foo', :limit => 1) + end + end + I can't understand how it happens with real params, though (they are converted to hash with indifferent access internally). Example (real rails app): 1.9.3p327 :017 > Forum::Thread.find_by_id_and_forum_id(1, {:limit => 10}.with_indifferent_access) ArgumentError: Unknown key: limit [backtrace skipped] NOTE: I originally posted (and quickly deleted) wrong answer because I looked up another CVE. I apologize if it confused anyone.
Xylakant 14y ago
Not everything that gets passed to the find_by_ methods has to come from the params hash. The sessions hash is another source of data that gets fed to such methods. See this PR https://github.com/binarylogic/authlogic/pull/341 https://github.com/binarylogic/authlogic/pull/341
- benmmurphy 14y ago
  if you can control session hash it may also be possible to execute arbitrary ruby code. if you take an object from the session hash and call a method on it then depending on the method name it is possible to eval arbitrary ruby code.
InAnEmergency 14y ago
Yes, exactly. This is only directly exploitable if the user can submit a hash with symbol keys. Otherwise, it seems like it would take some unusual code path in the app to exploit the vulnerability. The original post of the problem goes like this: 1. Gain an application's secret key, used to sign session cookies. 2. Inject a marshalled hash with _symbol_ keys into the session cookie, sign it with the secret key. 3. Now you can exploit the SQL vulnerability in the dynamic finders, assuming the session value is used directly as input.

latortuga 14y ago

Rails param parsing automatically converts all param keys to symbols.

oomkiller 14y ago
If I submit a form where the param is "login[select]=* from users limit 1 --" when I inspect params[:login] I get {"select"=>"* from users limit 1 --"}. Is there a different way of submitting things that converts it to symbols? params[:login] works due to it being a HashWithIndifferentAccess
- mnarayan01 14y ago
  Yea I'm not seeing it either. Maybe if someone explicitly called `params.symbolize_keys!`? If that's the only time its vulnerable it seems like less of a big deal, though still obviously something that should be patched ASAP. edit: Above sandstrom posts the link to https://github.com/binarylogic/authlogic/pull/341 https://github.com/binarylogic/authlogic/pull/341 so I guess maybe you can use the session to do this, though you would need access to the secret_token.
charliesome 14y ago
The param keys remain strings underneath.
mnarayan01 14y ago
Just to expand on what others have already said...Rails converts params to http://api.rubyonrails.org/classes/ActiveSupport/HashWithIndifferentAccess.html http://api.rubyonrails.org/classes/ActiveSupport/HashWithInd... which means that `params[:foo]` and `params["foo"]` will both return the same thing. The function [`assert_valid_keys`](http://api.rubyonrails.org/classes/Hash.html#method-i-assert_valid_keys http://api.rubyonrails.org/classes/Hash.html#method-i-assert...), which is called in [`apply_finder_options`](http://api.rubyonrails.org/classes/ActiveRecord/SpawnMethods.html#method-i-apply_finder_options http://api.rubyonrails.org/classes/ActiveRecord/SpawnMethods...) does not, however, treat symbol and string keys as the same, even if given a `HashWithIndifferentAccess`.
- xentronium 14y ago
  To expand on your expansion: when a hash with indifferent access is asserted over a list of symbols (as is the keys) it will always fail. 1.9.3p327 :025 > {:a => "b"}.with_indifferent_access.assert_valid_keys([:a]) ArgumentError: Unknown key: a
waffle_ss 14y ago
No, it's a bit more elaborate than that. If what you said were strictly true you could DoS any Rails app as symbols are never garbage collected - you could just continue sending new param keys to the app until it runs out of memory.

deleted 14y ago

[deleted]

xentronium 14y ago

Patch is quite small, here are the tests: + def test_find_by_id_with_hash + assert_raises(ActiveRecord::StatementInvalid) do + Post.find_by_id(:limit => 1) + end + end + + def test_find_by_title_and_id_with_hash + assert_raises(ActiveRecord::StatementInvalid) do + Post.find_by_title_and_id('foo', :limit => 1) + end + end + I can't understand how it happens with real params, though (they are converted to hash with indifferent access internally). Example (real rails app): 1.9.3p327 :017 > Forum::Thread.find_by_id_and_forum_id(1, {:limit => 10}.with_indifferent_access) ArgumentError: Unknown key: limit [backtrace skipped] NOTE: I originally posted (and quickly deleted) wrong answer because I looked up another CVE. I apologize if it confused anyone.

Xylakant 14y ago

Not everything that gets passed to the find_by_ methods has to come from the params hash. The sessions hash is another source of data that gets fed to such methods. See this PR https://github.com/binarylogic/authlogic/pull/341 https://github.com/binarylogic/authlogic/pull/341

benmmurphy 14y ago
if you can control session hash it may also be possible to execute arbitrary ruby code. if you take an object from the session hash and call a method on it then depending on the method name it is possible to eval arbitrary ruby code.

InAnEmergency 14y ago

Yes, exactly. This is only directly exploitable if the user can submit a hash with symbol keys. Otherwise, it seems like it would take some unusual code path in the app to exploit the vulnerability. The original post of the problem goes like this: 1. Gain an application's secret key, used to sign session cookies. 2. Inject a marshalled hash with _symbol_ keys into the session cookie, sign it with the secret key. 3. Now you can exploit the SQL vulnerability in the dynamic finders, assuming the session value is used directly as input.