> I committed a patch to that effect to our RSAREF wrapper functions.
Well, I just undid the change. SSLeay or OpenSSL-based applications
are not vulnerable to the buffer overrun error.
The alleged problem is:
"Providing a suitable modulus length to RSAPrivateDecrypt() it is
possible to force NN_Encode() to copy data beyond the bounds of pkcsBLock"
In SSLeay / OpenSSL the modulus length is set in the functions
RSAref_Public_eay2ref and RSAref_Private_eay2ref. Both of these
functions do check all parameters against the RSAREF maximum. That
means that RSAREF is not called if the modulus is longer than
MAX_RSA_MODULUS_LEN.
But even for programs that use RSAREF directly, CORE SDI's proposed
bug fix doesn't make any sense. You have to make sure that
{public,private}Key->bits does not exceed 1024. In their patch, they
test the size of inputLen instead. (If inputLen >= publicKey->bits, an
error occurs regardless of whether publicKey->bits is within the
specified range or not. On the other hand, if publicKey->bits is too
big, we have a problem, but the value of inputLen doesn't make any
difference.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
