Rails 5.2 Vulnerabilities

Description

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller. This vulnerability has been assigned the CVE identifier CVE-2021-22904.

Versions Affected: >= 4.0.0.Not affected: < 4.0.0. Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6.

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:

class PostsController < ApplicationController
 before_action :authenticate
 private
   def authenticate
     authenticate_or_request_with_http_token do |token, options|
       # ...
     end
   end
 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.

WORKAROUNDS

The following monkey patch placed in an initializer can be used to work around the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\\t)/
end

Description

It is possible to possible to, given a global CSRF token such as the one present in the authenticity_token meta tag, forge a per-form CSRF token for any action for that session.

Versions Affected: rails < 5.2.5, rails < 6.0.4 Not affected: Applications without existing HTML injection vulnerabilities. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Given the ability to extract the global CSRF token, an attacker would be able to construct a per-form CSRF token for that session.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded.

Description

There is a possible information disclosure / unintended method execution vulnerability in Action Pack which has been assigned the CVE identifier CVE-2021-22885.

Versions Affected: >= 2.0.0. Not affected: < 2.0.0. Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

There is a possible information disclosure / unintended method execution vulnerability in Action Pack when using the redirect_to or polymorphic_url helper with untrusted user input.

Vulnerable code will look like this:

redirect_to(params[:some_param])

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

Workarounds

To work around this problem, it is recommended to use an allow list for valid parameters passed from the user. For example:

private

def check(param)
  case param
  when "valid"
    param
  else
    "/"
  end
end

def index
  redirect_to(check(params[:some_param]))
end

Or force the user input to be cast to a string like this:

def index
  redirect_to(params[:some_param].to_s)
end

Impact

Under certain circumstances response bodies will not be closed, for example a bug in a webserver (https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware. In the event a response is not notified of a close, ActionDispatch::Executor will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests, especially when interacting with ActiveSupport::CurrentAttributes.

Upgrading to the FIXED versions of Rails will ensure mitigation if this issue even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

  def ensure_completed!
    @executor.new.complete! if @executor.active?
  end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end

Description

There is a possible XSS vulnerability in Rails / Action Pack. This vulnerability has been assigned the CVE identifier CVE-2022-22577.

Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

CSP headers were only sent along with responses that Rails considered as "HTML" responses. This left API requests without CSP headers, which could possibly expose users to XSS attacks.

Releases

The FIXED releases are available at the normal locations.

Workarounds

Set a CSP for your API responses manually.

Description

There is a strong parameters bypass vector in ActionPack.

Versions Affected: rails <= 6.0.3 Not affected: rails < 4.0.0 Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

In some cases user supplied information can be inadvertently leaked from Strong Parameters. Specifically the return value of each, or each_value, or each_pair will return the underlying "untrusted" hash of data that was read from the parameters. Applications that use this return value may be inadvertently use untrusted user input. Impacted code will look something like this:

def update
  # Attacker has included the parameter: { is_admin: true }
  User.update(clean_up_params)
end

def clean_up_params
  params.each { |k, v| SomeModel.check(v) if k == :name }
end

Note the mistaken use of each in the clean_up_params method in the above example

Workarounds

Do not use the return values of each, each_value, or each_pair in your application.

Description

There is an vulnerability in rails-ujs that allows attackers to send CSRF tokens to wrong domains.

Versions Affected: rails <= 6.0.3 Not affected: Applications which don't use rails-ujs. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

This is a regression of CVE-2015-1840.

In the scenario where an attacker might be able to control the href attribute of an anchor tag or the action attribute of a form tag that will trigger a POST action, the attacker can set the href or action to a cross-origin URL, and the CSRF token will be sent.

Workarounds

To work around this problem, change code that allows users to control the href attribute of an anchor tag or the action attribute of a form tag to filter the user parameters.

For example, code like this:

link_to params

to code like this:

link_to filtered_params

def filtered_params
  # Filter just the parameters that you trust
end

Description

There is a potential Cross-Site Scripting (XSS) vulnerability in Action View's translation helpers. Views that allow the user to control the default (not found) value of the t and translate helpers could be susceptible to XSS attacks.

Impact

When an HTML-unsafe string is passed as the default for a missing translation key named html or ending in _html, the default string is incorrectly marked as HTML-safe and not escaped. Vulnerable code may look like the following examples:

<%# The welcome_html translation is not defined for the current l
ocale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translatio
n is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controll ed_string]) %>

Workarounds

Impacted users who can't upgrade to a patched Rails version can avoid this issue by manually escaping default translations with the html_escape helper (aliased as h):

<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>

Description

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

Impact

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.

Releases

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.

Workarounds

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"

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

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

Description

There is a possible XSS vulnerability in Action View tag helpers. Passing untrusted input as hash keys can lead to a possible XSS vulnerability. This vulnerability has been assigned the CVE identifier CVE-2022-27777. Versions Affected: ALL Not affected: NONE Fixed Versions: 7.0.2.4, 6.1.5.1, 6.0.4.8, 5.2.7.1

Impact

If untrusted data is passed as the hash key for tag attributes, there is a possibility that the untrusted data may not be properly escaped which can lead to an XSS vulnerability. Impacted code will look something like this:

check_box_tag('thename', 'thevalue', false, aria: { malicious_input
=> 'thevalueofaria' })

Where the "malicious_input" variable contains untrusted data. 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

Escape the untrusted data before using it as a key for tag helper methods

Description

There is a potential denial of service vulnerability in actionview. This vulnerability has been assigned the CVE identifier CVE-2019-5419.

Impact

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.

Workarounds

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 van be changed to 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)

Credits

Thanks to John Hawthorn john@hawthorn.email of GitHub

Description

There is a possible XSS vulnerability in ActionView's JavaScript literal escape helpers. Views that use the j or escape_javascript methods may be susceptible to XSS attacks.

Versions Affected: All. Not affected: None. Fixed Versions: 6.0.2.2, 5.2.4.2

Impact

There is a possible XSS vulnerability in the j and escape_javascript methods in ActionView. These methods are used for escaping JavaScript string literals. Impacted code will look something like this:

let a = <%= j unknown_input %> 

or

let a = <%= escape_javascript unknown_input %>

Releases

The 6.0.2.2 and 5.2.4.2 releases are available at the normal locations.

Workarounds

For those that can't upgrade, the following monkey patch may be used:

ActionView::Helpers::JavaScriptHelper::JS_ESCAPE_MAP.merge!({
  "" => "\\",
  "$" => "\\$"
})

module ActionView::Helpers::JavaScriptHelper
  alias :old_ej :escape_javascript
  alias :old_j :j

  def escape_javascript(javascript)
    javascript = javascript.to_s
    if javascript.empty?
      result = ""
    else
      result = javascript.gsub(/(\\|<\/|\r\n|\342\200\250|\342\200\251|[\n\r"']|[`]|[$])/u, JS_ESCAPE_MAP)
    end
    javascript.html_safe? ? result.html_safe : result
  end

  alias :j :escape_javascript
end

Description

There is a vulnerability in Active Job. This vulnerability has been assigned the CVE identifier CVE-2018-16476. Versions Affected: >= 4.2.0 Not affected: < 4.2.0 Fixed Versions: 4.2.11, 5.0.7.1, 5.1.6.1, 5.2.1.1

Impact

Carefully crafted user input can cause Active Job to deserialize it using GlobalId and allow an attacker to have access to information that they should not have.

Vulnerable code will look something like this:

MyJob.perform_later(user_input)

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

Description

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.

Description

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

Description

There is a vulnerability in Active Storage. This vulnerability has been assigned the CVE identifier CVE-2018-16477. Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 5.2.1.1

Impact

Signed download URLs generated by ActiveStorage for Google Cloud Storage service and Disk service include content-disposition and content-type parameters that an attacker can modify. This can be used to upload specially crafted HTML files and have them served and executed inline. Combined with other techniques such as cookie bombing and specially crafted AppCache manifests, an attacker can gain access to private signed URLs within a specific storage path. Vulnerable apps are those using either GCS or the Disk service in production. Other storage services such as S3 or Azure aren't affected. All users running an affected release should either upgrade or use one of the workarounds immediately. For those using GCS, it's also recommended to run the following to update existing blobs:

ActiveStorage::Blob.find_each do |blob|
  blob.send :update_service_metadata
end

Description

There is a possible code injection vulnerability in the Active Storage module of Rails. This vulnerability has been assigned the CVE identifier CVE-2022- 21831. Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.0.2.3, 6.1.4.7, 6.0.4.7, 5.2.6.3

Impact

There is a possible code injection vulnerability in the Active Storage module of Rails. This vulnerability impacts applications that use Active Storage with the imageprocessing processing in addition to the mini magick back end for image_processing. Vulnerable code will look something similar to this:

<%= image_tag blob.variant(params[:t] => params[:v]) %>

Where the transformation method or its arguments are untrusted arbitrary input. All users running an affected release should either upgrade or use one of the workarounds immediately.

Workarounds

To work around this issue, applications should implement a strict allow-list on accepted transformation methods or arguments. Additionally, a strict image magick security policy will help mitigate this issue. https://imagemagick.org/script/security-policy.php

Description

There is a vulnerability in ActiveStorage's S3 adapter that allows the Content-Length of a direct file upload to be modified by an end user. Versions Affected: rails < 5.2.4.2, rails < 6.0.3.1 Not affected: Applications that do not use the direct upload functionality of the ActiveStorage S3 adapter. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Utilizing this vulnerability, an attacker can control the Content-Length of an S3 direct upload URL without receiving a new signature from the server. This could be used to bypass controls in place on the server to limit upload size.

Workarounds

This is a low-severity security issue. As such, no workaround is necessarily until such time as the application can be upgraded

Description

There is potentially unexpected behaviour in the MemCacheStore and RedisCacheStore where, when untrusted user input is written to the cache store using the raw: true parameter, re-reading the result from the cache can evaluate the user input as a Marshalled object instead of plain text. Vulnerable code looks like:

data = cache.fetch("demo", raw: true) { untrusted_string }

Versions Affected: rails < 5.2.5, rails < 6.0.4 Not affected: Applications not using MemCacheStore or RedisCacheStore. Applications that do not use the raw option when storing untrusted user input. Fixed Versions: rails >= 5.2.4.3, rails >= 6.0.3.1

Impact

Unmarshalling of untrusted user input can have impact up to and including RCE. At a minimum, this vulnerability allows an attacker to inject untrusted Ruby objects into a web application. In addition to upgrading to the latest versions of Rails, developers should ensure that whenever they are calling Rails.cache.fetch they are using consistent values of the raw parameter for both reading and writing, especially in the case of the RedisCacheStore which does not, prior to these changes, detect if data was serialized using the raw option upon deserialization.

Workarounds

It is recommended that application developers apply the suggested patch or upgrade to the latest release as soon as possible. If this is not possible, we recommend ensuring that all user-provided strings cached using the raw argument should be double-checked to ensure that they conform to the expected format.

Description

Within the URI template implementation in Addressable, a maliciously crafted template may result in uncontrolled resource consumption, leading to denial of service when matched against a URI. In typical usage, templates would not normally be read from untrusted user input, but nonetheless, no previous security advisory for Addressable has cautioned against doing this. Users of the parsing capabilities in Addressable but not the URI template capabilities are unaffected.

Description

Summary

Loofah < 2.19.1 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1.

Description

Summary

Loofah >= 2.1.0, < 2.19.1 is vulnerable to cross-site scripting via the image/svg+xml media type in data URIs.

Mitigation

Upgrade to Loofah >= 2.19.1.

Description

Summary

Loofah >= 2.2.0, < 2.19.1 uses recursion for sanitizing CDATA sections, making it susceptible to stack exhaustion and raising a SystemStackError exception. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to Loofah >= 2.19.1. Users who are unable to upgrade may be able to mitigate this vulnerability by limiting the length of the strings that are sanitized.

Description

Summary

Nokogiri v1.13.5 upgrades the packaged version of its dependency libxml2 from v2.9.13 to v2.9.14. libxml2 v2.9.14 addresses CVE-2022-29824. This version also includes several security-related bug fixes for which CVEs were not created, including a potential double-free, potential memory leaks, and integer-overflow. Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.5 , and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.5. Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against external libraries libxml2 >= 2.9.14 which will also address these same issues.

Impact

libxml2 CVE-2022-29824 CVSS3 score: Unspecified upstream Nokogiri maintainers evaluate at 8.6 (High) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H) Note that this is different from the CVSS assessed by NVD. Type: Denial of service, information disclosure Description: In libxml2 before 2.9.14, several buffer handling functions in buf.c (xmlBuf) and tree.c (xmlBuffer) don't check for integer overflows. This can result in out- of-bounds memory writes. Exploitation requires a victim to open a crafted, multi-gigabyte XML file. Other software using libxml2's buffer functions, for example libxslt through 1.1.35, is affected as well. Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/2554a24

All versions of libml2 prior to v2.9.14 are affected. Applications parsing or serializing multi-gigabyte documents (in excess of INT_MAX bytes) may be vulnerable to an integer overflow bug in buffer handling that could lead to exposure of confidential data, modification of unrelated data, or a segmentation fault resulting in a denial-of-service. REFERENCES

libxml2 v2.9.14 release notes CVE-2022-29824 CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

Description

Summary

Nokogiri < v1.13.4 contains an inefficient regular expression that is susceptible to excessive backtracking when attempting to detect encoding in HTML documents.

Mitigation

Upgrade to Nokogiri >= 1.13.4

Description

Summary

Nokogiri v1.13.9 upgrades the packaged version of its dependency libxml2 to v2.10.3 from v2.9.14. libxml2 v2.10.3 addresses the following known vulnerabilities:

CVE-2022-2309 CVE-2022-40304 CVE-2022-40303

Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.9, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.9. Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link Nokogiri against external libraries libxml2 >= 2.10.3 which will also address these same issues.

Impact

libxml2 CVE-2022-2309

CVSS3 score: Under evaluation Type: Denial of service Description: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.

Nokogiri maintainers investigated at #2620 and determined this CVE does not affect Nokogiri users.

libxml2 CVE-2022-40304

CVSS3 score: Unspecified upstream Type: Data corruption, denial of service Description: When an entity reference cycle is detected, the entity content is cleared by setting its first byte to zero. But the entity content might be allocated from a dict. In this case, the dict entry becomes corrupted leading to all kinds of logic errors, including memory errors like double-frees.

See https://gitlab.gnome.org/GNOME/libxml2/-/commit/644a89e080bced793295f61f18aac8cfad6bece2

libxml2 CVE-2022-40303

CVSS3 score: Unspecified upstream Type: Integer overflow Description: Integer overflows with XMLPARSEHUGE

See https://gitlab.gnome.org/GNOME/libxml2/-/commit/c846986356fc149915a74972bf198abc266bc2c0

Description

In Nokogiri versions <= 1.11.0.rc3, XML Schemas parsed by Nokogiri::XML::Schema are trusted by default, allowing external resources to be accessed over the network, potentially enabling XXE or SSRF attacks. This behavior is counter to the security policy followed by Nokogiri maintainers, which is to treat all input as untrusted by default whenever possible. Please note that this security fix was pushed into a new minor version, 1.11.x, rather than a patch release to the 1.10.x branch, because it is a breaking change for some schemas and the risk was assessed to be "Low Severity".

AFFECTED VERSIONS

Nokogiri <= 1.10.10 as well as prereleases 1.11.0.rc1, 1.11.0.rc2, and 1.11.0.rc3

Mitigation

There are no known workarounds for affected versions. Upgrade to Nokogiri 1.11.0.rc4 or later. If, after upgrading to 1.11.0.rc4 or later, you wish to re-enable network access for resolution of external resources (i.e., return to the previous behavior):

Ensure the input is trusted. Do not enable this option for untrusted input. When invoking the Nokogiri::XML::Schema constructor, pass as the second parameter an instance of Nokogiri::XML::ParseOptions with the NONET flag turned off.

So if your previous code was:

# in v1.11.0.rc3 and earlier, this call allows resources to be acces sed over the network
# but in v1.11.0.rc4 and later, this call will disallow network access f or external resources
schema = Nokogiri::XML::Schema.new(schema)

# in v1.11.0.rc4 and later, the following is equivalent to the code above
# (the second parameter is optional, and this demonstrates its default value)
schema = Nokogiri::XML::Schema.new(schema, Nokogiri::XML::ParseOptions::DEFAULT_SCHEMA)

Then you can add the second parameter to indicate that the input is trusted by changing it to:

# in v1.11.0.rc3 and earlier, this would raise an ArgumentError
# but in v1.11.0.rc4 and later, this allows resources to be accessed over the network
schema = Nokogiri::XML::Schema.new(trusted_schema, Nokogiri::XML::ParseOptions.new.nononet)

Summary

Nokogiri < v1.13.6 does not type-check all inputs into the XML and HTML4 SAX parsers. For CRuby users, this may allow specially crafted untrusted inputs to cause illegal memory access errors (segfault) or reads from unrelated memory.

Severity

The Nokogiri maintainers have evaluated this as High 8.2 (CVSS3.1).

Mitigation

CRuby users should upgrade to Nokogiri >= 1.13.6 . JRuby users are not affected.

workarounds

To avoid this vulnerability in affected applications, ensure the untrusted input is a String by calling #to_s or equivalent.

Summary

Nokogiri v1.13.4 updates the vendored xerces:xercesImpl from 2.12.0 to 2.12.2, which addresses CVE-2022-23437. That CVE is scored as CVSS 6.5 "Medium" on the NVD record. Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4-label="code line">< 1.13.4.

Mitigation

Upgrade to Nokogiri >= v1.13.4 .

Impact

CVE-2022-23437 IN XERCES-J

Severity: Medium Type: CWE-91 XML Injection (aka Blind XPath Injection) Description: There's a vulnerability within the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This causes, the XercesJ XML parser to wait in an infinite loop, which may sometimes consume system resources for prolonged duration. This vulnerability is present within XercesJ version 2.12.1 and the previous versions. See also: https://github.com/advisories/GHSA-h65f-jvqw- m9fj

Summary

Nokogiri v1.13.4 updates the vendored org.cyberneko.html library to 1.9.22.noko2 which addresses CVE-2022-24839. That CVE is rated 7.5 (High Severity). See GHSA-9849-p7jc-9rmv for more information. Please note that this advisory only applies to the JRuby implementation of Nokogiri < 1.13.4.

Mitigation

Upgrade to Nokogiri >= 1.13.4.

Impact

CVE-2022-24839 IN NEKOHTML

Severity: High 7.5 Type: CWE-400 Uncontrolled Resource Consumption Description: The fork of org.cyberneko.html used by Nokogiri (Rubygem) raises a java.lang.OutOfMemoryError exception when parsing ill-formed HTML markup. See also: GHSA-9849-p7jc-9rmv

Summary

Nokogiri v1.13.4 updates the vendored zlib from 1.2.11 to 1.2.12, which addresses CVE-2018-25032. That CVE is scored as CVSS 7.4 "High" on the NVD record as of 2022-04-05. Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.4, and only if the packaged version of zlib is being used. Please see this document for a complete description of which platform gems vendor zlib. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's zlib release announcements.

Mitigation

Upgrade to Nokogiri >= v1.13.4.

Impact

CVE-2018-25032 IN ZLIB Severity: High Type: CWE-787 Out of bounds write Description: zlib before 1.2.12 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches.

Summary

Nokogiri v1.11.4 updates the vendored libxml2 from v2.9.10 to v2.9.12 which address:

CVE-2019-20388 (Medium severity) CVE-2020-24977 (Medium severity) CVE-2021-3517 (Medium severity) CVE-2021-3518 (Medium severity) CVE-2021-3537 (Low severity) CVE-2021-3541 (Low severity)

Note that two additional CVEs were addressed upstream but are not relevant to this release. CVE-2021-3516 via xmllint is not present in Nokogiri, and CVE-2020-7595 has been patched in Nokogiri since v1.10.8 (see #1992). Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.11.4 , and only if the packaged version of libxml2 is being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 release announcements.

Mitigation

Upgrade to Nokogiri >= 1.11.4.

Impact

I've done a brief analysis of the published CVEs that are addressed in this upstream release. The libxml2 maintainers have not released a canonical set of CVEs, and so this list is pieced together from secondary sources and may be incomplete. All information below is sourced from security.archlinux.org, which appears to have the most up-to-date information as of this analysis. CVE-2019-20388

Severity: Medium Type: Denial of service

Description: A memory leak was found in the xmlSchemaValidateStream function of libxml2. Applications that use this library may be vulnerable to memory not being freed leading to a denial of service. Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d93

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2020-7595

Severity: Medium Type: Denial of service

Description: xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation. Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/0e1a49c89076

This has been patched in Nokogiri since v1.10.8 (see #1992). CVE-2020-24977

Severity: Medium Type: Information disclosure

Description: GNOME project libxml2 <= 2.9.10 has a global buffer over-read vulnerability in xmlEncodeEntitiesInternal at libxml2/entities.c. Fixed: https://gitlab.gnome.org/GNOME/libxml2/commit/50f06b3efb638efb0abd95dc62dc

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3516

Severity: Medium Type: Arbitrary code execution (no remote vector)

Description: A use-after-free security issue was found libxml2 before version 2.9.11 when "xmllint --html --push" is used to process crafted files. Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/230 Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1358d157d0bd83be1dfe356a69213df9fac0b539

Verified that the fix commit first appears in v2.9.11. This vector does not exist within Nokogiri, which does not ship xmllint. CVE-2021-3517

Severity: Medium Type: Arbitrary code execution

Description: A heap-based buffer overflow was found in libxml2 before version 2.9.11 when processing truncated UTF-8 input. Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235 Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3518

Severity: Medium Type: Arbitrary code execution

Description: A use-after-free security issue was found in libxml2 before version 2.9.11 in xmlXIncludeDoProcess() in xinclude.c when processing crafted files. Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/237 Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/1098c30a040e72a4654968547f415be4e4c40fe7

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3537

Severity: Low Type: Denial of service

Description: It was found that libxml2 before version 2.9.11 did not propagate errors while parsing XML mixed content, causing a NULL dereference. If an untrusted XML document was parsed in recovery mode and post- validated, the flaw could be used to crash the application. Issue: https://gitlab.gnome.org/GNOME/libxml2/-/issues/243 Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/babe75030c7f64a37826bb3342317134568bef61

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3541

Severity: Low Type: Denial of service

Description: A security issue was found in libxml2 before version 2.9.11. Exponential entity expansion attack its possible bypassing all existing protection mechanisms and leading to denial of service. Fixed: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8598060bacada41a0eb09d95c97744ff4e428f8e

Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4, however Nokogiri's default parse options prevent the attack from succeeding (it is necessary to opt into DTDLOAD which is off by default). For more details supporting this analysis of this CVE, please visit #2233.

summary

Nokogiri v1.13.2 upgrades two of its packaged dependencies:

vendored libxml2 from v2.9.12 to v2.9.13

vendored libxslt from v1.1.34 to v1.1.35

Those library versions address the following upstream CVEs:

libxslt: CVE-2021-30560 (CVSS 8.8, High severity)

libxml2: CVE-2022-23308 (Unspecified severity, see more information below)

Those library versions also address numerous other issues including performance improvements, regression fixes, and bug fixes, as well as memory leaks and other use-after-free issues that were not assigned CVEs. Please note that this advisory only applies to the CRuby implementation of Nokogiri < 1.13.2, and only if the packaged libraries are being used. If you've overridden defaults at installation time to use system libraries instead of packaged libraries, you should instead pay attention to your distro's libxml2 and libxslt release announcements.

Mitigation

Upgrade to Nokogiri >= 1.13.2.

Users who are unable to upgrade Nokogiri may also choose a more complicated mitigation: compile and link an older version Nokogiri against external libraries libxml2 >= 2.9.13 and libxslt >= 1.1.35, which will also address these same CVEs.

Impact

libxslt CVE-2021- 30560 CVSS3 score: 8.8 (High)

Fixed by https://gitlab.gnome.org/GNOME/libxslt/-/commit/50f9c9c

All versions of libxslt prior to v1.1.35 are affected.

Applications using untrusted XSL stylesheets to transform XML are vulnerable to a denial-of-service attack and should be upgraded immediately. libxml2 CVE-2022-23308 * As of the time this security advisory was published, there is no officially published information available about this CVE's severity. The above NIST link does not yet have a published record, and the libxml2 maintainer has declined to provide a severity score. * Fixed by https://gitlab.gnome.org/GNOME/libxml2/-/commit/652dd12 * Further explanation is at https://mail.gnome.org/archives/xml/2022- February/msg00015.html The upstream commit and the explanation linked above indicate that an application may be vulnerable to a denial of service, memory disclosure, or code execution if it parses an untrusted document with parse options DTDVALID set to true, and NOENT set to false.

An analysis of these parse options:

While NOENT is off by default for Document, DocumentFragment, Reader, and Schema parsing, it is on by default for XSLT (stylesheet) parsing in Nokogiri v1.12.0 and later. DTDVALID is an option that Nokogiri does not set for any operations, and so this CVE applies only to applications setting this option explicitly.

It seems reasonable to assume that any application explicitly setting the parse option DTDVALID when parsing untrusted documents is vulnerable and should be upgraded immediately.

Severity

The Nokogiri maintainers have evaluated this as High Severity 7.5 (CVSS3.0) for JRuby users. (This security advisory does not apply to CRuby users.)

Impact

In Nokogiri v1.12.4 and earlier, on JRuby only, the SAX parser resolves external entities by default.

Users of Nokogiri on JRuby who parse untrusted documents using any of these classes are affected:

Nokogiri::XML::SAX::Parser
Nokogiri::HTML4::SAX::Parser or its alias
Nokogiri::HTML::SAX::Parser
Nokogiri::XML::SAX::PushParser
Nokogiri::HTML4::SAX::PushParser or its alias
Nokogiri::HTML::SAX::PushParser

Impact

JRuby users should upgrade to Nokogiri v1.12.5 or later. There are no workarounds available for v1.12.4 or earlier. CRuby users are not affected.

Impact

The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A puma server which received more concurrent keep-alive connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections.

Patches

This problem has been fixed in puma 4.3.8 and 5.3.1.

Workarounds

Setting queue_requests false also fixes the issue. This is not advised when using puma without a reverse proxy, such as nginx or apache, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small. A git patch is available here for those using unsupported versions of Puma.

Impact

Prior to puma version 5.5.0, using puma with a proxy which forwards LF characters as line endings could allow HTTP request smuggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to another unknown client. This behavior (forwarding LF characters as line endings) is very uncommon amongst proxy servers, so we have graded the impact here as "low". Puma is only aware of a single proxy server which has this behavior. If the proxy uses persistent connections and the client adds another request in via HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two requests, and when processing the second request, send back a response that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another request for a different client, the second response from the first client will be sent to the second client.

Patches

This vulnerability was patched in Puma 5.5.1 and 4.3.9.

Workarounds

This vulnerability only affects Puma installations without any proxy in front. Use a proxy which does not forward LF characters as line endings. Proxies which do not forward LF characters as line endings:

Nginx Apache Haproxy Caddy Traefik (>2.4.25)

Possible breakage

If you are dealing with legacy clients that want to send LF as a line ending in an HTTP header, this will cause those clients to receive a 400 error.

References

HTTP Request Smuggling

Impact

When using Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230 standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow requests to be smuggled via the front-end proxy to Puma. The following vulnerabilities are addressed by this advisory: - Lenient parsing of Transfer-Encoding headers, when unsupported encodings should be rejected and the final encoding must be chunked . - Lenient parsing of malformed Content-Length headers and chunk sizes, when only digits and hex digits should be allowed. - Lenient parsing of duplicate Content-Length headers, when they should be rejected. - Lenient parsing of the ending of chunked segments, when they should end with \r\n .

Patches

The vulnerability has been fixed in 5.6.4 and 4.3.12.

Workarounds

When deploying a proxy in front of Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard. These proxy servers are known to have "good" behavior re: this standard and upgrading Puma may not be necessary. Users are encouraged to validate for themselves.

Nginx (latest) Apache (latest) Haproxy 2.5+ Caddy (latest) Traefik (latest)

References

HTTP Request Smuggling

Impact

Prior to puma version 5.6.2 , puma may not always call close on the response body. Rails, prior to version 7.0.2.2 , depended on the response body being closed in order for its CurrentAttributes implementation to work correctly.

From Rails:

Under certain circumstances response bodies will not be closed, for example a bug in a webserver[1] or a bug in a Rack middleware. In the event a response is not notified of a close, ActionDispatch::Executor will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests, especially when interacting with ActiveSupport::CurrentAttributes.

The combination of these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information leakage.

Patches

This problem is fixed in Puma versions 5.6.2 and 4.3.11.

This problem is fixed in Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

See: https://github.com/advisories/GHSA-wh98-p28r-vrc9 for details about the rails vulnerability

Upgrading to a patched Rails or Puma version fixes the vulnerability.

Workarounds

Upgrade to Rails versions 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. The Rails CVE includes a middleware that can be used instead.

Description

There is a possible shell escape sequence injection vulnerability in the Lint and CommonLogger components of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30123.

Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted requests can cause shell escape sequences to be written to the terminal via Rack's Lint middleware and CommonLogger middleware. These escape sequences can be leveraged to possibly execute commands in the victim's terminal. Impacted applications will have either of these middleware installed, and vulnerable apps may have something like this:

use Rack::Lint

Or

use Rack::CommonLogger

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

Workarounds

Remove these middleware from your application

Description

There is a possible denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30122.

Versions Affected: >= 1.2 Not affected: < 1.2 Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1

Impact

Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability.

Impacted code will use Rack's multipart parser to parse multipart posts. This includes directly using the multipart parser like this:

params = Rack::Multipart.parse_multipart(env)

But it also includes reading POST data from a Rack request object like this:

p request.POST # read POST data
p request.params # reads both query params and POST data

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

Workarounds

There are no feasible workarounds for this issue

Description

It is possible to forge a secure or host-only cookie prefix in Rack using an arbitrary cookie write by using URL encoding (percent-encoding) on the name of the cookie. This could result in an application that is dependent on this prefix to determine if a cookie is safe to process being manipulated into Name: rack Version: 2.2.2 ID: CVE-2020-8184 LINK processing an insecure or cross-origin request. This vulnerability has been assigned the CVE identifier CVE-2020-8184. Versions Affected: rack < 2.2.3, rack < 2.1.4 Not affected: Applications which do not rely on _Host- and _Secure- prefixes to determine if a cookie is safe to process Fixed Versions: rack >= 2.2.3, rack >= 2.1.4.

Impact

An attacker may be able to trick a vulnerable application into processing an insecure (non-SSL) or cross-origin request if they can gain the ability to write arbitrary cookies that are sent to the application.

Workarounds

If your application is impacted but you cannot upgrade to the released versions or apply the provided patch, this issue can be temporarily addressed by adding the following workaround:

module Rack
  module Utils
    module_function def parse_cookies_header(header)
      return {} unless header
        header.split(/[;] */n).each_with_object({}) do |cookie, cookies|
        next if cookie.empty?
        key, value = cookie.split('=', 2)
        cookies[key] = (unescape(value) rescue value) unless cookies.key?(key)
      end
    end
  end
end

summary

rails-html-sanitizer >= 1.0.3, < 1.4.4 is vulnerable to cross-site scripting via data URIs when used in combination with Loofah >= 2.1.0.

Migration

Upgrade to rails-html-sanitizer >= 1.4.4.

Description

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer. This vulnerability has been assigned the CVE identifier CVE-2022-32209.

Versions Affected: ALL Not affected: NONE Fixed Versions: v1.4.3

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags to allow both select and style elements.

Code is only impacted if allowed tags are being overridden. This may be done via application configuration:

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["select", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view Or it may be done with a :tags option to the Action View helper sanitize:

<%= sanitize @comment.body, tags: ["select", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize Or it may be done with Rails::Html::SafeListSanitizer directly:

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]

or

# instance-level option
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["select", "style"])

All users overriding the allowed tags by any of the above mechanisms to include both "select" and "style" should either upgrade or use one of the workarounds immediately.

Workarounds

Remove either select or style from the overridden allowed tags.

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer. This is due to an incomplete fix of CVE-2022-32209.

Versions affected: ALL Not affected: NONE Fixed versions: 1.4.4

Summary

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags to allow both "select" and "style" elements.

Code is only impacted if allowed tags are being overridden using either of the following two mechanisms:

Using the Rails configuration config.action_view.sanitized_allow_tags= :

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["select", "style"]

(see https://guides.rubyonrails.org/configuring.html#configuring-action-view)

Using the class method Rails::Html::SafeListSanitizer.allowed_tags= :

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]

All users overriding the allowed tags by either of the above mechanisms to include both "select" and "style" should either upgrade or use one of the workarounds immediately.

NOTE: Code is not impacted if allowed tags are overridden using either of the following mechanisms:

the :tags option to the Action View helper method sanitize .

the :tags option to the instance method SafeListSanitizer#sanitize .

Workarounds

Remove either "select" or "style" from the overridden allowed tags.

Summary

Certain configurations of rails-html-sanitizer < 1.4.4 use an inefficient regular expression that is susceptible to excessive backtracking when attempting to sanitize certain SVG attributes. This may lead to a denial of service through CPU resource consumption.

Mitigation

Upgrade to rails-html-sanitizer >= 1.4.4.

Summary

There is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.

Versions affected: ALL Not affected: NONE Fixed versions: 1.4.4

Impact

A possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags in either of the following ways:

allow both "math" and "style" elements,

or allow both "svg" and "style" elements

Code is only impacted if allowed tags are being overridden. Applications may be doing this in four different ways:

using application configuration:

# In config/application.rb
config.action_view.sanitized_allowed_tags = ["math", "style"]
# or
config.action_view.sanitized_allowed_tags = ["svg", "style"]

see https://guides.rubyonrails.org/configuring.html#configuring-action-view

using a :tags option to the Action View helper sanitize:

<%= sanitize @comment.body, tags: ["math", "style"] %>
<%# or %>
<%= sanitize @comment.body, tags: ["svg", "style"] %>

see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize

using Rails::Html::SafeListSanitizer class method allowed_tags= :

# class-level option
Rails::Html::SafeListSanitizer.allowed_tags = ["math", "style"]
# or
Rails::Html::SafeListSanitizer.allowed_tags = ["svg", "style"]

using a :tags options to the Rails::Html::SafeListSanitizer instance method sanitize:

# instance-level option
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["math", "style"])
# or
Rails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: ["svg", "style"])

All users overriding the allowed tags by any of the above mechanisms to include (("math" or "svg") and "style") should either upgrade or use one of the workarounds immediately.

Workarounds

Remove "style" from the overridden allowed tags, or remove "math" and "svg" from the overridden allowed tags.

Description

There is a possible a possible remote code executing exploit in Rails when in development mode. This vulnerability has been assigned the CVE identifier CVE-2019-5420.

Versions Affected: 6.0.0.X, 5.2.X. Not affected: < 5.2.0 Fixed Versions: 6.0.0.beta3, 5.2.2.1

Impact

With some knowledge of a target application it is possible for an attacker to guess the automatically generated development mode secret token. This secret token can be used in combination with other Rails internals to escalate to a remote code execution exploit.

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

Workarounds

This issue can be mitigated by specifying a secret key in development mode. In "config/environments/development.rb" add this: config.secretkeybase = SecureRandom.hex(64)

Credits

Thanks to ooooooo_q

Impact

AFFECTED VERSIONS 0.3.60 and earlier. 1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo- data).

Vulnerability

With the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and later and built-in to earlier versions), time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with require on demand. In the affected versions, TZInfo::Timezone.get fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, TZInfo::Timezone.get can be made to load unintended files with require , executing them within the Ruby process.

