"What seems to happen is that when parsing a header like this
Content-Disposition: inline; name=xml_product_config;
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.
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:
(In reply to comment #3)
> Fixed versions for all reported DoS issues are now in the tree:
Thanks. Arches, please test and mark stable.
GLSA vote: yes.
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."
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.
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).