I've come across four race conditions in the following functions in
rsa_eay.c:
RSA_public_encrypt
RSA_public_decrypt
RSA_eay_mod_exp (x2)
These can cause unexpected failure of the RSA_eay_ encryption/decryption
functions for both public and private key operations. The problem occurs
when more than one thread simultaneously uses the same RSA key (more
specifically, when multiple threads simultaneously initialise
rsa->_method_mod_[npq] when RSA_FLAG_CACHE_PUBLIC is set). The problems are
only easily reproduceable on a multi-processor machine, although they can
also occur on a single processor machine.
I've attached a patch for OpenSSL 0.9.6, though I've only tested it on
0.9.5a. The patch uses CRYPTO_LOCK_RSA, but perhaps it should be rewritten
to use the dyn_locks added in 0.9.5b. In order to not add overhead to the
non-initialisation run through the function, I test _method_mod_[npq], then
lock if it is NULL, then test again (since after aquiring the lock
_method_mod_[npq] may have been set).
Regards,
Steven
--
Steven Reddie <[EMAIL PROTECTED]>
Senior Software Engineer
OpenDirectory Lab, Computer Associates Pty Ltd (Australia)
<<openssl-0.9.6-rsa-mt.diff>>
openssl-0.9.6-rsa-mt.diff
