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. Releases -------- The fixed releases are available on RubyGems. 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
dev-ruby/rack-2.1.4 and dev-ruby/rack-2.2.3 have been added.
ppc/ppc64 stable
sparc stable
arm stable
x86 stable
amd64 stable
hppa stable
Cleanup is currently on hold as we still have some packages that depend on the old slots (notable dev-ruby/bcat and dev-ruby/faraday).
(In reply to Hans de Graaff from comment #8) > Cleanup is currently on hold as we still have some packages that depend on > the old slots (notable dev-ruby/bcat and dev-ruby/faraday). Thanks. Is there a bug to block on or just wait for you to let us know?
(XSS => noglsa).
dev-ruby/bcat was treecleaned and dev-ruby/faraday doesn't appear to depend on slotted rack, are we able to cleanup here now?
(In reply to John Helmert III (ajak) from comment #11) > dev-ruby/bcat was treecleaned and dev-ruby/faraday doesn't appear to depend > on slotted rack, are we able to cleanup here now? Unfortunately not. It turns out that there are more dependencies out there. I have fixed a number of these today and as far as I can tell now the only remaining blocker is sinatra. Current status: rack 1.6: now masked for removal. rack 2.0: pending sinatra-2.0.8.1 removal which depends on bug 692324 rack 2.1: pending sinatra-2.1.0 stable (added 2020-09-19, needs some time in testing)
Resetting sanity check; keywords are not fully specified and arches are not CC-ed.
The remaining insecure rack slot have now been masked for removal: # Hans de Graaff <graaff@gentoo.org> (2020-12-29) # These slots masked for removal in 30 days due to # security issues, bug 730786 # Use a newer slot instead. dev-ruby/rack:2.0 dev-ruby/rack:2.1
Tree is clean, all done!
