Skip to content

🚨 [security] [ruby] Upgrade omniauth: 1.8.1 → 1.9.2 (minor) #337

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

🚨 [security] [ruby] Upgrade omniauth: 1.8.1 → 1.9.2 (minor) #337

wants to merge 1 commit into from

Conversation

@depfu
Copy link
Contributor

@depfu depfu bot commented Sep 6, 2022 •
edited
Loading

🚨 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?

✳️ omniauth (1.8.1 → 1.9.2) · Repo

Security Advisories 🚨

🚨 OmniAuth's `lib/omniauth/failure_endpoint.rb` does not escape `message_key` value

lib/omniauth/failure_endpoint.rb in OmniAuth before 1.9.2 (and before
2.0) does not escape the message_key value.

Release Notes

1.9.2

Backports a vulnerability fix that was included in Omniauth 2.0 release to the 1.9 channel.

https://nvd.nist.gov/vuln/detail/CVE-2020-36599

Current Omniauth security policy maintains v2.0 and v2.1 channels for security releases, and security patches should not be typically expected for the v1.9 channel.

1.9.1

This release includes minor changes that remove code specific to rack versions we no longer support, it also loosens the top-end of the version of hashie we require.

No breaking changes are expected with this change. If a breaking change has been introduced with this release, please open an issue.

You can view a list of commits and changed files here: v1.9.0...v1.9.1

1.9.0

  • Update rack to >=2.0.6 per CVE-2018-16471
  • Allows usage of Hashie up to 3.7.0
  • Fixes Rubocop offenses.

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by 36 commits:

↗️ hashie (indirect, 3.5.7 → 5.0.0) · Repo · Changelog

Release Notes

5.0.0 (from changelog)

Added

Changed

  • #521: Do not convert keys that cannot be represented as symbols to String in Mash initialization - @carolineartz.
  • #524: Test with Ruby 2.7 - @aried3r.
  • #525: Use indifferent_writer in IndifferentAccess#convert! - @yogeshjain999.
  • #527: Updated Copyright to (c) 2009-2020 Intridea, Inc., and Contributors - @dblock.
  • #555: Test with Ruby 3.0 - @dblock.

Removed

Fixed

  • #516: Fixed NoMethodError raised when including Hashie::Extensions::Mash::SymbolizeKeys and Hashie::Extensions::SymbolizeKeys in mashes/hashes with non string or symbol keys - @carolineartz.
  • #531: Fixed slice doesn't work using symbols using hash with IndifferentAccess extension - @gnomex.
  • #533: Fixed NoMethodError: undefined method 'to_json' at hashie/dash_spec - @gnomex.
  • #535: Restored the exporting of all properties as part of Dash#to_h and Dash#to_hash - @michaelherold.
  • #537: Fixed inconsistencies with handling defaults in Dash with and without IgnoreUnclared mixed in - @michaelherold.
  • #547: Fixed issue where a source hash key can be used in translating multiple properties - @danwa5.

4.1.0

Added

  • #499: Add Hashie::Extensions::Mash::PermissiveRespondTo to make specific subclasses of Mash fully respond to messages for use with SimpleDelegator - @michaelherold.

Fixed

  • #467: Fixed DeepMerge#deep_merge mutating nested values within the receiver - @michaelherold.
  • #505: Ensure that Hashie::Arrays are not deconverted within Hashie::Mashes to make Mash#dig work properly - @michaelherold.
  • #507: Suppress Psych.safe_load arg warn when using Psych 3.1.0+ - @koic.
  • #508: Fixed Mash.load no longer uses Rails-only #except - @bobbymcwho.
  • #508: Fixed Hashie::Extensions::DeepMerge #deep_merge not correctly dup'ing sub-hashes if active_support hash extensions were not present - @bobbymcwho.
  • #500: Do not warn when setting Mash keys that look like underbang, bang, and query methods - @michaelherold.
  • #510: Ensure that Hashie::Mash#compact is only defined on Ruby version >= 2.4.0 - @bobbymcwho.
  • #511: Suppress keyword arguments warning for Ruby 2.7.0 - @koic.
  • #512: Suppress an integer unification warning for using Ruby 2.4.0+ - @koic.
  • #513: Suppress a Ruby's warning when using Ruby 2.6.0+ - @koic.

