Date: Mon, 24 Nov 2008 23:14:35 +0000 From: Robert Woolley <fbsd06@mlists.homeunix.com> To: freebsd-security@freebsd.org Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random Message-ID: <20081124231435.326fadc4@gumby.homeunix.com> In-Reply-To: <Pine.GSO.4.64.0811241001430.1597@zeno.ucsd.edu> References: <200811241747.mAOHlDSE034716@freefall.freebsd.org> <Pine.GSO.4.64.0811241001430.1597@zeno.ucsd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Nov 2008 10:07:18 -0800 (PST) Nate Eldredge <neldredge@math.ucsd.edu> wrote: > Upon reading this, my first question was whether the weakness applies > to the random numbers supplied by /dev/random. If it does, then > userspace has been getting non-random values, and things like PGP and > SSH keys could be compromised. It might be good for secteam to > clarify this, IMHO. I'm not from secteam, but I did submit the problem and suggest the solution. The primary problem is that the kernel version of arc4random is seeded from yarrow before yarrow itself is seeded. This does not affect /dev/random or userland arc4random, just the things mentioned in the advisory. However, there is a second problem that is fixed by the patch, but not documented in the advisory. Closing a write to /dev/random causes a yarrow reseed, but previously didn't flush the entropy queue first. The first 4kB of low-grade entropy that's fed into /dev/random before the entropy file causes the queue to saturate, leaving no space for the entropy file, which is tail-dropped. And without a flush any entropy in the queues isn't processed into the yarrow key until another reseed occurs, at which point it's redundant anyway. In short, the primary entropy file didn't previously do anything useful. Whether that's actually a problem isn't clear to me. On my desktop machine yarrow reseeds by itself before the entropy file is used, due to disk activity. There may however be some platforms where the entropy file is really needed, and /dev/random itself may have been a bit insecure until the stage in the boot process where /var is mounted and the secondary entropy files in /var/db/entropy/ are used. PGP and SSH keys are generated late in the boot process, or after boot, usually on machines with plenty of entropy, so there shouldn't be an issue there.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081124231435.326fadc4>