Bug 477212 - (CVE-2008-5659) CVE-2008-5659 gnu.java.security.util.PRNG produces easily predictable values
CVE-2008-5659 gnu.java.security.util.PRNG produces easily predictable values
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://nvd.nist.gov/nvd.cfm?cvename=C...
source=cve,reported=20081217,public=2...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-19 12:23 EST by Tomas Hoger
Modified: 2010-05-12 14:03 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-12 14:03:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch derived from upstream CVS commits (23.20 KB, patch)
2010-01-26 15:40 EST, Vincent Danen
no flags Details | Diff
gcc41-CVE-2008-5659.patch (46.26 KB, patch)
2010-01-28 04:19 EST, Jakub Jelinek
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2008-12-19 12:23:23 EST
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-5659 to the following vulnerability:

The gnu.java.security.util.PRNG class in GNU Classpath 0.97.2 and
earlier uses a predictable seed based on the system time, which makes
it easier for context-dependent attackers to conduct brute force
attacks against cryptographic routines that use this class for
randomness, as demonstrated against DSA private keys.

Upstream bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417

Reference:
http://www.openwall.com/lists/oss-security/2008/12/06/2
Comment 1 Tomas Hoger 2008-12-19 12:27:24 EST
PRNG implementation in GNU Classpath is based on gnu-crypto implementation.  Version of gnu-crypo as shipped in Red Hat Enterprise Linux 5 does not implement getInstance method of the PRNG (gnu.crypto.util.PRNG) class, but uses millisecond-based reinitialization in nextBytes(), so may be affected by this problem as well.
Comment 2 Vincent Danen 2010-01-26 15:40:08 EST
Created attachment 386916 [details]
patch derived from upstream CVS commits

Attached is a patch derived from upstream CVS using cvs-git, based on comments from upstream's bugzilla (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38417#c11) that are meant to correct this in gnu classpath (fixed upstream in 0.98).

This would be a good starting point to see whether gnu-crypto is affected or not.
Comment 5 Jakub Jelinek 2010-01-27 10:59:09 EST
And, RHEL6 gcc (and clearly also the RHEL5 gcc44 source) don't seem to be vulnerable.
Both contain the:
libjava/
2009-02-13  Andrew John Hughes  <ahughes@redhat.com>

        * Makefile.am: Add natVMSecureRandom.cc.
        * Makefile.in: Regenerated.
        * classpath/ChangeLog,
        * classpath/gnu/java/security/jce/prng/SecureRandomAdapter.java,
        * classpath/gnu/javax/crypto/jce/prng/ARCFourRandomSpi.java,
        * classpath/gnu/javax/crypto/jce/prng/CSPRNGSpi.java,
        * classpath/gnu/javax/crypto/jce/prng/FortunaImpl.java,
        * classpath/gnu/javax/crypto/jce/prng/ICMRandomSpi.java,
        * classpath/gnu/javax/crypto/jce/prng/UMacRandomSpi.java,
        * classpath/gnu/javax/crypto/prng/ICMGenerator.java,
        * classpath/java/security/SecureRandom.java: Merged.
        * configure: Regenerated.
        * configure.ac: Add symlink for natVMSecureRandomPosix.cc to natVMSecureRandom.cc
        * gnu/java/security/jce/prng/SecureRandomAdapter.h: Regenerated.
        * gnu/java/security/jce/prng/VMSecureRandom.h: Generated.
        * gnu/java/security/jce/prng/VMSecureRandom.java: Added native implementation.
        * gnu/java/security/jce/prng/natVMSecureRandomPosix.cc: Wrapper around /dev/random.
        * gnu/javax/crypto/jce/prng/CSPRNGSpi.h,
        * gnu/javax/crypto/jce/prng/FortunaImpl.h,
        * java/security/SecureRandom.h: Regenerated.
        * java/security/VMSecureRandom$Spinner.h,
        * java/security/VMSecureRandom.h,
        * java/security/VMSecureRandom.java: Removed.
        * sources.am: Move VMSecureRandom to gnu.java.security.jce.prng.

libjava/classpath/
2009-02-03  Andrew John Hughes  <ahughes@redhat.com>

        PR classpath/38417:
        * gnu/java/security/jce/prng/SecureRandomAdapter.java:
        Remove unneeded import.
        * gnu/javax/crypto/jce/prng/FortunaImpl.java:
        Fix typo.
        * java/security/SecureRandom.java:
        Remove duplicate use of VMSecureRandom,
        call SecureRandomAdapter instead.
        * vm/reference/gnu/java/security/jce/prng/VMSecureRandom.java:
        Moved from java/security so SecureRandomAdapter can
        access it.

