Rails 4.1 Vulnerabilities

In order to calculate Rails 4.1 vulnerabilities we created an application using the latest patch version of Rails 4.1 and we ran bundler-audit to find all known vulnerabilities.

Here we list the security risks related to a sample Rails 4.1 application.

VULNERABLE GEM: ACTIONVIEW@4.1.16

Name:

actionview

Version:

4.1.16

ID:

CVE-2016-6316

Possible XSS Vulnerability in Action View

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: sanitize(user_input)

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)))

VULNERABLE GEM: ACTIONVIEW@4.1.16

Name:

actionview

Version:

4.1.16

ID:

CVE-2019-5419

Denial of Service Vulnerability in Action View

Description

There is a potential denial of service vulnerability in actionview. This vulnerability has been assigned the CVE identifier CVE-2019-5419.

IMPACT

Specially crafted accept headers can cause the Action View template location code to consume 100% CPU, causing the server unable to process requests. This impacts all Rails applications that render views.

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

WORKAROUNDS

This vulnerability can be mitigated by wrapping render calls with respond_to blocks. For example, the following example is vulnerable:

class UserController < ApplicationController
  def index
    render "index"
  end
end

But the following code is not vulnerable:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Implicit rendering is impacted, so this code is vulnerable:

class UserController < ApplicationController
  def index
  end
end

But can be changed this this:

class UserController < ApplicationController
  def index
    respond_to |format|
      format.html { render "index" }
    end
  end
end

Alternatively to specifying the format, the following monkey patch can be applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

VULNERABLE GEM: ACTIONVIEW@4.1.16

Name:

actionview

Version:

4.1.16

ID:

CVE-2019-5418

File Content Disclosure in Action View

Description

There is a possible file content disclosure vulnerability in Action View. This vulnerability has been assigned the CVE identifier CVE-2019-5418.

Versions Affected: All. Not affected: None. Fixed Versions: 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, 4.2.11.1

IMPACT

There is a possible file content disclosure vulnerability in Action View. Specially crafted accept headers in combination with calls to render file: can cause arbitrary files on the target server to be rendered, disclosing the file contents.

The impact is limited to calls to render which render file contents without a specified accept format. Impacted code in a controller looks something like this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file"
  end
end

Rendering templates as opposed to files is not impacted by this vulnerability.

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

RELEASES

The 6.0.0.beta3, 5.2.2.1, 5.1.6.2, 5.0.7.2, and 4.2.11.1 releases are available at the normal locations.

WORKAROUNDS

This vulnerability can be mitigated by specifying a format for file rendering, like this:

class UserController < ApplicationController
  def index
    render file: "#{Rails.root}/some/file", formats: [:html]
  end
end

In summary, impacted calls to render look like this:

render file: "#{Rails.root}/some/file"

The vulnerability can be mitigated by changing to this:

render file: "#{Rails.root}/some/file", formats: [:html]

Other calls to render are not impacted.

Alternatively, the following monkey patch can be applied in an initializer:

$ cat config/initializers/formats_filter.rb
# frozen_string_literal: true

ActionDispatch::Request.prepend(Module.new do
  def formats
    super().select do |format|
      format.symbol || format.ref == "*/*"
    end
  end
end)

VULNERABLE GEM: RACK@1.5.5

Name:

rack

Version:

1.5.5

ID:

CVE-2019-5418

Possible XSS vulnerability in Rack

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