4 ms·

But how do you patch it?

danielpal 14y ago
bundle update activesupport
kapilkale 14y ago
If running Rails 3, you can disable XML parsing of parameters by adding this to an initializer: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) source: https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion https://groups.google.com/forum/#!topic/rubyonrails-security...
- kapilkale 14y ago
  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"}
  - gautamc 14y ago
    On a patched server I see a Hash::DisallowedType (Disallowed type attribute: "yaml") exception raised by activesupport. As a simpler test-case, I modified the rails_rce.rb ( for CVE-2013-0156 )and passed a simpler yaml that creates a Time object: yaml = %{ --- !ruby/object:Time {} } xml = %{ <?xml version="1.0" encoding="UTF-8"?> <#{param} type="yaml">#{yaml}</#{param}> }.strip print_info "POSTing #{code} to #{url} ..." response = http_request( :method => :post, :url => url, :headers => {:content_type => 'text/xml'}, :body => xml ) 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.
    - kapilkale 14y ago
      I'm unable to reproduce- not sure why. Seeing no parameters. I'm getting: Started POST "/user/sign_in" for 127.0.0.1 at 2013-01-09 21:40:56 -0800 Processing by UsersController#sign_in as */* If I comment out the patch, I see: Parameters: {"secret"=>1969-12-31 16:00:00 -0800} So I suspect others may not see the same exception... I'm using ActiveSupport 3.0.3, fyi.
      - gautamc 14y ago
        Yep. I see what you mean. 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.
        kapilkale 14y ago
        Right. Thanks!
    - j_mac 14y ago
      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) http://www.railsperformance.com/2013/01/simple-test-for-rails-xmlyaml-security.html http://www.railsperformance.com/2013/01/simple-test-for-rail...
lengarvey 14y ago
If you're running a relatively new version of Rails (hopefully 3.2.10) you can just goto your app on your dev machine and type: bundle update rails Then commit and deploy in the usual manner. You'll probably experience no issues with your application, but it's good practice to run your test suite before you do any sort of production deploy anyway. If you're running an older version of Rails (pre bundler) or if you don't have a solid test-suite, you'll have a tougher time updating. But you definitely need to put aside time to figure it out now.
- bonzoesc 14y ago
  You'll need to change the version of rails listed in the Gemfile. I don't think "bundle update" modifies that.
  - outside1234 14y ago
    That's exactly what bundle update does.
    - guywithabike 14y ago
      Only in Gemfile.lock. If you've hard-coded a version in Gemfile, you'll need to update it. Eg. These will update fine: gem "rails" gem "rails", "~> 3.2" This wont: gem "rails", "= 3.2.10"
    - jaggederest 14y ago
      No, bundle update only updates the Gemfile.lock If your gemfile looks like: gem 'rails', '3.2.10' Then `bundle update` does nothing.
  - lengarvey 14y ago
    Actually it depends on what your Gemfile looks like. If you've specified the exact version in your Gemfile you'll need to edit it before running `bundle update rails`. This means your Gemfile might look like: gem 'rails', '3.2.10' Running `bundle update rails` when you've absolutely specified the version number won't do anything. Your Gemfile.lock file (which is the file that bundler uses to determine which gems to require) won't be changed. Instead of absolutely specifying the version of Rails you want to use, considering using the '~>' specifier. My Gemfile at Airtasker looks like: gem 'rails', '~> 3.2.8' That means that when I run `bundle update rails` it will update the patch version of rails. Our Gemfile.lock has the following entry for rails: rails (3.2.11) By using the '~>' specifier it means that we can easily update our gems patch versions without worrying about API changes between major and minor versions. You can read: http://gembundler.com/v1.2/gemfile.html http://gembundler.com/v1.2/gemfile.html to find out more.

bundle update activesupport

If running Rails 3, you can disable XML parsing of parameters by adding this to an initializer: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) source: https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion https://groups.google.com/forum/#!topic/rubyonrails-security...

kapilkale 14y ago
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"}
- gautamc 14y ago
  On a patched server I see a Hash::DisallowedType (Disallowed type attribute: "yaml") exception raised by activesupport. As a simpler test-case, I modified the rails_rce.rb ( for CVE-2013-0156 )and passed a simpler yaml that creates a Time object: yaml = %{ --- !ruby/object:Time {} } xml = %{ <?xml version="1.0" encoding="UTF-8"?> <#{param} type="yaml">#{yaml}</#{param}> }.strip print_info "POSTing #{code} to #{url} ..." response = http_request( :method => :post, :url => url, :headers => {:content_type => 'text/xml'}, :body => xml ) 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.
  - kapilkale 14y ago
    I'm unable to reproduce- not sure why. Seeing no parameters. I'm getting: Started POST "/user/sign_in" for 127.0.0.1 at 2013-01-09 21:40:56 -0800 Processing by UsersController#sign_in as */* If I comment out the patch, I see: Parameters: {"secret"=>1969-12-31 16:00:00 -0800} So I suspect others may not see the same exception... I'm using ActiveSupport 3.0.3, fyi.
    - gautamc 14y ago
      Yep. I see what you mean. 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.
      - kapilkale 14y ago
        Right. Thanks!
  - j_mac 14y ago
    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) http://www.railsperformance.com/2013/01/simple-test-for-rails-xmlyaml-security.html http://www.railsperformance.com/2013/01/simple-test-for-rail...

lengarvey 14y ago

If you're running a relatively new version of Rails (hopefully 3.2.10) you can just goto your app on your dev machine and type: bundle update rails Then commit and deploy in the usual manner. You'll probably experience no issues with your application, but it's good practice to run your test suite before you do any sort of production deploy anyway. If you're running an older version of Rails (pre bundler) or if you don't have a solid test-suite, you'll have a tougher time updating. But you definitely need to put aside time to figure it out now.

bonzoesc 14y ago
You'll need to change the version of rails listed in the Gemfile. I don't think "bundle update" modifies that.
- outside1234 14y ago
  That's exactly what bundle update does.
  - guywithabike 14y ago
    Only in Gemfile.lock. If you've hard-coded a version in Gemfile, you'll need to update it. Eg. These will update fine: gem "rails" gem "rails", "~> 3.2" This wont: gem "rails", "= 3.2.10"
  - jaggederest 14y ago
    No, bundle update only updates the Gemfile.lock If your gemfile looks like: gem 'rails', '3.2.10' Then `bundle update` does nothing.
- lengarvey 14y ago
  Actually it depends on what your Gemfile looks like. If you've specified the exact version in your Gemfile you'll need to edit it before running `bundle update rails`. This means your Gemfile might look like: gem 'rails', '3.2.10' Running `bundle update rails` when you've absolutely specified the version number won't do anything. Your Gemfile.lock file (which is the file that bundler uses to determine which gems to require) won't be changed. Instead of absolutely specifying the version of Rails you want to use, considering using the '~>' specifier. My Gemfile at Airtasker looks like: gem 'rails', '~> 3.2.8' That means that when I run `bundle update rails` it will update the patch version of rails. Our Gemfile.lock has the following entry for rails: rails (3.2.11) By using the '~>' specifier it means that we can easily update our gems patch versions without worrying about API changes between major and minor versions. You can read: http://gembundler.com/v1.2/gemfile.html http://gembundler.com/v1.2/gemfile.html to find out more.