🚨 [security] Upgrade all of rails: 5.1.7 → 5.2.4.4 (minor)

[depfu]

---

🚨 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 upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ nokogiri (1.10.2 → 1.10.10) · Repo · Changelog

Security Advisories 🚨

🚨 xmlStringLenDecodeEntities in parser.c in libxml2 2.9.10 has an infinite loop in a certain end-of-file situation.

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.

🚨 Nokogiri gem, via libxslt, is affected by multiple vulnerabilities

Nokogiri v1.10.5 has been released.

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.

---

CVE-2019-13117

https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-13117.html

Priority: Low

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.

Patched with commit https://gitlab.gnome.org/GNOME/libxslt/commit/c5eb6cf3aba0af048596106ed839b4ae17ecbcb1

---

CVE-2019-13118

https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-13118.html

Priority: Low

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

Patched with commit https://gitlab.gnome.org/GNOME/libxslt/commit/6ce8de69330783977dd14f6569419489875fb71b

---

CVE-2019-18197

https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-18197.html

Priority: Medium

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.

Patched with commit https://gitlab.gnome.org/GNOME/libxslt/commit/2232473733b7313d67de8836ea3b29eec6e8e285

🚨 Nokogiri Command Injection Vulnerability

🚨 Nokogiri gem, via libxslt, is affected by improper access control vulnerability

Nokogiri v1.10.3 has been released.

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.

---

CVE-2019-11068

Permalinks are:

• Canonical: https://people.canonical.com/~ubuntu-security/cve/CVE-2019-11068
• Debian: https://security-tracker.debian.org/tracker/CVE-2019-11068

Description:

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)".

Release Notes

1.10.10

More info than we can show here.

1.10.9

More info than we can show here.

1.10.8

More info than we can show here.

1.10.7

More info than we can show here.

1.10.6

More info than we can show here.

1.10.5

More info than we can show here.

1.10.4

More info than we can show here.

1.10.3

More info than we can show here.

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.

✳️ rails (5.1.7 → 5.2.4.4) · Repo

Security Advisories 🚨

🚨 ActiveJob/ActiveStorage vulnerabilities

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.

---

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

Release Notes

5.2.4.1

More info than we can show here.

5.2.4

More info than we can show here.

5.2.3

More info than we can show here.

5.2.2

More info than we can show here.

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.

