+++ 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 18.104.22.168 to address this issue.
JRuby before 22.214.171.124 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.
Update: with joint effort from the ruby and java team we now have a jruby 126.96.36.199 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.
jruby 188.8.131.52 is now in the main tree.
Arches, please test and mark stable:
Target keywords : "amd64 x86"
I get a bunch of unstable java packages as blocking dependencies on x86. Any info on how to proceed?
(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.
*** Bug 414715 has been marked as a duplicate of this bug. ***
x86 stable, closing
(In reply to comment #9)
> x86 stable, closing
Re-opening, that was automated tool, sorry.
Thanks, everyone. GLSA Vote: Yes.
GLSA vote: yes.
Filing GLSA request.
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).