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.
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.
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.
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.
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)))
There is a potential denial of service vulnerability in actionview. This vulnerability has been assigned the CVE identifier CVE-2019-5419.
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.
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)
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
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.
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.
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)
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
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.
The 2.0.6 and 1.6.11 releases are available at the normal locations.
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