What happens with this fix is scary at first, but is actually OK.
If you patched as described, and run the exploit code on your local server, the exploit code will return a 200 response. As in:
[-] POSTing puts 'boom' to http://localhost:3000 ...
[-] Success!
This doesn't mean your site is vulnerable. Rails is entirely disregarding the parameters as specified by your initializer code.
Testing locally, watch your server when the request comes through and ensure there are no parameters being registered. You don't want to see something like this:
Started POST "/" for 127.0.0.1 at 2013-01-09 21:00:04 -0800
Processing by StartController#index as */*
Parameters: {"secret"=>"--- !ruby/hash:ActionDispatch::Routing::RouteSet::NamedRouteCollection\n? {}\n: !ruby/object:OpenStruct\n table:\n :defaults:\n :action: create\n :controller: foos\n :required_parts: []\n :requirements:\n :action: create\n :controller: foos\n :segment_keys:\n - :format\n modifiable: true"}
This way a vulnerable server's log file shows something like give below(ie. the Time object was actually created from the yaml):
Started POST "/users/sign_in" for 127.0.0.1 at 2013-01-10 00:26:40 -0500
Processing by Devise::SessionsController#create as /
Parameters: {"secret"=>1969-12-31 19:00:00 -0500}
A patched server raises a Hash::DisallowedType (Disallowed type attribute: "yaml") exception.
activesupport-3.2.11/lib/active_support/core_ext/hash/conversions.rb has a -- DISALLOWED_XML_TYPES = %w(symbol yaml) -- which is used by its def typecast_xml_value to raise the exception.
I don't see these lines of code in activesupport-3.0.3/lib/active_support/core_ext/hash/conversions.rb
In my case I could upgrade to 3.2.11.
In your case, I am guessing you added the lines of code that disable xml and yaml parameter parsing to an initializer (or application.rb). This way, activesupport simply wouldn't try to convert the parameter value in question into a ruby object.
Thanks for posting this, you gave me the bits I needed to make a simple test I could use to verify the patch, without needing the metasploit stuff. (on rails 2.3, I don't get the disallowedType error, but I can verify in the logs that the patch works)
If you patched as described, and run the exploit code on your local server, the exploit code will return a 200 response. As in:
This doesn't mean your site is vulnerable. Rails is entirely disregarding the parameters as specified by your initializer code.Testing locally, watch your server when the request comes through and ensure there are no parameters being registered. You don't want to see something like this: