Vulnerable Gem: actionpack@3.2.22.5

Name:

actionpack

Version:

3.2.22.5

ID:

CVE-2021-22885

Link

Possible Information Disclosure / Unintended Method Execution in Action Pack

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

Vulnerable Gem: actionpack@3.2.22.5

Name:

actionpack

Version:

3.2.22.5

ID:

CVE-2020-8166

Link

Ability to forge per-form CSRF tokens given a global CSRF token

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.

Vulnerable Gem: activerecord@3.2.22.5

Name:

activerecord

Version:

3.2.22.5

ID:

CVE-2022-32224

Link

Possible RCE escalation bug with Serialized Columns in Active Record

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.

Vulnerable Gem: activeresource@3.2.22.5

Name:

activeresource

Version:

3.2.22.5

ID:

CVE-2020-8151

Link

activeresource Gem for Ruby lib/active_resource/base.rb element_path Lack of Encoding

Description:

activeresource contains a lack of encoding flaw in the elementpath function of lib/activeresource/base.rb.

There is an issue with the way Active Resource encodes data before querying the back end server. This encoding mechanism can allow specially crafted requests to possibly access data that may not be expected.

Impacted code will look something like this:

require 'activeresource'

class Test < ActiveResource::Base
  self.site = 'http://127.0.0.1:3000'
end

Test.exists?(untrusted_user_input)

Where untrusted user input is passed to an Active Resource model. Specially crafted untrusted input can cause Active Resource to access data in an unexpected way and possibly leak information.

Workarounds

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

module ActiveResource
 class Base
   class << self
     def element_path(id, prefix_options = {}, query_options = nil)
       check_prefix_options(prefix_options)

       prefix_options, query_options = split_options(prefix_options) if query_options.nil?
       "#{prefix(prefix_options)}#{collection_name}/#{URI.encode_www_form_component(id.to_s)}#{format_extension}#{query_string(query_options)}"
     end
   end
 end
end

Vulnerable Gem: activesupport@3.2.22.5

Name:

activesupport

Version:

3.2.22.5

ID:

CVE-2020-8165

Link

Potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore

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.

Vulnerable Gem: addressable@2.3.6

Name:

addressable

Version:

2.3.6

ID:

CVE-2021-32740

Link

Regular Expression Denial of Service in Addressable templates

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.

Vulnerable Gem: better_errors@1.0.1

Name:

better_errors

Version:

1.0.1

ID:

CVE-2021-39197

Link

Older releases of better_errors open to Cross-Site Request Forgery attack

Description:

Impact

bettererrors prior to 2.8.0 did not implement CSRF protection for its internal requests. It also did not enforce the correct "Content-Type" header for these requests, which allowed a cross-origin "simple request" to be made without CORS protection. These together left an application with bettererrors enabled open to cross-origin attacks.

As a developer tool, bettererrors documentation strongly recommends addition only to the development bundle group, so this vulnerability should only affect development environments. Please ensure that your project limits bettererrors to the development group (or the non-Rails equivalent).

Patches

Starting with release 2.8.x, CSRF protection is enforced. It is recommended that you upgrade to the latest release, or minimally to "~> 2.8.3".

Workarounds

There are no known workarounds to mitigate the risk of using older releases of better_errors.

References

Chris Moberly provided an example attack that uses a now-patched vulnerability of webpack-dev-server in conjunction with Better Errors

For more information

If you have any questions or comments about this advisory, please - Add to the discussion in better_errors - Open an issue in better_errors

Vulnerable Gem: cocaine@0.4.2

Name:

cocaine

Version:

0.4.2

ID:

CVE-2013-4457

Link

Cocaine Gem for Ruby contains a flaw

Description:

Cocaine Gem for Ruby contains a flaw that is due to the method of variable interpolation used by the program. With a specially crafted object, a context-dependent attacker can execute arbitrary commands.

Vulnerable Gem: doorkeeper@3.1.0

Name:

doorkeeper

Version:

3.1.0

ID:

CVE-2016-6582

Link

Doorkeeper gem does not revoke tokens & uses wrong auth/auth method

Description:

Doorkeeper failed to implement OAuth 2.0 Token Revocation (RFC 7009) in the following ways:

Public clients making valid, unauthenticated calls to revoke a token would not have their token revoked
Requests were not properly authenticating the client credentials but were, instead, looking at the access token in a second location
Because of 2, the requests were also not authorizing confidential clients' ability to revoke a given token. It should only revoke tokens that belong to it.

The security implication is: OAuth 2.0 clients who "log out" a user expect to have the corresponding access & refresh tokens revoked, preventing an attacker who may have already hijacked the session from continuing to impersonate the victim. Because of the bug described above, this is not the case. As far as OWASP is concerned, this counts as broken authentication design.

