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.

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

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.

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.

Rails param parsing automatically converts all param keys to symbols.

Just to expand on what others have already said...Rails converts params to 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...), which is called in [`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`.

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

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.

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

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 so I guess maybe you can use the session to do this, though you would need access to the secret_token.

The param keys remain strings underneath.