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. Reference: https://groups.google.com/forum/#!msg/rubyonrails-security/OWtmozPH9Ak/4m00yHPCBAAJ
Created rubygem-rack tracking bugs for this issue: Affects: epel-all [bug 1849143] Affects: fedora-all [bug 1849142]
External References: https://groups.google.com/forum/#!msg/rubyonrails-security/OWtmozPH9Ak/4m00yHPCBAAJ
* HackerOne report: https://hackerone.com/reports/895727 * Cookie RFC: https://www.ietf.org/rfc/rfc2965.txt * Initial idea of Magic-cookies aka cookie prefixes: https://textslashplain.com/2015/10/09/duct-tape-and-baling-wirecookie-prefixes/ * Idea to proposal; allowed prefix pattern: https://tools.ietf.org/html/draft-west-cookie-prefixes-05#section-3 Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/ The flaw in Rack allows __%48ost- or __%53ecure- or custom cookie to be set without HTTPS/root domain/secure page flag. With this escape, an attacker could set this cookie from a subdomain and have it apply to the root domain.
Upstream fix: https://github.com/rack/rack/commit/1f5763de6a9fe515ff84992b343d63c88104654c
Statement: Because Red Hat OpenStack Platform 13.0 Operational Tools packages ships the flawed code, but does not use its functionality, its Impact has been reduced to 'Low'. Red Hat Satellite 6 and Red Hat CloudForms ship affected RubyGem Rack, however, since overwriting cookies is not possible products are not vulnerable to the flaw. We may update the Rack dependency in a future releases. Red Hat Gluster Storage 3 ships RubyGem Rack, but the version shipped does not contain the affected code. Therefore, it is impossible to overwrite cookies using this particular flaw.
This issue has been addressed in the following products: Red Hat Satellite 6.7 for RHEL 8 Via RHSA-2020:4366 https://access.redhat.com/errata/RHSA-2020:4366
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-8184