Has use of /dev/urandom instead of /dev/random ever caused a vulnerability?

Question

Not theoretical mumbo jumbo. Has anyone, ever, in any way, made known an actual exploitable vulnerability due to using /dev/urandom? One that would have been mitigated if they had instead used /dev/random?

Answer 1

Yes, there are.

A quick search shows CVE-2003-0094 for instance:

A patch for mcookie in the util-linux package for Mandrake Linux 8.2 and 9.0 uses /dev/urandom instead of /dev/random, which causes mcookie to use an entropy source that is more predictable than expected, which may make it easier for certain types of attacks to succeed.

Issues of using /dev/urandom instead of /dev/random may occur during the boot sequence. At that time, the system may not have enough entropy available to provide safe random numbers.

Concretely, this "entropy" designates the number of possible internal states for the pseudo-random numbers generator (PRNG):

• When the start sequence is being initiated, the system starts from a known state, always the same (particularly true for virtual images), and mostly the same also on any other identical environment.

• As the system processes more and more "things" (I/O or whatever), the number of possible states also growths more and more.

• But during the boot sequence, relatively few things are being processed and above all these are mostly the same each time and on each identical environment.

The CVE linked above targets mcookie, which generates a secret for X authentication. But the very same thing for instance would also apply for the automatic generation of new SSH keys on the first boot after the installation of a system or the deployment of a new virtual machine.

A well-founded attacker could run the initial boot sequence of your VM template tens or hundreds of thousands of times and collect the keys generated each time. As the combination of ways a freshly installed system may boot is not infinite, I expect that at some point the attacker may find duplicates.

The attacker can then try to reuse those keys against identical systems who are still using the key automatically generated at install time.

While the post-install startup sequence is the most vulnerable, most (all?) systems now store a seed in some file to be used early-on upon next reboot. This file is nothing special, just a random byte sequence designed to break any potential determinism in the early PRNG states.

So, nowadays, apart from material generated during the post-install phase, only code run before the seed has been loaded might still really show a vulnerability because it used /dev/urandom instead of /dev/random.