Marc-Andre Lemburg added the comment: On 07.06.2016 21:12, Cory Benfield wrote: > >> Python hash randomization only happens once. So it's not a matter of how >> early we try the attack, it's a matter of how early we seed Python hash >> randomization. > > Sorry Larry, I was insufficiently clear (relying on context from earlier). I > totally agree that Python startup should not block. I'm saying that having > getrandom() called in "blocking mode" for os.urandom, random.SystemRandom, > and secrets is not a DoS vector.
I'm not sure I follow. A delay of 90 seconds on startup of a VM or container can easily lead the supervisor style management tool to think that something is wrong and issue a retry. Depending on the configuration it'll then try this a couple of times and give up. Overall, I have a hard time following the arguments. To be clear: getrandom() on Linux is just a wrapper with some additional control around /dev/random and /dev/urandom. http://lxr.free-electrons.com/source/drivers/char/random.c#L1601 Unlike /dev/urandom, getrandom() without flag GRND_NONBLOCK will block, but only in the case where the entropy pool has not been initialized yet. Once this has been done, it will never block again, and happily send you poor random data if the entropy pool has been completely wiped of any entropy data - without telling you. So now, you're all arguing: oh my, it's so insecure to use data from /dev/urandom when the entropy pool is not initialized. But you're not worried about os.urandom() happily sending you data which is no longer based on any external entropy half an hour later: http://lxr.free-electrons.com/source/drivers/char/random.c#L1458 This doesn't make sense. Either you're worried all the time, or you're not :-) The whole discussion is centering around whether to block on an uninitialized entropy pool or not. This can only happen during startup. By falling back to reading /dev/urandom in case of an uninitialized pool, you are reading data from a not fully initialized pool, but you still get random data. That's really all that's needed for basic operations like hash seeding or seeding the PRNG in the random module. And it's limited to Python processes which are run very early in the VM/container startup phase. Note that "uninitialized" only means that the kernel entropy pool has not yet reached an "entropy level" of 128 (whatever that means): http://lxr.free-electrons.com/source/drivers/char/random.c#L676 It does not mean that you're just reading a list of zeros. So given all this information, why is it that you get so tangled up in wanting os.urandom() to block during system startup ? Or put differently: Where is the attack vector that blocking behavior of os.urandom() would help remedy ? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
