linux-kernel - Re: /dev/urandom uses uninit bytes, leaks user data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47699E82.5020503@tmr.com>
Date:	Wed, 19 Dec 2007 17:43:14 -0500
From:	Bill Davidsen <davidsen@....com>
To:	Theodore Tso <tytso@....edu>, David Newall <david@...idnewall.com>,
	Andy Lutomirski <luto@...ealbox.com>,
	John Reiser <jreiser@...Wagon.com>,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	security@...nel.org
Subject: Re: /dev/urandom uses uninit bytes, leaks user data

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@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/