3

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?

  • I can't answer the question, but actually I'd assume the opposite would be the case, if anything. An interesting read for you to clear up some misconceptions: 2uo.de/myths-about-urandom – Ben Jan 13 '17 at 4:25
  • 1
    That question probably doesn't make much sense as /dev/random and /dev/urandom have had different implementations at different times and for different OSes. – Arminius Jan 13 '17 at 4:43
  • @Arminius your objection would only make sense if you assume that information would not be provided in a vulnerability report. Seems like the sort of stuff that should be. – candied_orange Jan 13 '17 at 4:56
3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.