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 for Android: free password hash cracker in your pocket

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

Message-ID: <20071222011400.GE8601@thunk.org>
Date:	Fri, 21 Dec 2007 20:14:00 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andrew Lutomirski <luto@...ealbox.com>
Cc:	Phillip Susi <psusi@....rr.com>,
	David Newall <david@...idnewall.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

On Fri, Dec 21, 2007 at 11:10:36AM -0500, Andrew Lutomirski wrote:
> > > 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.
> >
> > Only root can do 1 and 2, at which point, it's already game over.
> 
> Again, no.  Root could do this accidentally.  Step 1 happens all the
> time (see the comments on non-unique UUIDs).  

Actually, it doesn't happen *all* the time.  That was a situation of
an rpm post-install script trying to use a random UUID generation
facility from a kick-start install where there was no keyboard
activity and apparently no other entropy added.  (Note that in such an
environment, generation of host ssh keys at install time without any
entropy is an even bigger problem, and that *is* something that people
should be thinking about.)

> Step 2 just requires a
> program to put data which it things is OK to go into the pool next to
> data that shouldn't be there in memory.  

Um, no, that's incorrect.  Simply putting data which is OK to put into
the pool next to data that shouldn't isn't enough.  First of all, the
issue is using unitialized kernel stack garbage.  Read that again,
slowly --- kernel stack.  How you arrange your data in user memory
doesn't matter.  Secondly, as I've said earlier, I'm not aware of any
program that actually tries to write into the entropy pool on most
modern Linux systems other than dd in /etc/init.d/random which
initializes the random pool from pre-seeded entropy on disk. 

    	       	    	 	    	    - Ted
--
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/