Bug 880671 (CVE-2012-5370) - CVE-2012-5370 jruby: Murmur hash function collisions (oCERT-2012-001)
Summary: CVE-2012-5370 jruby: Murmur hash function collisions (oCERT-2012-001)
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2012-5370
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 880674 881571
Blocks: 875553 880678 883225
TreeView+ depends on / blocked
 
Reported: 2012-11-27 15:04 UTC by Jan Lieskovsky
Modified: 2019-09-29 12:58 UTC (History)
8 users (show)

Fixed In Version: JRuby 1.7.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 05:14:39 UTC
Embargoed:


Attachments (Terms of Use)
patch to the issue (11.08 KB, patch)
2012-12-10 23:50 UTC, Martin Quinson
no flags Details | Diff
Updated version of the patch, picking the main change from upstream (4.78 KB, patch)
2012-12-11 21:07 UTC, Martin Quinson
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:1604 0 normal SHIPPED_LIVE Moderate: Fuse ESB Enterprise 7.1.0 update 2012-12-21 08:10:20 UTC
Red Hat Product Errata RHSA-2013:0533 0 normal SHIPPED_LIVE Important: JBoss Enterprise SOA Platform 5.3.1 update 2013-02-21 02:42:25 UTC

Description Jan Lieskovsky 2012-11-27 15:04:21 UTC
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

Comment 1 Jan Lieskovsky 2012-11-27 15:16:38 UTC
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).

Comment 2 Jan Lieskovsky 2012-11-27 15:17:32 UTC
Created jruby tracking bugs for this issue

Affects: fedora-all [bug 880674]

Comment 3 Jan Lieskovsky 2012-11-27 15:19:59 UTC
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/

Comment 6 David Jorm 2012-11-29 06:06:18 UTC
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

Comment 7 David Jorm 2012-11-29 06:16:26 UTC
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

Comment 9 Martin Quinson 2012-12-10 23:50:35 UTC
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.

Comment 10 Jan Lieskovsky 2012-12-11 09:17:59 UTC
(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

Comment 11 Martin Quinson 2012-12-11 13:17:44 UTC
(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

Comment 12 Jan Lieskovsky 2012-12-11 13:39:32 UTC
(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.

Comment 13 Martin Quinson 2012-12-11 21:07:01 UTC
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.

Comment 14 Jan Lieskovsky 2012-12-12 10:56:32 UTC
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

Comment 16 errata-xmlrpc 2012-12-21 03:10:51 UTC
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

Comment 17 errata-xmlrpc 2013-02-20 21:44:32 UTC
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


Note You need to log in before you can comment on or make changes to this bug.