Rails 3.2 Vulnerabilities

Description

There is an unsafe object creation vulnerability in the json gem bundled with Ruby. This vulnerability has been assigned the CVE identifier CVE-2020-10663. We strongly recommend upgrading the json gem.

Details

When parsing certain JSON documents, the json gem (including the one bundled with Ruby) can be coerced into creating arbitrary objects in the target system.

This is the same issue as CVE-2013-0269. The previous fix was incomplete, which addressed JSON.parse(userinput), but didn’t address some other styles of JSON parsing including JSON(userinput) and JSON.parse(user_input, nil).

See CVE-2013-0269 in detail. Note that the issue was exploitable to cause a Denial of Service by creating many garbage-uncollectable Symbol objects, but this kind of attack is no longer valid because Symbol objects are now garbage-collectable. However, creating arbitrary objects may cause severe security consequences depending upon the application code.

Description

The (1) jdom.rb and (2) rexml.rb components in Active Support in Ruby on Rails before 4.1.11 and 4.2.x before 4.2.2, when JDOM or REXML is enabled, allow remote attackers to cause a denial of service (SystemStackError) via a large XML document depth.

hat the issue was exploitable to cause a Denial of Service by creating many garbage-uncollectable Symbol objects, but this kind of attack is no longer valid because Symbol objects are now garbage-collectable. However, creating arbitrary objects may cause severe security consequences depending upon the application code.

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.

Description

Specially crafted requests can be used to access files that exist on the filesystem that is outside an application's root directory, when the Sprockets server is used in production.

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

Workaround

In Rails applications, work around this issue, set config.assets.compile = false and config.public_file_server.enabled = true in an initializer and precompile the assets.

This work around will not be possible in all hosting environments and upgrading is advised.