Messages in this thread | | | Date | Thu, 27 Dec 2007 10:44:14 +0000 | From | Pavel Machek <> | Subject | Re: /dev/urandom uses uninit bytes, leaks user data |
| |
On Thu 2007-12-20 15:36:01, Theodore Tso wrote: > On Wed, Dec 19, 2007 at 11:18:54PM -0500, Andrew Lutomirski wrote: > > I understand that there's no way that /dev/random can provide good > > output if there's insufficient entropy. But it still shouldn't leak > > arbitrary bits of user data that were never meant to be put into the > > pool at all. > > Let's be clear here. It's not arbitrary bits of user data. It's at > most three bytes of kernel stack garbage from the process which is > adding entropy to /dev/random from userspace. And the attacker > doesn't get to pick which 3 bytes they are, either! That means they > are not "arbitrary bits". > > > (My hypothetical attack is a lot hypothetical than I thought at first. > > An attacker does not need to break into the kernel and steal the > > state of the pool. It may be as easy as this to trigger: > > > > Step 1: Boot a system without a usable entropy source. > > Step 2: add some (predictable) "entropy" from userspace which isn't a > > multiple of 4, so up to three extra bytes get added. > > Step 3: Read a few bytes of /dev/random and send them over the network. > > So Step 1 assumes a system without a random seed file, or any usable > entropy source. As I've mentioned, this means that any cryptographic > users of /dev/random --- like, say, openssh daemon --- are in deep, > DEEP, trouble. This is a very serious problem, and in my opinion, far > more serious and far more REAL that your hypothetical attack. So we > need to address Step 1 anyway, and more urgently. > > In step 2, what program are you expecting will be writing to > /dev/random? Very few programs do so today, and none that are > commonly installed on most Linux distributions, other than the dd > program run out of /etc/init.d/random to initialize /dev/random from > the random seed file. But, oh wait --- you're assuming that doesn't > exist, even though all major distributions have it. > > Why would a legitimate program read a few bytes of /dev/random and > send them on the network in step 3? Or are you assuming your > hypothetical attacker has a shell account on the system? In which > case there is probably far more concerns about information leakage > than 3 bytes of kernel stack garbage, which might or might not contain > user data. > > And note that this attack can only be done for 3 bytes. After that, > the work factors involved become intractable. > > So yes, there is a theoretical hole given your assumptions, but the > problem started the "system without any intial entropy", and there are > far worse problems that result in that case. So that is the problem > we should be addressing. > > That being said, write_pool() is hardly a fastpath, and the memset > isn't going to make any difference. So if it makes people feel > better, I don't object to adding it. I'm just pointing out that the > assumption is either pretty silly (since all of the distributions do > use the random seed file, and in practice *someone* has logged into > the console to add some amount of entropy at some point in the > machine's lifetime, even it if was when the machine was initially > installed) and/or points out a more critical issue, which is we need > to make sure that we do have a reasonable entropy source on all > machines.
Lets memset. It is not a fastpath, and code will be more obvious that way.
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |