Theo de Raadt <dera...@cvs.openbsd.org> wrote:
> In all of these code blocks are a well-known piece of information
> (same time on your machine as everywhere else) is being used to seed a
> deterministic number generator.
>
> At some later point, deterministic numbers are taken out using rand(),
> random(), drand48(), lrand48(), mrand48(), or srand48(), or some
> derivative function inside the program itself, and used for WHO KNOWS
> WHAT PURPOSE.
>
> I did not audit what the numbers are being used for.
>
> Quite likely some numbers are just used to help hashing. Some could
> be used to print pretty pictures. But in xulrunner? In the zip password
> creator? In postgresql, or say in openldap (a network related thing)?
>
> It is doubtful they are all fine.
>
> For the benefit of other projects who haven't taken the same steps as
> OpenBSD, it would be nice if some people helped out these pieces of
> software.
I took one as an example.
> apr-util-1.5.3 srand((unsigned int)(((time_now >> 32) ^ time_now) &
> 0xffffffff));
> apr-util-1.5.3 srand((unsigned int)apr_time_now());
Here is the only usage of rand in its entirety.
/* true_random -- generate a crypto-quality random number. */
static int true_random(void)
{
apr_uint64_t time_now;
#if APR_HAS_RANDOM
unsigned char buf[2];
if (apr_generate_random_bytes(buf, 2) == APR_SUCCESS) {
return (buf[0] << 8) | buf[1];
}
#endif
/* crap. this isn't crypto quality, but it will be Good Enough */
time_now = apr_time_now();
srand((unsigned int)(((time_now >> 32) ^ time_now) & 0xffffffff));
return rand() & 0x0FFFF;
}
Interestingly this is inside a UUID generator, which already uses time
as part of the unique value. Deterministic statistically random numbers
based on time don't help at all.
I looked into apr_generate_random_bytes and found that it is a giant
ifdef, which, if nothing is set, will reduce to a one line function
returning success. I hope their configure script doesn't continue if
nothing is set.
>From APR 1.5.1, which Theo's script didn't seem to catch:
#define arc4random() rand()
But if mkstemp is present, they assume random is also (I wonder why?)
and use
#define arc4random() random()
as if that were more secure.
I find no evidence of real arc4random in their tree. It's as if they're
relying on the magic of the name to protect them.
APR also has it's own random number generator in tree, which neither
the UUID generator nor the mkstemp replacement uses. I don't know enough
math to pass judgement on it other than saying random generation belongs
in some library or the kernel.
Apache HTTPD contains a large snarl of code intended to do OpenSSL's
job for it and seed it, but I don't know enough about OpenSSL to pass
judgement.
There are several more rand calls in HTTPD, including what appears to
be another random number generator, complete with comments indicating
that APR should have its own random number generator.
What I'm ultimately saying is that upstream's views on random number
generation can be mighty strange. Many are of the opinion that an
insecure fallback is better than refusing to compile. Not that it is an
excuse for poor software engineering, but many are old enough to be
rather jumbled in their library use.
I tried to CC their list but it won't let me post without subscribing
and furthermore I couldn't seem to subscribe.
-- Martin
