[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Nov 2012 16:10:24 +0100
From: Andrea Barisani <lcars@...rt.org>
To: Jan Lieskovsky <jlieskov@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: [oCERT-2012-001] multiple implementations
denial-of-service via MurmurHash algorithm collision
On Tue, Nov 27, 2012 at 10:00:55AM -0500, Jan Lieskovsky wrote:
> Hello Andrea,
>
Hello,
> thank you for the notification. Just quick check -
> could you confirm the correct CVE id for JRuby Murmur flaw
> should be CVE-2012-5370, and not CVE-2011-5370?
>
> Asking, because while oCERT-2012-001 page mentions CVE-2012-5370,
> it actually links against:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5370
>
> (so some of them is typo), and CVE-2011-5370 would also make
> sense in the order for other Murmur hash algorithm implementations
> for other languages.
>
You are quite correct, unfortunately there were typos in the other CVEs as
well which slipped during the advisory review.
I just corrected the advisory. The correct CVEs are the following:
CVE-2012-5370 (JRuby), CVE-2012-5371 (Ruby), CVE-2012-5372 (Rubinius),
CVE-2012-5373 (Oracle JDK, OpenJDK)
I apologize for the error.
Cheers
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team
>
> ----- Original Message -----
> #2012-001 multiple implementations denial-of-service via MurmurHash algorithm
> collision
>
> Description:
>
> A variety of programming languages suffer from a denial-of-service (DoS)
> condition against storage functions of key/value pairs in hash data
> structures, the condition can be leveraged by exploiting predictable
> collisions in the underlying hashing algorithms.
>
> The issue is similar to the one reported in oCERT-2011-003 and concerns the
> MurmurHash algorithm family. The condition for predictable collisions in the
> hashing functions has been reported for the following language
> implementations: JRuby (MurmurHash2), Ruby (MurmurHash2), Rubinius
> (MurmurHash3), Oracle JDK (MurmurHash), OpenJDK (MurmurHash). In the case of
> Java OpenJDK the hash function affected by the reported issue is not enabled
> by default, the default function is however reported vulnerable to
> oCERT-2011-003.
>
> Affected version:
> Ruby < 1.9.3-p327
> JRuby all versions
> Rubinius, all versions
> Oracle JDK <= 7
> OpenJDK <= 7
>
> Fixed version:
> Ruby >= 1.9.3-p327
> JRuby, N/A
> Rubinius, N/A
> Oracle JDK, N/A
> OpenJDK, N/A
>
> Credit: vulnerability report received from Jean-Philippe Aumasson
> <jeanphilippe.aumasson AT gmail.com>, PoC code and SipHash
> implementation used to patch the issue developed by Martin Bosslet
> <martin.bosslet AT gmail.com>.
>
> CVE: CVE-2012-5370 (JRuby), CVE-2011-5371 (Ruby), CVE-2011-5372 (Rubinius),
> CVE-2011-5373 (Oracle JDK, OpenJDK)
>
> Timeline:
> 2012-08-30: vulnerability report sent to Ruby, JRuby and Rubinius security contacts
> 2012-09-03: vulnerability report forwarded to oCERT by Hiroshi Nakamura (Ruby security contact)
> 2012-09-06: oCERT contacted reporters to investigate additional affected projects
> 2012-09-06: reporters indicate OpenJDK as vulnerable and that Java security team has been contacted on 2012-07-31
> 2012-09-10: oCERT requested CVE assignment for Ruby, JRuby and Rubinius
> 2012-09-12: Oracle JDK and OpenJDK confirmed vulnerable by reporters
> 2012-09-12: oCERT requested CVE assignment for Oracle JDK and OpenJDK
> 2012-10-10: reporters indicate public PoC release on 2012-11-07 at ASFWS
> 2012-11-08: assigned CVEs
> 2012-11-09: Ruby 1.9.3-p327 released
> 2012-11-23: advisory release
>
> References:
> https://www.131002.net/siphash
>
> Permalink:
> http://www.ocert.org/advisories/ocert-2012-001.html
>
> --
> Andrea Barisani | Founder & Project Coordinator
> oCERT | OSS Computer Security Incident Response Team
>
> <lcars@...rt.org> http://www.ocert.org
> 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
> "Pluralitas non est ponenda sine necessitate"
--
Andrea Barisani | Founder & Project Coordinator
oCERT | OSS Computer Security Incident Response Team
<lcars@...rt.org> http://www.ocert.org
0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
"Pluralitas non est ponenda sine necessitate"
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
