activerecord 4.2.1.rc2

5 security vulnerabilities found in version 4.2.1.rc2

Possible RCE escalation bug with Serialized Columns in Active Record

critical severity CVE-2022-32224
critical severity CVE-2022-32224
Patched versions: ~> 5.2.8, >= 5.2.8.1, ~> 6.0.5, >= 6.0.5.1, ~> 6.1.6, >= 6.1.6.1, >= 7.0.3.1

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.

  • config.active_record.yaml_column_permitted_classes

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:

config.active_record.yaml_column_permitted_classes = [Symbol, Date, Time]

Workarounds

There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.

Denial of Service Vulnerability in ActiveRecord’s PostgreSQL adapter

high severity CVE-2022-44566
high severity CVE-2022-44566
Patched versions: ~> 5.2.8, >= 5.2.8.15, ~> 6.1.7, >= 6.1.7.1, >= 7.0.4.1

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.

Unsafe Query Generation Risk in Active Record

high severity CVE-2016-6317
high severity CVE-2016-6317
Patched versions: >= 4.2.7.1
Unaffected versions: < 4.2.0, >= 5.0.0

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

Possible DoS Vulnerability in Active Record PostgreSQL adapter

medium severity CVE-2021-22880
medium severity CVE-2021-22880
Patched versions: ~> 5.2.4, >= 5.2.4.5, ~> 6.0.3, >= 6.0.3.5, >= 6.1.2.1
Unaffected versions: < 4.2.0

There is a possible DoS vulnerability in the PostgreSQL adapter in Active Record. This vulnerability has been assigned the CVE identifier CVE-2021-22880.

Versions Affected: >= 4.2.0 Not affected: < 4.2.0 Fixed Versions: 6.1.2.1, 6.0.3.5, 5.2.4.5

Impact

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

Nested attributes rejection proc bypass in Active Record

medium severity CVE-2015-7577
medium severity CVE-2015-7577
Patched versions: >= 5.0.0.beta1.1, ~> 4.2.5, >= 4.2.5.1, ~> 4.1.14, >= 4.1.14.1, ~> 3.2.22.1
Unaffected versions: ~> 3.0.0, < 3.0.0

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

Impact

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.

Releases

The FIXED releases are available at the normal locations.

Workarounds

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

Patches

To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

  • 3-2-nested-attributes-reject-if-bypass.patch - Patch for 3.2 series
  • 4-1-nested-attributes-reject-if-bypass.patch - Patch for 4.1 series
  • 4-2-nested-attributes-reject-if-bypass.patch - Patch for 4.2 series
  • 5-0-nested-attributes-reject-if-bypass.patch - Patch for 5.0 series

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.

Credits

Thank you to Justin Coyne for reporting the problem and working with us to fix it.

No officially reported memory leakage issues detected.


This gem version does not have any officially reported memory leaked issues.

No license issues detected.


This gem version has a license in the gemspec.

This gem version is available.


This gem version has not been yanked and is still available for usage.