↗️ actioncable (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ actionmailer (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ actionpack (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Security Advisories 🚨

🚨 Possible Strong Parameters Bypass in ActionPack

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.

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

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.

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ actionview (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Security Advisories 🚨

🚨 Potential XSS vulnerability in Action View

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 locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>
<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>

<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_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)) %>

🚨 CSRF Vulnerability in rails-ujs

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

🚨 Possible XSS vulnerability in ActionView

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:

<script>let a = `<%= j unknown_input %>`</script>

or

<script>let a = `<%= escape_javascript unknown_input %>`</script>

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

🚨 File Content Disclosure in Action View

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", formats: [:html]

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

🚨 Denial of Service Vulnerability in Action View

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 can be changed this 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

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ activejob (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Security Advisories 🚨

🚨 Broken Access Control vulnerability in Active Job

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.

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ activemodel (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ activerecord (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ activesupport (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Security Advisories 🚨

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

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.

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ arel (indirect, 8.0.0 → 9.0.0) · Repo · Changelog

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ builder (indirect, 3.2.3 → 3.2.4) · Repo · Changelog

↗️ concurrent-ruby (indirect, 1.1.5 → 1.1.7) · Repo · Changelog

Release Notes

1.1.7 (from changelog)

More info than we can show here.

1.1.6 (from changelog)

More info than we can show here.

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.

↗️ crass (indirect, 1.0.4 → 1.0.6) · Repo · Changelog

Release Notes

1.0.6

More info than we can show here.

1.0.5

More info than we can show here.

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.

↗️ erubi (indirect, 1.8.0 → 1.9.0) · Repo · Changelog

Release Notes

1.9.0 (from changelog)

More info than we can show here.

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.

↗️ i18n (indirect, 1.6.0 → 1.8.5) · Repo · Changelog

Release Notes

1.8.4

More info than we can show here.

1.8.3

More info than we can show here.

1.8.2

More info than we can show here.

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.

↗️ loofah (indirect, 2.2.3 → 2.7.0) · Repo · Changelog

Security Advisories 🚨

🚨 Loofah XSS Vulnerability

In the Loofah gem, through v2.3.0, unsanitized JavaScript may occur in
sanitized output when a crafted SVG element is republished.

Release Notes

2.7.0

More info than we can show here.

2.6.0 (from changelog)

More info than we can show here.

2.5.0 (from changelog)

More info than we can show here.

2.4.0

More info than we can show here.

2.3.1

More info than we can show here.

2.3.0 (from changelog)

More info than we can show here.

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.

↗️ method_source (indirect, 0.9.2 → 1.0.0) · Repo

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ mini_mime (indirect, 1.0.1 → 1.0.2) · Repo · Changelog

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

↗️ minitest (indirect, 5.11.3 → 5.14.2) · Repo · Changelog

Release Notes

5.14.2 (from changelog)

More info than we can show here.

5.14.0 (from changelog)

More info than we can show here.

5.13.0 (from changelog)

More info than we can show here.

5.12.2 (from changelog)

More info than we can show here.

5.12.1 (from changelog)

More info than we can show here.

5.12.0 (from changelog)

More info than we can show here.

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.

↗️ nio4r (indirect, 2.3.1 → 2.5.3) · Repo · Changelog

Release Notes

2.5.3 (from changelog)

More info than we can show here.

2.5.2 (from changelog)

More info than we can show here.

2.4.0 (from changelog)

More info than we can show here.

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.6 → 2.2.3) · Repo · Changelog

Security Advisories 🚨

🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names

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

🚨 Percent-encoded cookies can be used to overwrite existing prefixed cookie names

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

🚨 Directory traversal in Rack::Directory app bundled with Rack

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.

🚨 Directory traversal in Rack::Directory app bundled with Rack

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.

🚨 Possible information leak / session hijack vulnerability

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.

Release Notes

2.2.2 (from changelog)

More info than we can show here.

2.2.1 (from changelog)

More info than we can show here.

2.2.0 (from changelog)

More info than we can show here.

2.1.2 (from changelog)

More info than we can show here.

2.1.1 (from changelog)

More info than we can show here.

2.1.0 (from changelog)

More info than we can show here.

2.0.8 (from changelog)

More info than we can show here.

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.

↗️ rails-html-sanitizer (indirect, 1.0.4 → 1.3.0) · Repo · Changelog

Release Notes

1.3.0

More info than we can show here.

1.2.0

More info than we can show here.

1.1.0

More info than we can show here.

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.

↗️ railties (indirect, 5.1.7 → 5.2.4.4) · Repo · Changelog

Security Advisories 🚨

🚨 Possible Remote Code Execution Exploit in Rails Development Mode

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: None.
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.

Releases

The 6.0.0.beta3 and 5.2.2.1 releases are available at the normal locations.

Workarounds

This issue can be mitigated by specifying a secret key in development mode.
In "config/environments/development.rb" add this:

config.secret_key_base = SecureRandom.hex(64)

Credits

Thanks to ooooooo_q

Release Notes

5.2.4.3 (from changelog)

More info than we can show here.

5.2.4.1 (from changelog)

More info than we can show here.

5.2.4 (from changelog)

More info than we can show here.

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.

↗️ rake (indirect, 12.3.2 → 12.3.3) · Repo · Changelog

Security Advisories 🚨

🚨 OS Command Injection in Rake

There is an OS command injection vulnerability in Ruby Rake < 12.3.3 in
Rake::FileList when supplying a filename that begins with the pipe character
|.

Release Notes

12.3.3 (from changelog)

More info than we can show here.

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.

↗️ tzinfo (indirect, 1.2.5 → 1.2.7) · Repo · Changelog

Release Notes

1.2.7

More info than we can show here.

1.2.6

More info than we can show here.

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.

↗️ websocket-driver (indirect, 0.6.5 → 0.7.3) · Repo · Changelog

Release Notes

0.7.3 (from changelog)

More info than we can show here.

0.7.2 (from changelog)

More info than we can show here.

0.7.1 (from changelog)

More info than we can show here.

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.

↗️ websocket-extensions (indirect, 0.1.3 → 0.1.5) · Repo · Changelog

Security Advisories 🚨

🚨 Regular Expression Denial of Service in websocket-extensions (RubyGem)

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.

Release Notes

0.1.5 (from changelog)

More info than we can show here.

0.1.4 (from changelog)

More info than we can show here.

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.

🆕 activestorage (added, 5.2.4.4)

🆕 marcel (added, 0.3.3)

🆕 mimemagic (added, 0.3.5)

---

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]

Closed in favor of #275.