Miscellaneous

  • #981: Exclude tests from the gem release to reduce installation size and improve installation speed - @michaelherold.

4.0.0

Full Changelog

New in 4.0.0:

4.0.0 - 2019-10-30

Added

  • #323: Added Hashie::Extensions::Mash::DefineAccessors - @marshall-lee.
  • #474: Expose YAML#safe_load options in Mash#load - @riouruma, @dblock.
  • #478: Added optional array parameter to Hashie::Mash.disable_warnings - @bobbymcwho.
  • #481: Ruby 2.6 - Support Hash#merge and #merge! called with multiple Hashes/Mashes - @bobbymcwho.
  • #488: Added ability to create an anonymous Hashie::Mash subclass with key conflict errors silenced using Hashie::Mash.quiet.new - @bobbymcwho.

Changed

Fixed

  • #459: Fixed a regression in Mash.load that disallowed aliases - @arekt and @michaelherold.
  • #465: Fixed deep_update to call any readers when a key exists - @laertispappas.
  • #479: Fixed an issue with Hash#except not returning a Mash in Rails 6 - @bobbymcwho.
  • #489: Updated the documentation to exlain the behavior of Mash and keyword arguments - @Bhacaz.

Miscellaneous

  • #465: Clean up our RuboCop configuration and fix the outstanding line length violations. This involved some minor refactoring on Hashie::Extensions::Coercion, Hashie::Extensions::Dash::IndifferentAccess, Hashie::Extensions::DeepLocate, Hashie::Extensions::Mash::SafeAssignment, and Hashie::Hash, but none that were detectable via the test suite - @michaelherold.
  • #482: Update Travis configs to make jruby builds run on trusty dist. - @BobbyMcWho.

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.2.2 → 2.2.6.4) · Repo · Changelog

Security Advisories 🚨

🚨 Possible Denial of Service Vulnerability in Rack’s header parsing

There is a denial of service vulnerability in the header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27539.

Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.2.6.4, 3.0.6.1

Impact

Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted.

Workarounds

Setting Regexp.timeout in Ruby 3.2 is a possible workaround.

🚨 Possible DoS Vulnerability in Multipart MIME parsing

There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.

Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3

Impact

The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.

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

Workarounds

A proxy can be configured to limit the POST body size which will mitigate this issue.

🚨 Denial of service via multipart parsing in Rack

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

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that parse multipart posts using
Rack (virtually all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Content-Disposition parsing

There is a denial of service vulnerability in the Content-Disposition parsing
component of Rack. This vulnerability has been assigned the CVE identifier
CVE-2022-44571.

Versions Affected: >= 2.0.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1

Impact

Carefully crafted input can cause Content-Disposition header parsing in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. This header is used typically used in multipart
parsing. Any applications that parse multipart posts using Rack (virtually
all Rails applications) are impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of service via header parsing in Rack

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

Versions Affected: >= 1.5.0
Not affected: None.
Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1

Impact

Carefully crafted input can cause the Range header parsing component in Rack
to take an unexpected amount of time, possibly resulting in a denial of
service attack vector. Any applications that deal with Range requests (such
as streaming applications, or applications that serve files) may be impacted.

Workarounds

There are no feasible workarounds for this issue.

🚨 Denial of Service Vulnerability in Rack Multipart Parsing

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.

🚨 Possible shell escape sequence injection vulnerability in Rack

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

🚨 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
Commits

See the full diff on Github. The new version differs by 36 commits:

Depfu Status

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 depfu bot added the depfu label Sep 6, 2022
@depfu depfu bot force-pushed the depfu/update/omniauth-1.9.2 branch from cb06034 to 5152dca Compare April 14, 2023 19:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

depfu

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant