-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[ Philip Zimmermann provided us with this additional technical
information from Hal Finney. -- CERT/CC]

There is a buffer overflow, which is triggered by passing in a private
or public key whose modulus is larger than the library is designed to
handle.  This is passed into RSAREF in a struct called R_RSA_PRIVATE_KEY,
which looks like:

typedef struct {
  unsigned int bits;                           /* length in bits of modulus */
  unsigned char modulus[MAX_RSA_MODULUS_LEN];                    /* modulus */
  unsigned char publicExponent[MAX_RSA_MODULUS_LEN];     /* public exponent */
  unsigned char exponent[MAX_RSA_MODULUS_LEN];          /* private exponent */
  unsigned char prime[2][MAX_RSA_PRIME_LEN];               /* prime factors */
  unsigned char primeExponent[2][MAX_RSA_PRIME_LEN];   /* exponents for CRT */
  unsigned char coefficient[MAX_RSA_PRIME_LEN];          /* CRT coefficient */
} R_RSA_PRIVATE_KEY;

What has to be done is to create a bogus struct, with the "bits" field
bigger than the maximum allowed by RSAREF.  This then causes RSAREF
to overflow an internal buffer, messing up the stack and allowing the
attacker to get control.

Needless to say, we do not create bogus structs, hence our code will
not trigger this bug.  Furthermore we always check the input keys to
make sure they are legal sizes for RSAREF before we call that code.

In the case of ssh it was necessary for the attackers to exploit another
bug, one in the code which calls RSAREF.  Using this bug they were able
to construct the bogus struct and cause the stack problem.  No such bugs
are known in our code which calls RSAREF.

There are two other issues which differentiate our use of RSAREF from that
of ssh, but they do not turn out to be important.  First, we use RSAREF
while they use RSAREF2, a newer version.  However the relevant code is
the same in the two versions.  Second, our RSAREF is modified to allow
the library to use our modular exponentiation function rather than the
built-in one.  However this operation is not where the bug lies, it is
when the final results are packed up for returning to the caller, and
that code is the same in the two versions.

The important difference remains that the attacker needs a way to
influence the R_RSA_PRIVATE_KEY struct in order to trigger the bug.
Our code is completely different from the ssh code which sets up this
data structure, and so we do not appear to be vulnerable to it.

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOFF4dFr9kb5qlZHQEQLyKACeNg1luWx7lCliU1g/u7pje5+8ICAAnRyD
MK61eTqkeVTBkZjEpI6M928e
=+8ZI
-----END PGP SIGNATURE-----