MITRE has assigned CVE-2016-6582 due to the security issues raised. An attacker, thanks to 1, can replay a hijacked session after a victim logs out/revokes their token. Additionally, thanks to 2 & 3, an attacker via a compromised confidential client could "grief" other clients by revoking their tokens (albeit this is an exceptionally narrow attack with little value).

Vulnerable Gem: doorkeeper@3.1.0

Name:

doorkeeper

Version:

3.1.0

ID:

CVE-2018-1000088

Link

Doorkeeper gem has stored XSS on authorization consent view

Description:

Stored XSS on the OAuth Client's name will cause users being prompted for consent via the "implicit" grant type to execute the XSS payload.

The XSS attack could gain access to the user's active session, resulting in account compromise.

Any user is susceptible if they click the authorization link for the malicious OAuth client. Because of how the links work, a user cannot tell if a link is malicious or not without first visiting the page with the XSS payload.

If 3rd parties are allowed to create OAuth clients in the app using Doorkeeper, upgrade to the patched versions immediately.

Description:

Impact

Passing HTML containing <option> elements from untrusted sources - even after sanitizing them - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.

Workarounds

To workaround this issue without upgrading, use DOMPurify with its SAFE_FOR_JQUERY option to sanitize the HTML string before passing it to a jQuery method.

Vulnerable Gem: jquery-rails@2.0.2

Name:

jquery-rails

Version:

2.0.2

ID:

CVE-2015-1840

Link

CSRF Vulnerability in jquery-rails

Description:

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 " https://attacker.com" (note the leading space) that will be passed to JQuery, who will see this as a same origin request, and send the user's CSRF token to the attacker domain.

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:

linkto filteredparams

def filtered_params # Filter just the parameters that you trust end

See also: - http://blog.honeybadger.io/understanding-the-rails-jquery-csrf-vulnerability-cve-2015-1840/

Vulnerable Gem: json@1.8.6

Name:

json

Version:

1.8.6

ID:

CVE-2020-10663

Link

json Gem for Ruby Unsafe Object Creation Vulnerability (additional fix)

Description:

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.

Details

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.

Vulnerable Gem: kaminari@0.13.0

Name:

kaminari

Version:

0.13.0

ID:

CVE-2020-11082

Link

Cross-Site Scripting in Kaminari via `original_script_name` parameter

Description:

Impact

There was a vulnerability in versions of Kaminari that would allow an attacker to inject arbitrary code into pages with pagination links.

For example, an attacker could craft pagination links that link to other domain or host: https://example.com/posts?page=4&originalscriptname=https://another-host.example.com

In addition, an attacker could also craft pagination links that include JavaScript code that runs when a user clicks the link: https://example.com/posts?page=4&originalscriptname=javascript:alert(42)%3b//

Releases

The 1.2.1 gem including the patch has already been released. All past released versions are affected by this vulnerability.

Workarounds

Application developers who can't update the gem can workaround by overriding the PARAM_KEY_EXCEPT_LIST constant.

module Kaminari::Helpers
  PARAM_KEY_EXCEPT_LIST = [:authenticity_token, :commit, :utf8, :_method, :script_name, :original_script_name].freeze
end

This vulnerability appears in code generated by the Rexical gem versions v1.0.6 and earlier. Rexical is used by Nokogiri to generate lexical scanner code for parsing CSS queries. The underlying vulnerability was addressed in Rexical v1.0.7 and Nokogiri upgraded to this version of Rexical in Nokogiri v1.10.4.

Upgrade to Nokogiri v1.10.4, or avoid calling the undocumented method Nokogiri::CSS::Tokenizer#load_file with untrusted user input.

Vulnerable Gem: nokogiri@1.5.5

Name:

nokogiri

Version:

1.5.5

ID:

CVE-2020-26247

Link

Nokogiri::XML::Schema trusts input by default, exposing risk of an XXE vulnerability

Description:

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 accessed over the network
# but in v1.11.0.rc4 and later, this call will disallow network access for 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)

Vulnerable Gem: nokogiri@1.5.5

Name:

nokogiri

Version:

1.5.5

ID:

GHSA-cgx6-hpwq-fhv5

Link

Integer Overflow or Wraparound in libxml2 affects Nokogiri

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

Vulnerable Gem: nokogiri@1.5.5

Name:

nokogiri

Version:

1.5.5

ID:

GHSA-gx8x-g87m-h5q6

Link

Denial of Service (DoS) in Nokogiri on JRuby

Description:

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

Vulnerable Gem: nokogiri@1.5.5

Name:

nokogiri

Version:

1.5.5

ID:

CVE-2021-41098

Link

Improper Restriction of XML External Entity Reference (XXE) in Nokogiri on JRuby

Description:

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

Mitigation

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.

Vulnerable Gem: nokogiri@1.5.5

Name:

nokogiri

Version:

1.5.5

ID:

GHSA-7rrm-v45f-jp64

Link

Update packaged dependency libxml2 from 2.9.10 to 2.9.12

Description:

Summary

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

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.