For example, with version 1.2.9, you can run the following to load a file with path /tmp/payload.rb:

TZInfo::Timezone.get(\"foo\ /../../../../../../../../../../../../../../../../tmp/payload\") 

The exact number of parent directory traversals needed will vary depending on the location of the tzinfo-data gem.

TZInfo versions 1.2.6 to 1.2.9 can be made to load files from outside of the Ruby load path. Versions up to and including 1.2.5 can only be made to load files from directories within the load path.

This could be exploited in, for example, a Ruby on Rails application using tzinfo version 1.2.9, that allows file uploads and has a time zone selector that accepts arbitrary time zone identifiers. The CVSS score and severity have been set on this basis.

Versions 2.0.0 and later are not vulnerable

Patches

Versions 0.3.61 and 1.2.10 include fixes to correctly validate time zone identifiers.

Note that version 0.3.61 can still load arbitrary files from the Ruby load path if their name follows the rules for a valid time zone identifier and the file has a prefix of tzinfo/definition within a directory in the load path. For example if /tmp/upload was in the load path, then TZInfo::Timezone.get('foo') could load a file with path /tmp/upload/tzinfo/definition/foo.rb. Applications should ensure that untrusted files are not placed in a directory on the load path.

Workarounds

As a workaround, the time zone identifier can be validated before passing to TZInfo::Timezone.get by ensuring it matches the regular expression \\A[A-Za-z0-9+\\-_]+(?:\\/[A-Za-z0-9+\\-_]+)*\\z.

Impact

The ReDoS flaw allows an attacker to exhaust the server's capacity to process incoming requests by sending a WebSocket handshake request containing a header of the following form:

Sec-WebSocket-Extensions: a; b="\c\c\c\c\c\c\c\c\c\c ...

That is, a header containing an unclosed string parameter value whose content is a repeating two-byte sequence of a backslash and some other character. The parser takes exponential time to reject this header as invalid, and this will block the processing of any other work on the same thread. Thus if you are running a single-threaded server, such a request can render your service completely unavailable.

Workarounds

There are no known work-arounds other than disabling any public-facing WebSocket functionality you are operating.