Rails 4.0 Vulnerabilities

Description

There is a timing attack vulnerability in the basic authentication support in Action Controller. This vulnerability has been assigned the CVE identifier CVE-2015-7576.

Versions Affected: All. Not affected: None. Fixed Versions: 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1

Impact

Due to the way that Action Controller compares user names and passwords in basic authentication authorization code, it is possible for an attacker to analyze the time taken by a response and intuit the password.

For example, this string comparison:

"foo" == "bar"

is possibly faster than this comparison:

"foo" == "fo1"

Attackers can use this information to attempt to guess the username and password used in the basic authentication system.

You can tell you application is vulnerable to this attack by looking for http_basic_authenticate_with method calls in your application.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

If you can't upgrade, please use the following monkey patch in an initializer that is loaded before your application:

$ cat config/initializers/basic_auth_fix.rb
module ActiveSupport
  module SecurityUtils
    def secure_compare(a, b)
      return false unless a.bytesize == b.bytesize

      l = a.unpack "C#{a.bytesize}"

      res = 0
      b.each_byte { |byte| res |= byte ^ l.shift }
      res == 0
    end
    module_function :secure_compare

    def variable_size_secure_compare(a, b)
      secure_compare(::Digest::SHA256.hexdigest(a), ::Digest::SHA256.hexdigest(b))
    end
    module_function :variable_size_secure_compare
  end
end

module ActionController
  class Base
    def self.http_basic_authenticate_with(options = {})
      before_action(options.except(:name, :password, :realm)) do
        authenticate_or_request_with_http_basic(options[:realm] || "Application") do |name, password|
          # This comparison uses & so that it doesn't short circuit and
          # uses `variable_size_secure_compare` so that length information
          # isn't leaked.
          ActiveSupport::SecurityUtils.variable_size_secure_compare(name, options[:name]) &
            ActiveSupport::SecurityUtils.variable_size_secure_compare(password, options[:password])
        end
      end
    end
  end
end

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for it. It is in git-am format and consist of a single changeset.

• 4-1-basic_auth.patch - Patch for 4.1 series
• 4-2-basic_auth.patch - Patch for 4.2 series
• 5-0-basic_auth.patch - Patch for 5.0 series

Please note that only the 4.1.x and 4.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

CREDITS

Thank you to Daniel Waterworth for reporting the problem and working with us to fix it.

Description

There is a possible directory traversal and information leak vulnerability in Action View. This was meant to be fixed on CVE-2016-0752. However the 3.2 patch was not covering all the scenarios. This vulnerability has been assigned the CVE identifier CVE-2016-2097.

Versions Affected: 3.2.x, 4.0.x, 4.1.x Not affected: 4.2+ Fixed Versions: 3.2.22.2, 4.1.14.2

Impact

Applications that pass unverified user input to the render method in a controller may be vulnerable to an information leak vulnerability.

Impacted code will look something like this:

def index
  render params[:id]
end

Carefully crafted requests can cause the above code to render files from unexpected places like outside the application's view directory, and can possibly escalate this to a remote code execution attack.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

A workaround to this issue is to not pass arbitrary user input to the render method. Instead, verify that data before passing it to the render method.

For example, change this:

def index
  render params[:id]
end

To this:

def index
  render verify_template(params[:id])
end

private
def verify_template(name)
  # add verification logic particular to your application here
end

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for it. It is in git-am format and consist of a single changeset.

• 3-2-renderdataleak_2.patch - Patch for 3.2 series
• 4-1-renderdataleak_2.patch - Patch for 4.1 series

CREDITS

Thanks to both Jyoti Singh and Tobias Kraze from makandra for reporting this and working with us in the patch!

Description

There is a possible XSS vulnerability in Action View. Text declared as "HTML safe" will not have quotes escaped when used as attribute values in tag helpers.

Impact

Text declared as "HTML safe" when passed as an attribute value to a tag helper will not have quotes escaped which can lead to an XSS attack. Impacted code looks something like this:

content_tag(:div, "hi", title: user_input.html_safe)

Some helpers like the sanitize helper will automatically mark strings as "HTML safe", so impacted code could also look something like this:

content_tag(:div, "hi", title: user_input.html_safe)

All users running an affected release should either upgrade or use one of the workarounds immediately.

WORKAROUNDS

You can work around this issue by either not marking arbitrary user input as safe, or by manually escaping quotes like this:

