Tom, > 3. arc4random puts a generator in the user process. > > This is much more controversial. Some people (Anthony F. for one and myself > until recently) argue that a generator algorithm in the user process > degrades security. It must in any case be downstream of the kernel source > and therefore cannot compensate for any problems in using kernel randomness. > Moreover, it adds another point of failure (a place where there might be > bugs, like OpenSSL's RNG bugs). And finally, since the downstream generator > is in the user process rather than protected kernel memory, it's easier for > an attacker to learn the generator's state and thus predict future outputs. > > Others, including Dan Bernstein[1] and the OpenBSD crowd[2], argue that the > later is theoretical rather than a practical vulnerability because if an > attacker can read your memory then your crypto system is a total fail > regardless where you get random numbers from.
There is one important nuance here though. If an attacker can read memory they they can compromise anything currently in memory for the application. Things that have since been freed (such as tokens and secrets generated from prior requests) are typically safe. However, using a userland RNG, that's not necessarily true unless a reseed (stir) event happened between them. So you do lose some practical forward security in that things that otherwise may not have been leaked may be leaked. So I would still consider it a practical vulnerability. And an attacker reading memory is only game over if they can control how and when that memory is read. It's a fail in any case, but if the exploit only allows them to ever see memory from their request, it's a lot less damaging than if they can see other's requests on the system. It's still quite bad, but there's definitely a difference. Thanks again for the discussion Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
