A denial of service flaw was found in the JRuby's Murmur hash function implementation. A specially-crafted set of keys could trigger Murmur hash function collisions, which degrade hash table items insert performance by changing hash table operations complexity from an expected/average O(n) to the worst case O(n^2). Reporters were able to find colliding strings efficiently using equivalent substrings. As various web application frameworks for Ruby automatically pre-fill certain arrays with data from the HTTP request (such as GET or POST parameters) for Ruby web applications, a remote attacker could use this flaw to make the Ruby interpreter use an excessive amount of CPU time by sending a POST request with a large number parameters which hash to the same value. A different vulnerability than CVE-2011-4838. References: [1] http://www.openwall.com/lists/oss-security/2012/11/23/4 [2] http://www.ocert.org/advisories/ocert-2012-001.html [3] http://2012.appsec-forum.ch/conferences/#c17 [4] https://www.131002.net/data/talks/appsec12_slides.pdf [5] http://asfws12.files.wordpress.com/2012/11/asfws2012-jean_philippe_aumasson-martin_bosslet-hash_flooding_dos_reloaded.pdf
This issue affects the versions of the jruby package, as shipped with Fedora release of 16 and 17. Please schedule an update (once there is final upstream patch available).
Created jruby tracking bugs for this issue Affects: fedora-all [bug 880674]
Ruby language upstream in version ruby-1.9.3 patchlevel 327 has replaced the Murmur hash function / algorithm implementation with the SipHash-2-4 implementation: http://www.ruby-lang.org/en/news/2012/11/09/ruby19-hashdos-cve-2012-5371/ https://www.131002.net/siphash/
Fuse Enterprise ESB 7.0.2 ships JRuby 1.6.7 as part of the camel-ruby component, which allows users to define Camel routes in Ruby. JRuby 1.6.7 exposes this flaw, although the default use of JRuby in Fuse Enterprise ESB 7.0.2 does not appear to expose the flaw. If the version of JRuby shipped with Fuse Enterprise ESB 7.0.2 was used to build a custom application, then this flaw could be exposed. A bug has been filed to update JRuby as shipped with Fuse Enterprise ESB once an upstream fix is available: http://fusesource.com/issues/browse/ENTESB-454
JBoss Enterprise SOA Platform 5.3.0 ships JRuby 1.6.5.1 as part of the scripting_chain quickstart sample application. JRuby 1.6.5.1 exposes this flaw, although the sample application itself does not appear to expose the flaw. If the version of JRuby shipped with the scripting_chain sample application was used to build a custom application, then this flaw could be exposed. A bug has been filed to update JRuby as shipped with the sample application once an upstream fix is available: https://issues.jboss.org/browse/JBESB-3884
Created attachment 661196 [details] patch to the issue Here is a proposed patch to fix that issue, using SipHash instead of bogus MurmurHash, exactly as it was done in the C version of ruby.
(In reply to comment #9) > Created attachment 661196 [details] > patch to the issue > > Here is a proposed patch to fix that issue, using SipHash instead of bogus > MurmurHash, exactly as it was done in the C version of ruby. Thank you for that patch proposal, Martin. Just out-of-curiosity have you checked that with JRuby upstream? (would be great if they would accept it too / first) Thank you, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team
(In reply to comment #10) > Just out-of-curiosity have you checked that with JRuby upstream? (would be > great if they would accept it too / first) I just sent the patch to security, will see what they think of it. Thanks for reminding me. Do you have another idea of how I should/could report it upstream? Thanks for your time, Mt
(In reply to comment #11) > (In reply to comment #10) > > Just out-of-curiosity have you checked that with JRuby upstream? (would be > > great if they would accept it too / first) > > I just sent the patch to security, will see what they think of it. That would be sufficient. Thank you for doing that. Regards, Jan.
Created attachment 661686 [details] Updated version of the patch, picking the main change from upstream I was told by upstream that they already solved this CVE in the 1.7.1 branch, but not with SipHash (as done in C version) because it's too slow. Instead they used PerlHash. So I updated my patch, and uploaded to debian. Thanks for the advice of contacting upstream, I should have thought of it myself. Bye, Mt.
Changelog for 1.7.1 release: http://jruby.org/2012/12/03/jruby-1-7-1 and relevant patch: https://github.com/jruby/jruby/commit/5e4aab28b26fd127112b76fabfac9a33b64caf77
This issue has been addressed in following products: Fuse ESB Enterprise 7.1.0 Via RHSA-2012:1604 https://rhn.redhat.com/errata/RHSA-2012-1604.html
This issue has been addressed in following products: JBoss Enterprise SOA Platform 5.3.1 Via RHSA-2013:0533 https://rhn.redhat.com/errata/RHSA-2013-0533.html