Compromising /dev/random

#!/bin/sh
rm /dev/random
mknod /dev/random c 1 5

You can't trust the random number generator on any system you don't control. The above script deletes /dev/random and then recreates it - but instead of using the device numbers for a character device that outputs random data from the entropy pool (1,8) it uses the numbers for a device that spits out nothing but zero (1,5). So when you think you are generating a 4096 bit secure key using genuine random data, you are just getting four thousand zeros. And even if your software checks for something like this, there are more sophisticated ways to generate random looking data that isn't.

While this doesn't matter at all to the most users, it's a potentially major problem for anyone that relies on encryption for security. The moral of the story - secure communications requires a lot more than using a very large key.

Baron_Saturday's writeup in this node, suggesting one could simply replace /dev/random with /dev/zero, while technically totally true, is missing a very important point.

Nobody can delete /dev/random, or make a new device node, except for the root user. If someone who is already root on your machine is attempting to compromise your crypto, they are probably not going to do it by messing with your RNG (if they're smart, anyway). What they will do is recompile your application to dump plaintext, secret keys, and other interesting values into /tmp. Or they will modify it at run time, using a debugger (hey, they're root. They can do that kind of thing). Or they will just read your process' memory directly, through /proc.

A quote from Baron_Saturday's writeup: "You can't trust the random number generator on any system you don't control." Very true. You also can't trust the CPU, the memory, the programs you are executing, the shared libraries those programs are linked with, anything at all; in short, if you don't have exclusive control of the system (and you never have a guarantee that you do have exclusive control of the system, especially on Unix), nothing is safe. Either you have to a) trust people, or b) go live in a cave somewhere.

This is just how Unix security works. If you don't trust the root user on the system, then you can't trust the system at all. If this is a problem for you, instead consider a capability-secure system like CapROS or L4Ka.