Databases on Rails. Build a persistent domain model by mapping database tables to Ruby classes. Strong conventions for associations, validations, aggregations, migrations, and testing come baked-in.
When serialized columns that use YAML (the default) are deserialized, Rails uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an attacker can manipulate data in the database (via means like SQL injection), then it may be possible for the attacker to escalate to an RCE.
There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.
There is a potential denial of service vulnerability present in ActiveRecord’s PostgreSQL adapter.
This has been assigned the CVE identifier CVE-2022-44566.
Versions Affected: All. Not affected: None. Fixed Versions: 5.2.8.15 (Rails LTS, which is a paid service and not part of the rubygem), 6.1.7.1, 7.0.4.1
Impact:
In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.
Releases
The fixed releases are available at the normal locations.
Workarounds
Ensure that user supplied input which is provided to ActiveRecord clauses do not contain integers wider than a signed 64bit representation or floats.
Patches
To aid users who aren’t able to upgrade immediately we have provided patches for the supported release series in accordance with our maintenance policy 1 regarding security issues. They are in git-am format and consist of a single changeset.
6-1-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 6.1 series
7-0-Added-integer-width-check-to-PostgreSQL-Quoting.patch - Patch for 7.0 series
Active Record in Ruby on Rails 4.2.x before 4.2.7.1 does not properly consider differences in parameter handling between the Active Record component and the JSON implementation, which allows remote attackers to bypass intended database-query restrictions and perform NULL checks or trigger missing WHERE clauses via a crafted request, as demonstrated by certain [nil] values, a related issue to CVE-2012-2660, CVE-2012-2694, and CVE-2013-0155.
Active Record in Ruby on Rails 4.2.x before 4.2.7.1 does not properly consider differences in parameter handling between the Active Record component and the JSON implementation, which allows remote attackers to bypass intended database-query restrictions and perform NULL checks or trigger missing WHERE clauses via a crafted request, as demonstrated by certain [nil] values, a related issue to CVE-2012-2660, CVE-2012-2694, and CVE-2013-0155.
There is a vulnerability when Active Record is used in conjunction with JSON
parameter parsing. This vulnerability is similar to CVE-2012-2660,
CVE-2012-2694 and CVE-2013-0155.
Impact
Due to the way Active Record interprets parameters in combination with the way
that JSON parameters are parsed, it is possible for an attacker to issue
unexpected database queries with IS NULL or empty where clauses. This issue
does not let an attacker insert arbitrary values into an SQL query, however
they can cause the query to check for NULL or eliminate a WHERE clause when
most users wouldn't expect it.
For example, a system has password reset with token functionality:
unless params[:token].nil?
user = User.find_by_token(params[:token])
user.reset_password!
end
An attacker can craft a request such that params[:token] will return
[nil]. The [nil] value will bypass the test for nil, but will still add
an IN ('xyz', NULL) clause to the SQL query.
Similarly, an attacker can craft a request such that params[:token] will
return an empty hash. An empty hash will eliminate the WHERE clause of the
query, but can bypass the nil? check.
Note that this impacts not only dynamic finders (find_by_*) but also
relations (User.where(:name => params[:name])).
All users running an affected release should either upgrade or use one of the
work arounds immediately. All users running an affected release should upgrade
immediately. Please note, this vulnerability is a variant of CVE-2012-2660,
CVE-2012-2694, and CVE-2013-0155. Even if you upgraded to address those
issues, you must take action again.
If this chance in behavior impacts your application, you can manually decode
the original values from the request like so:
`ActiveSupport::JSON.decode(request.body)`
Workarounds
This problem can be mitigated by casting the parameter to a string before
passing it to Active Record. For example:
unless params[:token].nil? || params[:token].to_s.empty?
user = User.find_by_token(params[:token].to_s)
user.reset_password!
end
There is a possible DoS vulnerability in the PostgreSQL adapter in Active
Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.
Carefully crafted input can cause the input validation in the money type of
the PostgreSQL adapter in Active Record to spend too much time in a regular
expression, resulting in the potential for a DoS attack.
This only impacts Rails applications that are using PostgreSQL along with
money type columns that take user input.
Workarounds
In the case a patch can't be applied, the following monkey patch can be used
in an initializer:
module ActiveRecord
module ConnectionAdapters
module PostgreSQL
module OID # :nodoc:
class Money < Type::Decimal # :nodoc:
def cast_value(value)
return value unless ::String === value
value = value.sub(/^\((.+)\)$/, '-\1') # (4)
case value
when /^-?\D*+[\d,]+\.\d{2}$/ # (1)
value.gsub!(/[^-\d.]/, "")
when /^-?\D*+[\d.]+,\d{2}$/ # (2)
value.gsub!(/[^-\d,]/, "").sub!(/,/, ".")
end
super(value)
end
end
end
end
end
end
There is a possible escalation to RCE when using YAML serialized columns in
Active Record. This vulnerability has been assigned the CVE identifier
CVE-2022-32224.
Versions Affected: All.
Not affected: None
Fixed Versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, 5.2.8.1
Impact
When serialized columns that use YAML (the default) are deserialized, Rails
uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an
attacker can manipulate data in the database (via means like SQL injection),
then it may be possible for the attacker to escalate to an RCE.
Impacted Active Record models will look something like this:
class User < ApplicationRecord
serialize :options # Vulnerable: Uses YAML for serialization
serialize :values, Array # Vulnerable: Uses YAML for serialization
serialize :values, JSON # Not vulnerable
end
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.
The released versions change the default YAML deserializer to use
YAML.safe_load, which prevents deserialization of possibly dangerous
objects. This may introduce backwards compatibility issues with existing
data.
In order to cope with that situation, the released version also contains two
new Active Record configuration options. The configuration options are as
follows:
config.active_record.use_yaml_unsafe_load
When set to true, this configuration option tells Rails to use the old
unsafe YAML loading strategy, maintaining the existing behavior but leaving
the possible escalation vulnerability in place. Setting this option to true
is not recommended, but can aid in upgrading.
The safe YAML loading method does not allow all classes to be deserialized
by default. This option allows you to specify classes deemed safe in your
application. For example, if your application uses Symbol and Time in
serialized data, you can add Symbol and Time to the allowed list as follows:
There is a potential denial of service vulnerability present in
ActiveRecord’s PostgreSQL adapter.
This has been assigned the CVE identifier CVE-2022-44566.
Versions Affected: All.
Not affected: None.
Fixed Versions: 5.2.8.15 (Rails LTS), 6.1.7.1, 7.0.4.1
Impact
In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a
64bit signed integer is provided to the PostgreSQL connection adapter, it
will treat the target column type as numeric. Comparing integer values
against numeric values can result in a slow sequential scan resulting in
potential Denial of Service.
Workarounds
Ensure that user supplied input which is provided to ActiveRecord clauses do
not contain integers wider than a signed 64bit representation or floats.
