From: Matti Linnanvuori <[email protected]>
/dev/urandom use no uninit bytes, leak no user data
Signed-off-by: Matti Linnanvuori <[email protected]>
---
--- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
+++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
@@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
*/
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
+ static __u32 tmp[OUTPUT_POOL_WORDS];
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
On Fri, 14 Dec 2007 23:20:30 PST, Matti Linnanvuori said:
> From: Matti Linnanvuori <[email protected]>
>
> /dev/urandom use no uninit bytes, leak no user data
>
> Signed-off-by: Matti Linnanvuori <[email protected]>
>
> ---
>
> --- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
> +++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
> @@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
> */
> static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
> {
> - __u32 tmp[OUTPUT_POOL_WORDS];
> + static __u32 tmp[OUTPUT_POOL_WORDS];
This looks like a race waiting to happen - what lock is held so we don't have
'tmp' smashed by 2 instances on different CPUs (not a problem when each
instance lives on a hopefully separate stack)?
>> There is a path that goes from user data into the pool. This path
>> is subject to manipulation by an attacker, for both reading and
>> writing. Are you going to guarantee that in five years nobody
>> will discover a way to take advantage of it? Five years ago
>> there were no public attacks against MD5 except brute force;
>> now MD5 is on the "weak" list.
> Yep, I'm confident about making such a guarantee. Very confident.
For the writing side, there's a far easier way to inject potentially
hostile data into the /dev/random pool:
"echo evil inentions > /dev/random".
This is allowed because it's a very specific design goal that an attacker
cannot improve their knowledge of the state of the pool by feeding in
chosen text.
Which in turn allows /dev/random to get potential entropy from lots of
sources without worrying about how good they are. It tries to account
for entropy it's sure of, but it actually imports far more - it just
don't know how much more.
One of those "allowed, but uncredited" sources is whatever you want to
write to /dev/random.
So you can, if you like, get seed material using
wget -t1 -q --no-cache -O /dev/random 'http://www.fourmilab.ch/cgi-bin/Hotbits?fmt=bin&nbytes=32' 'http://www.random.org/cgi-bin/randbyte?nbytes=32&format=f' 'http://www.randomnumbers.info/cgibin/wqrng.cgi?limit=255&amount=32' 'http://www.lavarnd.org/cgi-bin/randdist.cgi?pick_num=16&max_num=65536'
I don't trust them, but IF the data is actually random, and IF it's not
observed in transit, then that's four nice 256-bit random seeds.
(Note: if you actually use the above, be very careful not to abuse these
free services by doing it too often. Also, the latter two actually
return whole HTML pages with the numbers included in ASCII. If anyone
knows how to just download raw binary, please share.)