"What seems to happen is that when parsing a header like this Content-Disposition: inline; name=xml_product_config; filename=XML_PRODUCT_CONFIG.xml the regexp in the get_filename method in parser.rb seems to get stuck in an infinite loop on the line with if head =~ RFC2183 "
The following versions of rack are now in the tree. =dev-ruby/rack-1.1.4 =dev-ruby/rack-1.2.6 =dev-ruby/rack-1.4.3 rack 1.3.7 is still pending because it fails its tests: https://github.com/rack/rack/issues/493
*** Bug 452198 has been marked as a duplicate of this bug. ***
Fixed versions for all reported DoS issues are now in the tree: =dev-ruby/rack-1.1.5 =dev-ruby/rack-1.2.7 =dev-ruby/rack-1.3.9 =dev-ruby/rack-1.4.4
(In reply to comment #3) > Fixed versions for all reported DoS issues are now in the tree: > > =dev-ruby/rack-1.1.5 > =dev-ruby/rack-1.2.7 > =dev-ruby/rack-1.3.9 > =dev-ruby/rack-1.4.4 Thanks. Arches, please test and mark stable.
amd64 stable
x86 stable
ppc64 stable
ppc stable
GLSA vote: yes.
CVE-2013-0184 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0184): Unspecified vulnerability in Rack::Auth::AbstractRequest in Rack 1.1.x before 1.1.5, 1.2.x before 1.2.7, 1.3.x before 1.3.9, and 1.4.x before 1.4.4 allows remote attackers to cause a denial of service via unknown vectors related to "symbolized arbitrary strings." CVE-2013-0183 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0183): multipart/parser.rb in Rack 1.3.x before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to cause a denial of service (memory consumption and out-of-memory error) via a long string in a Multipart HTTP packet. CVE-2012-6109 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-6109): lib/rack/multipart.rb in Rack before 1.1.4, 1.2.x before 1.2.6, 1.3.x before 1.3.7, and 1.4.x before 1.4.2 uses an incorrect regular expression, which allows remote attackers to cause a denial of service (infinite loop) via a crafted Content-Disposion header.
Added to existing GLSA draft.
This issue was resolved and addressed in GLSA 201405-10 at http://security.gentoo.org/glsa/glsa-201405-10.xml by GLSA coordinator Sean Amoss (ackle).