mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Theodore Tso" <tytso@mit.edu>,
	"John Reiser" <jreiser@BitWagon.com>,
	"Matt Mackall" <mpm@selenic.com>, <linux-kernel@vger.kernel.org>,
	<security@kernel.org>
Subject: RE: /dev/urandom uses uninit bytes, leaks user data
Date: Mon, 17 Dec 2007 21:12:56 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKOEPIIOAC.davids@webmaster.com> (raw)
In-Reply-To: <476719E5.1010505@myrealbox.com>


> Has anyone *proven* that using uninitialized data this way is safe?

You can probably find dozens of things in the Linux kernel that have not
been proven to be safe. That means nothing.

> As
> a *user* of this stuff, I'm *very* hesitant to trust Linux's RNG when I
> hear things like this.  (Hint: most protocols are considered insecure
> until proven otherwise, not the other way around.)

There's no reason whatsoever to think this is unsafe. First, you can't
access the pool directly. Second, even if you could, it's mixed in securely.

> Now imagine a security program.  It runs some forward secret protocol
> and it's very safe not to leak data that would break forward secrecy
> (mlockall, memset when done with stuff, etc).  It runs on a freshly
> booted machine (no DSA involved, so we're not automatically hosed), so
> an attacker knows the initial pool state.  Conveniently, some *secret*
> (say an ephemeral key, or, worse, a password) gets mixed in to the pool.
>   There are apparently at most three bytes of extra data mixed in, but
> suppose the attacker knows add the words that were supposed to get mixed
> in.  Now the program clears all its state to "ensure" forward secrecy,
> and *then* the machine gets hacked.  Now the attacker can learn (with at
> most 2^24 guesses worth of computation) 24 bits worth of a secret, which
> could quite easily reduce the work involved in breaking whatever forward
> secret protocol was involved from intractable to somewhat easy.  Or it
> could leak three bytes of password.  Or whatever.

This is no more precise than "imagine there's some vulnerability in the
RNG". Yes, if there's a vulnerability, then we're vulnerable.

An attacker can always (at least in principle) get the pool out of the
kernel. The RNG's design is premised on the notion that it is
computationally infeasbile to get the input entropy out of the pool. If an
attacker can watch data going into the pool, he needn't get it out of the
pool.

> Sorry for the somewhat inflammatory email, but this is absurd.

I agree.

DS



  parent reply	other threads:[~2007-12-18  5:13 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-14 19:34 John Reiser
2007-12-14 20:13 ` Matt Mackall
2007-12-14 20:45   ` John Reiser
2007-12-14 23:23     ` Theodore Tso
2007-12-15  0:30       ` John Reiser
2007-12-15  4:32         ` Theodore Tso
2007-12-17 16:30           ` John Reiser
2007-12-17 17:36             ` Theodore Tso
2007-12-18  0:52               ` Andy Lutomirski
2007-12-18  3:05                 ` Theodore Tso
2007-12-18  3:13                   ` David Newall
2007-12-18  3:46                     ` Theodore Tso
2007-12-18  4:09                       ` David Newall
2007-12-18  4:23                         ` Theodore Tso
2007-12-19 22:43                           ` Bill Davidsen
2007-12-19 22:40                         ` Bill Davidsen
2007-12-20  4:18                       ` Andrew Lutomirski
2007-12-20 20:17                         ` Phillip Susi
2007-12-21 16:10                           ` Andrew Lutomirski
2007-12-22  1:14                             ` Theodore Tso
2007-12-26 18:30                             ` Phillip Susi
2007-12-20 20:36                         ` Theodore Tso
2007-12-27 10:44                           ` Pavel Machek
2007-12-18  5:12                 ` David Schwartz [this message]
2007-12-17 20:59             ` David Schwartz
2007-12-15  7:13         ` Herbert Xu
2007-12-15 16:30           ` Matt Mackall
2007-12-17 17:28           ` Signed divides vs shifts (Re: [Security] /dev/urandom uses uninit bytes, leaks user data) Linus Torvalds
2007-12-17 17:48             ` Al Viro
2007-12-17 17:55             ` Eric Dumazet
2007-12-17 18:05               ` Ray Lee
2007-12-17 18:10                 ` Eric Dumazet
2007-12-17 18:12                   ` Ray Lee
2007-12-17 18:23               ` Al Viro
2007-12-17 18:28               ` [Security] Signed divides vs shifts (Re: " Linus Torvalds
2007-12-17 19:08                 ` Al Viro
2007-12-15  7:20 /dev/urandom uses uninit bytes, leaks user data Matti Linnanvuori
2007-12-15  7:54 ` Valdis.Kletnieks
2007-12-15 22:44 linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MDEHLPKNGKAHNMBLJOLKOEPIIOAC.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=jreiser@BitWagon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=security@kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome