From: Bill Davidsen <davidsen@tmr.com>
To: Theodore Tso <tytso@mit.edu>,
David Newall <david@davidnewall.com>,
Andy Lutomirski <luto@myrealbox.com>,
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: Wed, 19 Dec 2007 17:43:14 -0500 [thread overview]
Message-ID: <47699E82.5020503@tmr.com> (raw)
In-Reply-To: <20071218042337.GT7070@thunk.org>
Theodore Tso wrote:
> On Tue, Dec 18, 2007 at 02:39:00PM +1030, David Newall wrote:
>> Thus, the entropy saved at shutdown can be known at boot-time. (You can
>> examine the saved entropy on disk.)
>>
>
> If you can examine the saved entropy on disk, you can also introduce a
> trojan horse kernel that logs all keystrokes and all generated entropy
> to the FBI carnivore server --- you can replace the gpg binary with
> one which ships copies of the session keys to the CIA --- and you can
> replace the freeswan server with one which generates emphermal keys by
> encrypting the current timestamp with a key known only by the NSA. So
> if the attacker has access to your disk between shutdown and boot up,
> you are *done*. /dev/random is the least of your worries.
>
> Really, why is it that people are so enamored about proposing these
> totally bogus scenarios? Yes, if you have direct physical access to
> your machine, you can compromise it. But there are far easier ways
> that such a vulnerability can be exploited, rather than making it easy
> to carry out an cryptoanalytic attack on /dev/random.
>
> (And yes, after using the saved state to load the entropy at
> boot-time, the saved state file is overwritten, and if you're
> paranoid, you can scrub the disk after it is read and mixed into the
> entropy pool. And yes, the saved state is *not* the entropy pool used
> during the previous boot, but entropy extracted using SHA-1 based
> CRNG.)
>
>>> If you have a server, the best thing you can do is use a hardware
>>> random number generator, if it exists. Fortunately a number of
>>> hardware platforms, such as IBM blades and Thinkpads, come with TPM
>>> modules that include hardware RNG's. That's ultimately the best way
>>> to solve these issues.
>> Just how random are they? Do they turn out to be quite predictable if
>> you're IBM?
>
> They use a noise diode, so they are as good as any other hardware
> random number generator. Of course, you ultimately have to trust the
> supplier of your hardware not to do something screwy, and Thinkpads
> are now made by Lenovo, which has caused some US Government types to
> get paranoid --- but that's why the best way to do things is to get
> entropy from as many places as possible, and mix it all into
> /dev/random. If any one of them is unknown to the attacker, he's stuck.
>
In another thread I believe I mentioned things an attacker can't know
(unless your system is already compromised) like fan speed, CPU
temperature, etc.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
next prev parent reply other threads:[~2007-12-19 22:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 19:34 /dev/urandom uses uninit bytes, leaks user data 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 [this message]
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
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
-- strict thread matches above, loose matches on Subject: below --
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=47699E82.5020503@tmr.com \
--to=davidsen@tmr.com \
--cc=david@davidnewall.com \
--cc=jreiser@BitWagon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@myrealbox.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.