Bug 396305 – <dev-java/jruby-1.6.5.1 Hash collision DoS (CVE-2011-4838)

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Alex Legler (RETIRED) 2011-12-28 14:29:22 UTC]

+++ This bug was initially created as a clone of Bug #396301 +++

"The situation is similar to the one found for Perl in 2003. In 1.8 series of Ruby, we use a deterministic hash function to hash a string. Here the "deterministic" means no other bits of information than the input string itself is involved to generate a hash value. So you can precalculate a string's hash value beforehand. By collecting a series of strings that have the identical hash value, an attacker can let ruby process collide bins of hash tables (including Hash class instances). Hash tables' amortized O(1) attribute depends on uniformity of distribution of hash values. By giving such crafted input, an attacker can let hash tables work much slower than expected (namely O(n2) to construct a n-elements table this case)."

Upstream released 1.6.5.1 to address this issue.

[Comment 1 GLSAMaker/CVETool Bot 2012-01-02 18:59:36 UTC]

CVE-2011-4838 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4838):
  JRuby before 1.6.5.1 computes hash values without restricting the ability to
  trigger hash collisions predictably, which allows context-dependent
  attackers to cause a denial of service (CPU consumption) via crafted input
  to an application that maintains a hash table.

[Comment 2 Hans de Graaff 2012-01-23 19:54:38 UTC]

Update: with joint effort from the ruby and java team we now have a jruby 1.6.5.1 ebuild in the ruby overlay which appears to be working but needs further testing. We also need some updated java dependencies in CVS before we can move this ebuild there.

[Comment 3 Hans de Graaff 2012-04-14 07:10:57 UTC]

jruby 1.6.5.1 is now in the main tree.

[Comment 4 Tim Sammut (RETIRED) 2012-04-14 14:38:34 UTC]

Arches, please test and mark stable:
=dev-java/jruby-1.6.5.1
Target keywords : "amd64 x86"

[Comment 5 Myckel Habets 2012-04-21 07:33:55 UTC]

I get a bunch of unstable java packages as blocking dependencies on x86. Any info on how to proceed?

=dev-java/bytelist-1.0.9 ~x86
=dev-java/jnr-x86asm-1.0.1 ~x86
=dev-java/jcodings-1.0.5 ~x86
=dev-java/jnr-posix-1.1.8 ~x86
=dev-java/jnr-constants-0.8.2 ~x86
=dev-java/osgi-core-api-4.3 ~x86
=dev-java/jnr-ffi-0.5.10 ~x86
=dev-java/jffi-1.0.11 ~x86
=dev-java/snakeyaml-1.9 ~x86

[Comment 6 Hans de Graaff 2012-04-21 08:50:01 UTC]

(In reply to comment #5)
> I get a bunch of unstable java packages as blocking dependencies on x86. Any
> info on how to proceed?
> 
> =dev-java/bytelist-1.0.9 ~x86
> =dev-java/jnr-x86asm-1.0.1 ~x86
> =dev-java/jcodings-1.0.5 ~x86
> =dev-java/jnr-posix-1.1.8 ~x86
> =dev-java/jnr-constants-0.8.2 ~x86
> =dev-java/osgi-core-api-4.3 ~x86
> =dev-java/jnr-ffi-0.5.10 ~x86
> =dev-java/jffi-1.0.11 ~x86
> =dev-java/snakeyaml-1.9 ~x86

These should also be stabilized, unless the java folks have more specific requirements for versions. @java, if so, then please add a comment.

[Comment 7 Agostino Sarubbo 2012-04-30 10:49:01 UTC]

amd64 stable

[Comment 8 Ralph Sennhauser (RETIRED) 2012-05-05 14:20:00 UTC]

*** Bug 414715 has been marked as a duplicate of this bug. ***

[Comment 9 Paweł Hajdan, Jr. (RETIRED) 2012-05-09 17:10:41 UTC]

x86 stable, closing

[Comment 10 Paweł Hajdan, Jr. (RETIRED) 2012-05-09 17:12:34 UTC]

(In reply to comment #9)
> x86 stable, closing

Re-opening, that was automated tool, sorry.

[Comment 11 Tim Sammut (RETIRED) 2012-05-09 22:56:07 UTC]

Thanks, everyone. GLSA Vote: Yes.

[Comment 12 Sean Amoss (RETIRED) 2012-06-11 19:22:58 UTC]

GLSA vote: yes. 

Filing GLSA request.

[Comment 13 GLSAMaker/CVETool Bot 2012-07-09 22:39:13 UTC]

This issue was resolved and addressed in
 GLSA 201207-06 at http://security.gentoo.org/glsa/glsa-201207-06.xml
by GLSA coordinator Sean Amoss (ackle).