On Tue, Sep 03, 2002 at 05:29:41PM -0700, Patrick McCormick wrote:
> I needed to add the following calls in my single-thread "openssl setup" code
> to end several race conditions:
>
> SSLv23_client_method();
> SSLv2_client_method();
> SSLv3_client_method();
> TLSv1_client_method();
> SSLv23_method();
> SSLv2_method();
> SSLv3_method();
> TLSv1_method();
> SSLv23_server_method();
> SSLv2_server_method();
> SSLv3_server_method();
> TLSv1_server_method();
> ssl2_get_cipher_by_char("XXX");
> ssl3_get_cipher_by_char("XXX");
These functions appear to follow the same pattern (the
..._get_cipher_by_char functions actually use locks because they do
more than just simple assignments and copying).
> I also see race conditions in crypto/rand/md_rand.c that I don't see a
> workaround for. There's an init race in ssleay_rand_bytes. Multiple
> threads can call in and end up in the initialization code if init==0. I'm
> not sure why there is a lock around "if (init)", since this lock doesn't
> prevent multiple initialization.
>
> These threads then both call RAND_seed (ssleay_rand_seed, for me) at once.
> ssleay_rand_seed modifies globals without any locking, so it doesn't appear
> thread safe.
Er, what version of OpenSSL are you looking at? In 0.9.6g, we have
static int ssleay_rand_bytes(unsigned char *buf, int num)
{
[...]
CRYPTO_w_lock(CRYPTO_LOCK_RAND);
/* prevent ssleay_rand_bytes() from trying to obtain the lock again */
CRYPTO_w_lock(CRYPTO_LOCK_RAND2);
locking_thread = CRYPTO_thread_id();
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
if (!initialized)
{
RAND_poll();
initialized = 1;
}
so the call to RAND_poll() (and eventually to ssleay_rand_see())
happens inside the write lock, meaing that only a single thread can do
this at a time.
> ssleay_rand_bytes modifies globals (md, md_count, etc.) without locking, so
> the random byte buffer can be filled from "md" while another thread is
> rewriting the contents of "md". Also, "md_count[0]++" has undefined
> results.
"md_count[0] += 1" and access to "md" happens while the thread has the
CRYPTO_LOCK_RAND lock. Some accesses to the "state" array are not
protected by locking, however, because it does not really matter which
thread wins.
--
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
