Re: [oCERT-2012-001] multiple implementations denial-of-service via MurmurHash algorithm collision

["Steven M. Christey" <coley () rcf-smtp mitre org>]

Fortunately, CVE-2011-5370 through CVE-2011-5373 don't even exist, so I 
will REJECT these 2011 typos.

- Steve


On Tue, 27 Nov 2012, Andrea Barisani wrote:

> 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 () ocert 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 () ocert org>                         http://www.ocert.org
> 0x864C9B9E 0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E
>        "Pluralitas non est ponenda sine necessitate"