🚨 Your current dependencies have known security vulnerabilities 🚨
This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!
Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.
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.
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.
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.
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.
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).
Description: The fork of org.cyberneko.html used by Nokogiri (Rubygem) raises a java.lang.OutOfMemoryError exception when parsing ill-formed HTML markup.
Nokogiri < v1.13.4 contains an inefficient regular expression that is
susceptible to excessive backtracking when attempting to detect encoding
in HTML documents.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 resourcesschema=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 networkschema=Nokogiri::XML::Schema.new(trusted_schema,Nokogiri::XML::ParseOptions.new.nononet)
Pulled in upstream patch from libxml that addresses CVE-2020-7595. Full details are available in #1992. Note that this patch is not yet (as of 2020-02-10) in an upstream release of libxml.
This is a security release. It addresses three CVEs in upstream libxml2,
for which details are below.
If you're using your distro's system libraries, rather than Nokogiri's
vendored libraries, there's no security need to upgrade at this time,
though you may want to check with your distro whether they've patched this
(Canonical has patched Ubuntu packages). Note that libxslt 1.1.34 addresses
these vulnerabilities.
Full details about the security update are available in Github Issue
[#1943] #1943.
Description: In numbers.c in libxslt 1.1.33, an xsl:number with certain format strings
could lead to a uninitialized read in xsltNumberFormatInsertNumbers. This
could allow an attacker to discern whether a byte on the stack contains the
characters A, a, I, i, or 0, or any other character.
Description: In numbers.c in libxslt 1.1.33, a type holding grouping characters of an
xsl:number instruction was too narrow and an invalid character/length
combination could be passed to xsltNumberFormatDecimal, leading to a read
of uninitialized stack data
Description: In xsltCopyText in transform.c in libxslt 1.1.33, a pointer variable isn't
reset under certain circumstances. If the relevant memory area happened to
be freed and reused in a certain way, a bounds check could fail and memory
outside a buffer could be written to, or uninitialized data could be
disclosed.
This is a security release. It addresses a CVE in upstream libxslt rated as
"Priority: medium" by Canonical, and "NVD Severity: high" by Debian. More
details are available below.
If you're using your distro's system libraries, rather than Nokogiri's
vendored libraries, there's no security need to upgrade at this time, though
you may want to check with your distro whether they've patched this
(Canonical has patched Ubuntu packages). Note that this patch is not yet (as
of 2019-04-22) in an upstream release of libxslt.
Full details about the security update are available in Github Issue
[#1892] #1892.
libxslt through 1.1.33 allows bypass of a protection mechanism
because callers of xsltCheckRead and xsltCheckWrite permit access
even upon receiving a -1 error code. xsltCheckRead can return -1 for
a crafted URL that is not actually invalid and is subsequently
loaded.
Canonical rates this as "Priority: Medium".
Debian rates this as "NVD Severity: High (attack range: remote)".
This is a security and bugfix release. It addresses two CVEs in upstream
libxml2 rated as "medium" by Red Hat, for which details are below.
If you're using your distro's system libraries, rather than Nokogiri's
vendored libraries, there's no security need to upgrade at this time,
though you may want to check with your distro whether they've patched this
(Canonical has patched Ubuntu packages). Note that these patches are not
yet (as of 2018-10-04) in an upstream release of libxml2.
Full details about the security update are available in Github Issue #1785.
[#1785]: #1785
[MRI] Pulled in upstream patches from libxml2 that address CVE-2018-14404
and CVE-2018-14567. Full details are available in #1785. Note that these
patches are not yet (as of 2018-10-04) in an upstream release of libxml2.
A NULL pointer dereference vulnerability exists in the
xpath.c:xmlXPathCompOpEval() function of libxml2 through 2.9.8 when
parsing an invalid XPath expression in the XPATH_OP_AND or XPATH_OP_OR
case. Applications processing untrusted XSL format inputs with the use of
the libxml2 library may be vulnerable to a denial of service attack due
to a crash of the application
Canonical rates this vulnerability as "Priority: Medium"
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 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
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 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
There was a possible directory traversal vulnerability in the Rack::Directory app
that is bundled with Rack.
Versions Affected: rack < 2.2.0
Not affected: Applications that do not use Rack::Directory.
Fixed Versions: 2.1.3, >= 2.2.0
Impact
If certain directories exist in a director that is managed by Rack::Directory, an attacker could, using this vulnerability, read the
contents of files on the server that were outside of the root specified in the
Rack::Directory initializer.
Workarounds
Until such time as the patch is applied or their Rack version is upgraded,
we recommend that developers do not use Rack::Directory in their
applications.
There was a possible directory traversal vulnerability in the Rack::Directory app
that is bundled with Rack.
Versions Affected: rack < 2.2.0
Not affected: Applications that do not use Rack::Directory.
Fixed Versions: 2.1.3, >= 2.2.0
Impact
If certain directories exist in a director that is managed by Rack::Directory, an attacker could, using this vulnerability, read the
contents of files on the server that were outside of the root specified in the
Rack::Directory initializer.
Workarounds
Until such time as the patch is applied or their Rack version is upgraded,
we recommend that developers do not use Rack::Directory in their
applications.
There's a possible information leak / session hijack vulnerability in Rack.
Attackers may be able to find and hijack sessions by using timing attacks
targeting the session id. Session ids are usually stored and indexed in a
database that uses some kind of scheme for speeding up lookups of that
session id. By carefully measuring the amount of time it takes to look up
a session, an attacker may be able to find a valid session id and hijack
the session.
The session id itself may be generated randomly, but the way the session is
indexed by the backing store does not use a secure comparison.
Impact:
The session id stored in a cookie is the same id that is used when querying
the backing session storage engine. Most storage mechanisms (for example a
database) use some sort of indexing in order to speed up the lookup of that
id. By carefully timing requests and session lookup failures, an attacker
may be able to perform a timing attack to determine an existing session id
and hijack that session.
There is a possible DoS vulnerability in the multipart parser in Rack.
Carefully crafted requests can cause the multipart parser to enter a
pathological state, causing the parser to use CPU resources disproportionate to
the request size.
Impacted code can look something like this:
Rack::Request.new(env).params
But any code that uses the multi-part parser may be vulnerable.
Rack users that have manually adjusted the buffer size in the multipart parser
may be vulnerable as well.
All users running an affected release should either upgrade or use one of the
workarounds immediately.
Releases
The 2.0.6 release is available at the normal locations.
Workarounds
To work around this issue, the following code can be used:
There is a possible vulnerability in Rack. This vulnerability has been
assigned the CVE identifier CVE-2018-16471.
Versions Affected: All.
Not affected: None.
Fixed Versions: 2.0.6, 1.6.11
Impact
There is a possible XSS vulnerability in Rack. Carefully crafted requests can
impact the data returned by the scheme method on Rack::Request.
Applications that expect the scheme to be limited to "http" or "https" and do
not escape the return value could be vulnerable to an XSS attack.
Vulnerable code looks something like this:
<%= request.scheme.html_safe %>
Note that applications using the normal escaping mechanisms provided by Rails
may not impacted, but applications that bypass the escaping mechanisms, or do
not use them may be vulnerable.
All users running an affected release should either upgrade or use one of the
workarounds immediately.
Releases
The 2.0.6 and 1.6.11 releases are available at the normal locations.
Workarounds
The following monkey patch can be applied to work around this issue:
require "rack"
require "rack/request"
class Rack::Request
SCHEME_WHITELIST = %w(https http).freeze
def scheme
if get_header(Rack::HTTPS) == 'on'
'https'
elsif get_header(HTTP_X_FORWARDED_SSL) == 'on'
'https'
elsif forwarded_scheme
forwarded_scheme
else
get_header(Rack::RACK_URL_SCHEME)
end
end
def forwarded_scheme
scheme_headers = [
get_header(HTTP_X_FORWARDED_SCHEME),
get_header(HTTP_X_FORWARDED_PROTO).to_s.split(',')[0]
]
scheme_headers.each do |header|
return header if SCHEME_WHITELIST.include?(header)
end
nil
end
end
Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.
All Depfu comment commands
@depfu rebase
Rebases against your default branch and redoes this update
@depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@depfu close
Closes this PR and deletes the branch
@depfu reopen
Restores the branch and reopens this PR (if it's closed)
@depfu pause
Ignores all future updates for this dependency and closes this PR
@depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)
depfu[bot]
commented
1 year ago
🚨 Your current dependencies have known security vulnerabilities 🚨
This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!
Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.
What changed?
✳️ capybara (3.7.1 → 3.37.1) · Repo · Changelog
Release Notes
Too many releases to show here. View the full release notes.
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ addressable (indirect, 2.5.2 → 2.8.0) · Repo · Changelog
Security Advisories 🚨
🚨 Regular Expression Denial of Service in Addressable templates
Release Notes
2.8.0 (from changelog)
2.7.0 (from changelog)
2.6.0 (from changelog)
Does any of this look wrong? Please let us know.
↗️ mini_mime (indirect, 1.0.1 → 1.1.2) · Repo · Changelog
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ mini_portile2 (indirect, 2.3.0 → 2.8.0) · Repo · Changelog
Release Notes
2.8.0
2.7.1
2.7.0
2.6.1
2.6.0
2.5.3
2.5.2
2.5.1
2.5.0
Does any of this look wrong? Please let us know.
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ nokogiri (indirect, 1.8.4 → 1.13.6) · Repo · Changelog
Security Advisories 🚨
🚨 XML Injection in Xerces Java affects Nokogiri
🚨 Out-of-bounds Write in zlib affects Nokogiri
🚨 Denial of Service (DoS) in Nokogiri on JRuby
🚨 Inefficient Regular Expression Complexity in Nokogiri
🚨 Update packaged libxml2 (2.9.12 → 2.9.13) and libxslt (1.1.34 → 1.1.35)
🚨 Improper Restriction of XML External Entity Reference (XXE) in Nokogiri on JRuby
🚨 Update packaged dependency libxml2 from 2.9.10 to 2.9.12
🚨 Nokogiri::XML::Schema trusts input by default, exposing risk of an XXE vulnerability
🚨 xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.
🚨 Nokogiri gem, via libxslt, is affected by multiple vulnerabilities
🚨 Nokogiri Command Injection Vulnerability
🚨 Nokogiri gem, via libxslt, is affected by improper access control vulnerability
🚨 Nokogiri gem, via libxml2, is affected by multiple vulnerabilities
Release Notes
Too many releases to show here. View the full release notes.
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ public_suffix (indirect, 3.0.3 → 4.0.7) · Repo · Changelog
Release Notes
4.0.7 (from changelog)
4.0.6 (from changelog)
4.0.5 (from changelog)
4.0.4 (from changelog)
4.0.3 (from changelog)
4.0.2 (from changelog)
4.0.1 (from changelog)
4.0.0 (from changelog)
3.1.1 (from changelog)
3.1.0 (from changelog)
Does any of this look wrong? Please let us know.
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ rack (indirect, 2.0.5 → 2.2.3) · Repo · Changelog
Security Advisories 🚨
🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names
🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names
🚨 Directory traversal in Rack::Directory app bundled with Rack
🚨 Directory traversal in Rack::Directory app bundled with Rack
🚨 Possible information leak / session hijack vulnerability
🚨 Possible DoS vulnerability in Rack
🚨 Possible XSS vulnerability in Rack
Release Notes
2.2.2 (from changelog)
2.2.1 (from changelog)
2.2.0 (from changelog)
2.1.2 (from changelog)
2.1.1 (from changelog)
2.1.0 (from changelog)
2.0.8 (from changelog)
Does any of this look wrong? Please let us know.
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
↗️ xpath (indirect, 3.1.0 → 3.2.0) · Repo · Changelog
Commits
See the full diff on Github. The new version differs by more commits than we can show here.
🆕 matrix (added, 0.4.2)
🆕 racc (added, 1.6.0)
🆕 regexp_parser (added, 2.4.0)
Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with
@depfu rebase.All Depfu comment commands