apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject RE: svn commit: r1231605 - /apr/apr/trunk/tables/apr_hash.c
Date Sun, 15 Jan 2012 21:38:47 GMT
On Sun, 2012-01-15 at 18:06 +0100, Bert Huijben wrote:

> If you call srand() before every call to rand() the result is no longer random.

Yes, I'm aware of that.

> And in this case we do this inside a shared library, so this might introduce other attack
vectors in applications that use apr.

Also aware of that.

> If we really want to call srand() from apr we should do that from a one-time initialization
(apr_initialize? Or some initialize flag), to avoid breaking applications that assume rand()
produces random values for them. Calling srand() from apr_hash_make might even break scientific
applications that want the same set of random values multiple times (srand(CONSTANT)).

We can call srand() once as you suggest, but that doesn't mean something
else isn't going to call it from some other thread at any point. Relying
on rand() returning predictable values in a multi-threaded app would be
naive anyway.

> If the timer has enough detail we could just use the time, ptr combination as the seed
here. This is essentially what the code does by calling srand() every time anyway.

That is true. In fact, my first code to the list just used ht. We could
use ht and time to get "random" values. Same attack vectors as noted by
you above apply, of course.


View raw message