[openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c

[Mick Saxton via RT]

I modified your patch to also catch the similar problem in ssleay_rand_bytes.
Results from the instrumented tests attached.

These tests were run on 64-bit Windows 7.
I have not specified a locking callback so will be using the default – could this be the problem?

Each thread has it’s own SSL_ctx and each connection is only ever serviced by the same thread.

It looks like state_index is going outside of the expected range.

This is possible if one or more threads do
   state_index += num_ceil;

and then another thread reads it before
   if ( state_index > state_num )
      state_index %= st_num.;

Thanks for your help


From: Matt Caswell via RT [mailto:rt at openssl.org]
Sent: 18 June 2016 00:08
To: Mick Saxton
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #4545] Crash in crypto/rand/md_rand.c



On 17/06/16 20:56, Matt Caswell via RT wrote:
>
>
> On 17/06/16 19:43, Mick Saxton via RT wrote:
>> Perhaps we should consider if there are any negative consequences to my solution?
>> It does work.
>>
>> I am trying really hard to get contention but I am only seeing this problem in about 1 out of 100,000 successful TLSv1.2 connections
>> On a heavily congested network.
>> I require three machines to just to run the test that causes the failure.
>>
>> All we are trying to do is get a random number – surely getting a slightly less random number is better than crashing?
>> It could be that the problematic instances were going to disconnect anyway due to TCP/IP problems.
>>
>
> I think we need to try instrumenting the code to see if we can get some
> more information out. I will try and pull something together - but it
> might be Monday before I get the opportunity.

I got to it quicker than I thought. Please see attached patch. Can you
apply it to the latest git 1.0.2 version and re-run your test (capture
stderr output). I'd like to see what we get.

Also is this 32-bit or 64-bit Windows? Are you able to share your
locking callback implementation?

Thanks

Matt


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545<http://rt.openssl.org/Ticket/Display.html?id=4545>
Please log in as guest with password guest if prompted

________________________________


Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4545
Please log in as guest with password guest if prompted

-------------- next part --------------
MD_RAND ERROR: ssleay_rand_add: k == 35, j == 4, st_idx == 1054, state_num == 1023, do_not_lock 0, crypto_lock_rand == 0, locking_threadid == 3204, thisthreadid == 2756
 MD_RAND ERROR: ssleay_rand_add: k == 35, j == 4, st_idx == 1054, state_num == 1023, do_not_lock 0, crypto_lock_rand == 0, locking_threadid == 3204, thisthreadid == 2756
MD_RAND ERROR: ssleay_rand_bytes: k == 23, j == 10, st_idx == 1036, state_num == 1023, do_not_lock N/A, crypto_lock_rand == 0, locking_threadid == 8176, thisthreadid == 8176