Bug 477212 (CVE-2008-5659)

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.

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.

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>

        * 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>

        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>

        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.

Created attachment 387274 [details]
gcc41-CVE-2008-5659.patch

Completely untested backport of the patch to 4.1.2-RH.

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?

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.

(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.

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.