On 11/03/2011 01:44 AM, Jonathan Nieder wrote:
> What do you think? Is forcing !APR_HAS_RANDOM and just using
> apr_time_now() as Debian currently does safe, or does it expose users
> to a security risk?
I suspect it makes the server vulnerable to a replay attack.
The right answer is to use /dev/urandom. Using /dev/random has highly
questionable advantages over using /dev/urandom, and it's unfortunate
that APR only provides an interface to one and not the other.
A longer analysis: if a system has collected even a small amount of
entropy (128 bits) relative to what an attacker can guess since boot, it
can generate an infinite amount of pseudo-random data without risk of
vulnerability, if it uses a suitable PRNG function. The actual dangers
are that (1) the system has not accumulated enough entropy, and maybe we
should wait until it has, or (2) the system has a bad PRNG function.
Using /dev/random does not protect against either threat very effectively.
As for the first threat, it's very difficult to mitigate because a
system cannot generally estimate its entropy very well. It throws
possible entropy events into a pool and mixes them together, but it
doesn't have a very good measure of how guessable those events were.
PRNG algorithms like Fortuna seek to guarantee that the PRNG will
eventually reach an unguessable state (by ensuring that more and more
possible entropy is used each time the internal state is updated, until
eventually an update happens that the attacker can't brute-force), but
they can't tell you when they've reached that point.
As for the second threat, at least on Linux, /dev/random output still
comes from the PRNG. It just keeps an internal counter and blocks when
the PRNG has "run out of" its guess at estimated input entropy. (This
is exceedingly silly, because a PRNG doesn't "use up" input entropy as
it generates results; either it has unguessable internal state or it
doesn't.) An application can only protect against a poor system PRNG by
implementing its own generator, and it's far simpler to declare it the
system's responsibility to fix its PRNG if there's a security issue
associated with it.
Received on 2011-11-03 16:29:49 CET