2009-01-22  Mario Torre  <neugens@aicas.com>

        PR classpath/38417:
        * gnu/java/security/jce/prng/SecureRandomAdapter.java:
        (getSeed(int)): New; retrieve seed from source specified
        by securerandom.source property or failing that, use
        VMSecureRandom.
        * gnu/javax/crypto/jce/prng/ARCFourRandomSpi.java:
        (engineGenerateSeed(int)): Use SecureRandomAdapter.
        (engineNextBytes(byte[])): Initialise using new seed.
        * gnu/javax/crypto/jce/prng/CSPRNGSpi.java:
        (engineGenerateSeed(int)): Use SecureRandomAdapter.
        (engineNextBytes(byte[])): Initialise using new seed.
        * gnu/javax/crypto/jce/prng/FortunaImpl.java:
        (engineSetSeed(byte[])): Initialise with new seed if unused.
        (engineGenerateSeed(int)): Use SecureRandomAdapter.
        * gnu/javax/crypto/jce/prng/ICMRandomSpi.java:
        (engineGenerateSeed(int)): Use SecureRandomAdapter.
        (engineNextBytes(byte[])): Initialise using new seed.
        * gnu/javax/crypto/jce/prng/UMacRandomSpi.java:
        (engineGenerateSeed(int)): Use SecureRandomAdapter.
        (engineNextBytes(byte[])): Initialise using new seed.
        * gnu/javax/crypto/prng/ICMGenerator.java:
        (setup(Map)): Call fillBlock().
changes.  So that would leave just the RHEL5 gcc (and maybe gnu-crypto) vulnerable.
Comment 6 Jakub Jelinek 2010-01-28 04:19:31 EST
Created attachment 387274 [details]
gcc41-CVE-2008-5659.patch

Completely untested backport of the patch to 4.1.2-RH.
Comment 8 Vincent Danen 2010-03-19 12:38:24 EDT
Ok, this is a bit of a dependency rabbit trail.

gnu-crypto package builds gnu-crypto-sasl-jdk1.4, which provides "java-sasl".  Oddly enough, the bits used to build java-sasl come from GNU Classpath which we include in the gnu-crypto package specifically for this purpose:

Source1:        ftp://ftp.gnu.org/gnu/classpath/classpath-0.92.tar.gz
...
tar xzf %{SOURCE1}
mkdir -p security/javax/security
mv classpath-0.92/javax/security/sasl security/javax/security

java-sasl is required by classpathx-mail, which in turn provides "javamail".  javamail is then in turn required by tomcat5-common-lib, and tomcat5 is provided in RHDS3, RHAPS, and Certificate System.

So it looks like nothing actually uses gnu-crypto at all, the only thing we seem use are the SASL bits taken from GNU Classpath.

In light of this, this vulnerability is not exposed by default in anything we provide that I can see.  Certainly not for the use or generation of keys, which is the primary problem here.  While gnu-crypto has this vulnerability, and it may impact third-party programs that a customer might install, this would not affect anything we actually provide.

I'm going to drop this down to impact=low and we need to decide whether to drop or defer this.  The other thing I am noticing here is that this is documented design behaviour; http://www.gnu.org/software/gnu-crypto/#configuration states (for the configuration boolean gnu.crypto.with.reproducible.prng):

"For the sake of convenience, all invocations in this library to generate cryptographically strong pseudo-random data (bytes) are done through a classloader Singleton, inside the gnu.crypto.util.PRNG class. This Singleton generator is an instance of the pseudo-random number generator based on a generic hash function\u2014the class gnu.crypto.prng.MDGenerator\u2014using, in this case, the Secure Hash Standard (SHS, also known as the Secure Hash Algorithm SHA with 160-bit output block size). This is appropriate for two reasons:

   1. this method of generating random data is the one prescribed in the Digital Signature Standard (DSS),
   2. other digital signature schemes, implemented so far in this library, do not mandate any prescribed way for generating random data.

However, this type of generator works by hashing the output of a previous digest operation; i.e. the input to the hash function at time N is its output at time N-1, with the starting input being a 0-long octet string. The sequence of generated bytes from such a generator is then reproducible. This is useful for test and debugging purposes only and obviously should not be the case in any security-conscious application.

Default value: false

true: Indicates that the default PRNG used, when one is needed but none has been specified, will produce the same bit stream with every VM instance.

false: Indicates that the default PRNG used will be initialised (seeded) with the current time of day, thus yielding a different bit stream output with every VM instance."

Which makes me wonder whether or not we should just drop this altogether since it states it is really only useful for test and debugging purposes (unless I am reading this wrong).  Is this the case of someone finding a security issue in something that was never really meant to be used in production?  Would this fix not be considered a security _enhancement_ given the above documentation?
Comment 9 Vincent Danen 2010-03-19 12:50:11 EDT
It would be ideal if someone could double-check the above analysis and CVSS score; I believe they should be accurate for our use of gnu-crypto.  We also need to make a decision as to whether we drop or defer this.
Comment 10 Josh Bressers 2010-05-12 13:48:30 EDT
(In reply to comment #9)
> It would be ideal if someone could double-check the above analysis and CVSS
> score; I believe they should be accurate for our use of gnu-crypto.  We also
> need to make a decision as to whether we drop or defer this.    

Your analysis looks correct, and the documentation does state "security-conscious" applications should not use this. This is likely reflected in the fact that we've not found anything that actually uses this functionality.

I say we drop this. It's fixed in future versions, we're not gaining any real benefit by fixing such a minor flaw in old versions. The risk vs reward is too low.
Comment 11 Josh Bressers 2010-05-12 14:00:15 EDT
Statement:

The risks associated with fixing this bug are greater than the low severity
security risk.  We therefore currently have no plans to fix this flaw in
Red Hat Enterprise Linux 5.

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