Rack::Session::Cookie in Rack 1.5.x before 1.5.2, 1.4.x before 1.4.5, 1.3.x before 1.3.10, 1.2.x before 1.2.8, and 1.1.x before 1.1.6 allows remote attackers to guess the session cookie, gain privileges, and execute arbitrary code via a timing attack involving am HMAC comparison function that does not run in constant time. The ruby-rack package has been updated to latest 1.1.6 version to fix above security problem.
CC: (none) => luigiwalserBlocks: (none) => 6487
There's a lot more fixed by this. CVE-2011-5036: http://lwn.net/Vulnerabilities/475787/ CVE-2012-6109 CVE-2013-0183 CVE-2013-0184: http://lwn.net/Vulnerabilities/534632/
Advisory: ======================== Updated ruby-rack packages fix security vulnerabilities: Rack before 1.1.3, 1.2.x before 1.2.5, and 1.3.x before 1.3.6 computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters (CVE-2011-5036). Upstream released Rack 1.4.2, 1.3.7, 1.2.6, and 1.1.4 to fix a denial of service condition when Rack parses content with a certain Content-Disposition header as noted in the original report (CVE-2012-6109). Upstream released [1] Rack 1.4.3 and 1.3.8 to fix a denial of service condition due to a malicious client sending excessively long lines that trigger an out-of-memory error in Rack (CVE-2013-0183). A flaw that was fixed in 1.4.4, 1.3.9, 1.2.7, and 1.1.5 was also announced that creates a minor denial of service condition, this time in the Rack::Auth::AbstractRequest, where it symbolized arbitrary strings (apparently this has something to do with authentication, but there is no further information provided other than the fix itself, which is noted as "a breaking API change") (CVE-2013-0184). Rack::Session::Cookie in Rack 1.5.x before 1.5.2, 1.4.x before 1.4.5, 1.3.x before 1.3.10, 1.2.x before 1.2.8, and 1.1.x before 1.1.6 allows remote attackers to guess the session cookie, gain privileges, and execute arbitrary code via a timing attack involving am HMAC comparison function that does not run in constant time (CVE-2013-0263). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5036 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6109 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0183 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0184 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0263 http://lists.fedoraproject.org/pipermail/package-announce/2012-January/072051.html http://lists.fedoraproject.org/pipermail/package-announce/2013-January/097501.html ======================== Updated packages in core/updates_testing: ======================== ruby-rack-1.1.6-1.mga2 ruby-rack-doc-1.1.6-1.mga2 from ruby-rack-1.1.6-1.mga2.src.rpm
Severity: normal => major
Funda, please see this regarding other ruby packages in need of updates: https://bugs.mageia.org/show_bug.cgi?id=6487#c21
Is this one too ? CVE-2013-0262, symlink path traversal in Rack::File http://rack.github.com/
Can be tested with redmine or chiliproject $ urpmq --whatrequires ruby-rack
(In reply to comment #4) > Is this one too ? > > CVE-2013-0262, symlink path traversal in Rack::File > > http://rack.github.com/ No, doesn't affect 1.1.x, but that one was just fixed in Cauldron.
Simpler testing: http://rubylearning.com/blog/a-quick-introduction-to-rack/ Don't use 'gem install' as we need to test our own packages rather than downloading the gems directly.
Whiteboard: (none) => has_procedure
Adding feedback tag until chiliproject, redmine & teambox are updated
Whiteboard: has_procedure => has_procedure feedback
LWN reference for CVE-2013-0262 and CVE-2013-0263: http://lwn.net/Vulnerabilities/539877/ OpenSuSE has issued an update for this today (February 25): http://lists.opensuse.org/opensuse-updates/2013-02/msg00071.html
urpmf --requires `urpmq --whatrequires ruby-rack` | grep rack\\[== Shows no versioned requires other than ruby-rack-doc for this so we should test and push this without waiting for ruby-rails.
Whiteboard: has_procedure feedback => has_procedure
Assigning back to you Funda, sorry. Please reassign to QA when you've had a chance to take a look at this. Thanks. Same problems as other ruby packages. $ irb irb(main):001:0> require "rack" LoadError: no such file to load -- rack from (irb):1:in `require' from (irb):1 from :0 $ gem list *** LOCAL GEMS *** json (1.5.1) json_pure (1.5.1) msgpack (0.4.6) rack (1.1.6) Running under strace i586, not sure why it's doing stat64.. stat64("/usr/lib/ruby/site_ruby/1.8/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/1.8/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/1.8/i586-linux/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/1.8/i586-linux/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/1.8/i586-linux-gnu/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/1.8/i586-linux-gnu/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/site_ruby/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/1.8/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/1.8/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/1.8/i586-linux/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/1.8/i586-linux/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/vendor_ruby/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/i586-linux/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/i586-linux/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/i586-linux-gnu/rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ruby/1.8/i586-linux-gnu/rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("./rack.rb", 0xbfaf5740) = -1 ENOENT (No such file or directory) stat64("./rack.so", 0xbfaf5740) = -1 ENOENT (No such file or directory) As with other ruby packages it seems to be searching wrong paths. $ urpmf ruby-rack: ruby-rack:/usr/bin/rackup ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2 ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/bin ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/bin/rackup ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib/rack ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib/rack.rb ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib/rack/adapter ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib/rack/adapter/camping.rb ruby-rack:/usr/lib/ruby/gems/1.8/gems/rack-1.1.2/lib/rack/auth etc.
CC: (none) => qa-bugsAssignee: qa-bugs => fundawang
Closing this now due to Mageia 2 EOL. http://blog.mageia.org/en/2013/11/21/farewell-mageia-2/
Status: NEW => RESOLVEDResolution: (none) => OLDQA Contact: (none) => security