On 21 August 2013 03:19, Patrick Pelletier <c...@funwithsoftware.org> wrote:
> On 8/15/13 11:51 PM, Patrick Pelletier wrote: > >> On Aug 15, 2013, at 10:38 PM, Nico Williams wrote: >> >> Hmm, I've only read the article linked from there: >>> http://android-developers.**blogspot.com/2013/08/some-** >>> securerandom-thoughts.html<http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html> >>> >>> >> Yeah, that's the only place I've seen it, and then the Google+ thread I >> linked to is essentially the comment area for that post. We (meaning >> those of us commenting in the thread) haven't gotten any official answer >> from Google, but Nikolay Elenkov has been very helpful in reconstructing >> what seems to be happening. We've exchanged a few more posts this >> evening, and it appears that what's happening is that OpenSSL is >> correctly self-seeding when system_server starts, but then system_server >> forks (without execing) to start multiple processes, and these processes >> are producing the same random sequence. It's not yet entirely clear >> why, since the OpenSSL source code looks like it's trying to be >> fork-safe, but it appears that somehow in practice it's not succeeding. >> > > s/system_server/zygote/ > > So, it appears that the problem is that since OpenSSL merely mixes in the > pid to the existing random state, once the pids wrap, you will have had two > processes that have generated the exact same random sequence, since they > started with the same state (before the fork) and mixed in the same thing > (the pid) after the fork, resulting in the same output. (This is in > contrast to the approach of comparing the old and new pids, and doing a > full reseed from /dev/urandom if they differ, which is what is done by Nick > Mathewson's preliminary but already excellent-looking libottery.) > > Nikolay Elenkov wrote a proof-of-concept that shows the pid-wrapping bug > on Android, and then I took it one step further and wrote a > proof-of-concept using OpenSSL in C, demonstrating that this is an > underlying OpenSSL bug: > > https://gist.github.com/**ppelleti/6290984<https://gist.github.com/ppelleti/6290984> > > An easy way to work around this, if you don't mind linking against > pthreads, is to do this at the start of your application, after > initializing OpenSSL: > > typedef void (*voidfunc) (void); > > if (ENGINE_get_default_RAND () == NULL) > pthread_atfork (NULL, (voidfunc) RAND_poll, (voidfunc) RAND_poll); > > But, of course, this ought to eventually be fixed in OpenSSL itself. (By > using the pid-comparison trick that libottery uses, rather than just mixing > in the pid.) I'm happy to submit a patch, if we think there's a good > chance it would be considered? > Something needs to be done, but won't this re-introduce the problem of /dev/random starvation, leading to more use of /dev/urandom (on platforms where this is a problem)? Mixing in the time seems like a safer solution that should also fix the problem. Possibly only when the PID changes. > > --Patrick > > ______________________________**______________________________**__________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