def escape_quotes(value)
  value.gsub(/"/, '"'.freeze)
end

content_tag(:div, "hi", title: escape_quotes(sanitize(user_input)))

Description

There is a possible object leak which can lead to a denial of service vulnerability in Action Pack. This vulnerability has been assigned the CVE identifier CVE-2016-0751.

Versions Affected: All. Not affected: None. Fixed Versions: 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1

Impact

A carefully crafted accept header can cause a global cache of mime types to grow indefinitely which can lead to a possible denial of service attack in Action Pack.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

This attack can be mitigated by a proxy that only allows known mime types in the Accept header.

Placing the following code in an initializer will also mitigate the issue:

require 'action_dispatch/http/mime_type'

Mime.const_set :LOOKUP, Hash.new { |h,k|
  Mime::Type.new(k) unless k.blank?
}

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for it. It is in git-am format and consist of a single changeset.

• 5-0-mimetypesleak.patch - Patch for 5.0 series
• 4-2-mimetypesleak.patch - Patch for 4.2 series
• 4-1-mimetypesleak.patch - Patch for 4.1 series
• 3-2-mimetypesleak.patch - Patch for 3.2 series

Please note that only the 4.1.x and 4.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

CREDITS

Aaron Patterson <3<3

Description

There is an object leak vulnerability for wildcard controllers in Action Pack. This vulnerability has been assigned the CVE identifier CVE-2015-7581.

Versions Affected: >= 4.0.0 and < 5.0.0.beta1 Not affected: < 4.0.0, 5.0.0.beta1 and newer Fixed Versions: 4.2.5.1, 4.1.14.1

IMPACT

Users that have a route that contains the string ":controller" are susceptible to objects being leaked globally which can lead to unbounded memory growth. To identify if your application is vulnerable, look for routes that contain ":controller".

Internally, Action Pack keeps a map of "url controller name" to "controller class name". This map is cached globally, and is populated even if the controller class doesn't actually exist.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

There are no feasible workarounds for this issue.

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

• 4-1-wildcard_route.patch - Patch for 4.1 series
• 4-2-wildcard_route.patch - Patch for 4.2 series

Please note that only the 4.1.x and 4.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Description

There is a possible directory traversal and information leak vulnerability in Action View. This vulnerability has been assigned the CVE identifier CVE-2016-0752.

Versions Affected: All. Not affected: None. Fixed Versions: 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1

Impact

Applications that pass unverified user input to the render method in a controller may be vulnerable to an information leak vulnerability.

Impacted code will look something like this:

def index
  render params[:id]
end

Carefully crafted requests can cause the above code to render files from unexpected places like outside the application's view directory, and can possibly escalate this to a remote code execution attack.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

A workaround to this issue is to not pass arbitrary user input to the render method. Instead, verify that data before passing it to the render method.

For example, change this:

def index
  render params[:id]
end

To this:

def index
  render verify_template(params[:id])
end

private
def verify_template(name)
  # add verification logic particular to your application here
end

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for it. It is in git-am format and consist of a single changeset.

• 3-2-renderdataleak.patch - Patch for 3.2 series
• 4-1-renderdataleak.patch - Patch for 4.1 series
• 4-2-renderdataleak.patch - Patch for 4.2 series
• 5-0-renderdataleak.patch - Patch for 5.0 series

Please note that only the 4.1.x and 4.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

CREDITS

Thanks John Poulin for reporting this! <3<3

Description

There is a possible remote code execution vulnerability in Action Pack. This vulnerability has been assigned the CVE identifier CVE-2016-2098.

Versions Affected: 3.2.x, 4.0.x, 4.1.x, 4.2.x Not affected: 5.0+ Fixed Versions: 3.2.22.2, 4.1.14.2, 4.2.5.2

Impact

Applications that pass unverified user input to the render method in a controller or a view may be vulnerable to a code injection.

Impacted code will look like this:

class TestController < ApplicationController
  def show
    render params[:id]
  end
end

An attacker could use the request parameters to coerce the above example to execute arbitrary ruby code.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

A workaround to this issue is to not pass arbitrary user input to the render method. Instead, verify that data before passing it to the render method.

For example, change this:

def index
  render params[:id]
end

To this:

def index
  render verify_template(params[:id])
end

private
def verify_template(name)
  # add verification logic particular to your application here
end

PATCHES

To aid users who aren't able to upgrade immediately we have provided a patch for it. It is in git-am format and consist of a single changeset.

• 3-2-secureinlinewith_params.patch - Patch for 3.2 series
• 4-1-secureinlinewith_params.patch - Patch for 4.1 series
• 4-2-secureinlinewith_params.patch - Patch for 4.2 series

CREDITS

Thanks to both Tobias Kraze from makandra and joernchen of Phenoelit for reporting this!

Description

There is a vulnerability in how the nested attributes feature in Active Record handles updates in combination with destroy flags when destroying records is disabled. This vulnerability has been assigned the CVE identifier CVE-2015-7577.

Versions Affected: 3.1.0 and newer Not affected: 3.0.x and older Fixed Versions: 5.0.0.beta1.1, 4.2.5.1, 4.1.14.1, 3.2.22.1

Impact

When using the nested attributes feature in Active Record you can prevent the destruction of associated records by passing the allow_destroy: false option to the accepts_nested_attributes_for method. However due to a change in the commit a9b4b5d the _destroy flag prevents the :reject_if proc from being called because it assumes that the record will be destroyed anyway.

However this isn't true if :allow_destroy is false so this leads to changes that would have been rejected being applied to the record. Attackers could use this do things like set attributes to invalid values and to clear all of the attributes amongst other things. The severity will be dependent on how the application has used this feature.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The FIXED releases are available at the normal locations.

WORKAROUNDS

If you can't upgrade, please use the following monkey patch in an initializer that is loaded before your application:

$ cat config/initializers/nested_attributes_bypass_fix.rb
module ActiveRecord
  module NestedAttributes
    private

    def reject_new_record?(association_name, attributes)
      will_be_destroyed?(association_name, attributes) || call_reject_if(association_name, attributes)
    end

    def call_reject_if(association_name, attributes)
      return false if will_be_destroyed?(association_name, attributes)

      case callback = self.nested_attributes_options[association_name][:reject_if]
      when Symbol
        method(callback).arity == 0 ? send(callback) : send(callback, attributes)
      when Proc
        callback.call(attributes)
      end
    end

    def will_be_destroyed?(association_name, attributes)
      allow_destroy?(association_name) && has_destroy_flag?(attributes)
    end

    def allow_destroy?(association_name)
      self.nested_attributes_options[association_name][:allow_destroy]
    end
  end
end

PATCHES

To aid users who aren't able to upgrade immediately we have provided patches for it. It is in git-am format and consist of a single changeset.

• 3-2-nested-attributes-reject-if-bypass.patch - Patch for 3.2 series
• 4-1-nested-attributes-reject-if-bypass.patch - Patch for 4.1 seriess
• 4-2-nested-attributes-reject-if-bypass.patch - Patch for 4.2 series
• 5-0-nested-attributes-reject-if-bypass.patch - Patch for 5.0 series

Please note that only the 4.1.x and 4.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

CREDITS

Thank you to Justin Coyne for reporting the problem and working with us to fix it.

Description

Specially crafted XML documents can cause applications to raise a SystemStackError and potentially cause a denial of service attack. This only impacts applications using REXML or JDOM as their XML processor. Other XML processors that Rails supports are not impacted.

All users running an affected release should either upgrade or use one of the work arounds immediately.

WORKAROUNDS

Use an XML parser that is not impacted by this problem, such as Nokogiri or LibXML. You can change the processor like this:

ActiveSupport::XmlMini.backend = 'Nokogiri'

If you cannot change XML parsers, then adjust RUBY_THREAD_MACHINE_STACK_SIZE

Description

There is a possible vulnerability in Rack. This vulnerability has been assigned the CVE identifier CVE-2018-16471.

Versions Affected: All. Not affected: None. Fixed Versions: 2.0.6, 1.6.11

IMPACT

There is a possible XSS vulnerability in Rack. Carefully crafted requests can impact the data returned by the scheme method on Rack::Request. Applications that expect the scheme to be limited to "http" or "https" and do not escape the return value could be vulnerable to an XSS attack.

Vulnerable code looks something like this:

<%= request.scheme.html_safe >

Note that applications using the normal escaping mechanisms provided by Rails may not impacted, but applications that bypass the escaping mechanisms, or do not use them may be vulnerable.

All users running an affected release should either upgrade or use one of the workarounds immediately.

RELEASES

The 2.0.6 and 1.6.11 releases are available at the normal locations.

WORKAROUNDS

The following monkey patch can be applied to work around this issue:

require "rack"
require "rack/request"

class Rack::Request
SCHEME_WHITELIST = %w(https http).freeze

def scheme
  if get_header(Rack::HTTPS) == 'on'
    'https'
  elsif get_header(HTTP_X_FORWARDED_SSL) == 'on'
    'https'
  elsif forwarded_scheme
    forwarded_scheme
  else
    get_header(Rack::RACK_URL_SCHEME)
  end
end

def forwarded_scheme
  scheme_headers = [
    get_header(HTTP_X_FORWARDED_SCHEME),
    get_header(HTTP_X_FORWARDED_PROTO).to_s.split(',')[0]
  ]

  scheme_headers.each do |header|
    return header if SCHEME_WHITELIST.include?(header)
  end

  nil
end
end

Description:

There's a possible information leak / session hijack vulnerability in Rack.

Attackers may be able to find and hijack sessions by using timing attacks targeting the session id. Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session.

The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison.

Impact:

The session id stored in a cookie is the same id that is used when querying the backing session storage engine. Most storage mechanisms (for example a database) use some sort of indexing in order to speed up the lookup of that id. By carefully timing requests and session lookup failures, an attacker may be able to perform a timing attack to determine an existing session id and hijack that session.