Messages in this thread | | | Date | Wed, 19 Dec 2007 23:18:54 -0500 | From | "Andrew Lutomirski" <> | Subject | Re: /dev/urandom uses uninit bytes, leaks user data |
| |
On Dec 17, 2007 10:46 PM, Theodore Tso <tytso@mit.edu> wrote: > If you have a system with insufficent entropy inputs, you're in > trouble, of course. There are "catastrophic reseeds" that attempt to > mitigrate some of worse attacks, but at the end of the day, > /dev/random isn't magic. >
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.
(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.
An attacker can now try all possibilities of the three extra bytes and guess them pretty quickly. No compromise needed. This is, IMHO, bad. (It's one thing for the "random" numbers to be weak. It's another thing entirely for them to reveal data that never belonged in the pool in the first place.)
Actually, perhaps there should be a policy that we try never to reseed the pool at all until there is enough entropy around to prevent attacks like these. (In theory the state of the pool might contain 2^(smallish number) bits of data interesting to the attacker even without the uninitialized data issue.) This would make the situation even worse for low-entropy systems, though.
--Andy
| |