From owner-freebsd-security@FreeBSD.ORG Mon Nov 24 23:30:46 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9942F1065670 for ; Mon, 24 Nov 2008 23:30:46 +0000 (UTC) (envelope-from fbsd06+37=ab02fec6@mlists.homeunix.com) Received: from fallback-in1.mxes.net (fallback-out1.mxes.net [216.86.168.190]) by mx1.freebsd.org (Postfix) with ESMTP id 69D7F8FC0C for ; Mon, 24 Nov 2008 23:30:46 +0000 (UTC) (envelope-from fbsd06+37=ab02fec6@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by fallback-in1.mxes.net (Postfix) with ESMTP id 290161648E2 for ; Mon, 24 Nov 2008 18:14:39 -0500 (EST) Received: from gumby.homeunix.com (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 7CAD723E3F7 for ; Mon, 24 Nov 2008 18:14:37 -0500 (EST) Date: Mon, 24 Nov 2008 23:14:35 +0000 From: Robert Woolley To: freebsd-security@freebsd.org Message-ID: <20081124231435.326fadc4@gumby.homeunix.com> In-Reply-To: References: <200811241747.mAOHlDSE034716@freefall.freebsd.org> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-08:11.arc4random X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 23:30:46 -0000 On Mon, 24 Nov 2008 10:07:18 -0800 (PST) Nate Eldredge 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.