Rails 3.1 Vulnerabilities
In order to calculate Rails 3.1 vulnerabilities we created an application using
the latest patch version of Rails 3.1 and we ran bundler-audit
to find all known vulnerabilities.
In order to calculate Rails 3.1 vulnerabilities we created an application using
the latest patch version of Rails 3.1 and we ran bundler-audit
to find all known vulnerabilities.
Here we list the security risks related to a sample Rails 3.1 application.
Action Mailer Gem for Ruby contains a format string flaw in the Log Subscriber component. The issue is triggered as format string specifiers (e.g. %s and %x) are not properly sanitized in user-supplied input when handling email addresses. This may allow a remote attacker to cause a denial of service
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
Ruby on Rails contains a flaw that allows a cross-site scripting (XSS) attack. This flaw exists because the actionpack/lib/actionview/helpers/numberhelper.rb script does not validate input to the 'numbertocurrency', 'numbertopercentage', and 'numbertohuman' helpers before returning it to users. This may allow a remote attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server.
Specially crafted requests can be used to determine whether a file exists on the filesystem that is outside the Rails application's root directory. The files will not be served, but attackers can determine whether or not the file exists.
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
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.
The FIXED releases are available at the normal locations.
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
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.
Thanks to both Jyoti Singh and Tobias Kraze from makandra for reporting this and working with us in the patch!
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
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.
The FIXED releases are available at the normal locations.
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
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.
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.
Thank you to Daniel Waterworth for reporting the problem and working with us to fix it.
Ruby on Rails contains a flaw in actionpack/lib/action_view/template/text.rb in the text rendering component of Action View that is triggered when handling MIME types that are converted to symbols. This may allow a remote attacker to cause a denial of service.
The prior fix to CVE-2013-0155 was incomplete and the use of common 3rd party libraries can accidentally circumvent the protection. Due to the way that Rack::Request and Rails::Request interact, it is possible for a 3rd party or custom rack middleware to parse the parameters insecurely and store them in the same key that Rails uses for its own parameters. In the event that happens the application will receive unsafe parameters and could be vulnerable to the earlier vulnerability.
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
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.
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?
}
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.
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.
Aaron Patterson <3<3
There is a denial of service vulnerability in the header handling component of Action View.
There is a vulnerability in the internationalization component of Ruby on Rails. Under certain common configurations an attacker can provide specially crafted input which will execute a reflective XSS attack.
The root cause of this issue is a vulnerability in the i18n gem which has been assigned the identifier CVE-2013-4492.
Specially crafted requests can be used to determine whether a file exists on the filesystem that is outside the Rails application's root directory. The files will not be served, but attackers can determine whether or not the file exists. This vulnerability is very similar to CVE-2014-7818, but the specially crafted string is slightly different.
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
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.
The FIXED releases are available at the normal locations.
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
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.
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.
Thanks John Poulin for reporting this! <3<3
There is a vulnerability in the 'implicit render' functionality in Ruby on Rails.The implicit render functionality allows controllers to render a template, even if there is no explicit action with the corresponding name. This module does not perform adequate input sanitization which could allow an attacker to use a specially crafted request to retrieve arbitrary files from the rails application server.
There is an XSS vulnerability in the numbertocurrency helper in Ruby on Raile. The numbertocurrency helper allows users to nicely format a numeric value. One of the parameters to the helper (unit) is not escaped correctly. Applications which pass user controlled data as the unit parameter are vulnerable to an XSS attack.
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: user_input.html_safe)
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 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
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.
The FIXED releases are available at the normal locations.
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
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.
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.
Thank you to Justin Coyne for reporting the problem and working with us to fix it.
Ruby on Rails contains a flaw that may allow carrying out an SQL injection attack. The issue is due to the PostgreSQL adapter for Active Record not properly sanitizing user-supplied input when quoting bitstring. This may allow a remote attacker to inject or manipulate SQL queries in the back-end database, allowing for the manipulation or disclosure of arbitrary data.
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.
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
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.
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.
Because Mail does not disallow CRLF in email addresses, an attacker can inject SMTP commands in specially crafted email addresses passed to RCPT TO and MAIL FROM.
Not affected by this vulnerability: * Ruby 2.4.0+ with a fix for CVE-2015-9096. * Applications that do not use SMTP delivery. * Applications that validate email addresses to not include CRLF.
The injection attack is described in Terada, Takeshi. "SMTP Injection via Recipient Email Addresses." 2015. The attacks described in the paper (Terada, p. 4) can be applied to the library without any modification.
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.
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.
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
Carefully crafted requests can cause a SystemStackError
and potentially cause a denial of service attack.
All users running an affected release should upgrade.
Rack contains a flaw as the Rack::File function creates temporary files insecurely. It is possible for a local attacker to use a symlink attack to traverse to an arbitrary file and disclose its contents
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.
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.