From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 19:03:56 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EA023F2 for ; Sat, 19 Jul 2014 19:03:56 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E09AD250B for ; Sat, 19 Jul 2014 19:03:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6JJ3m6r004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 12:03:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6JJ3mW7004475; Sat, 19 Jul 2014 12:03:48 -0700 (PDT) (envelope-from jmg) Date: Sat, 19 Jul 2014 12:03:48 -0700 From: John-Mark Gurney To: Steven Chamberlain Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719190348.GM45513@funkthat.com> Mail-Followup-To: Steven Chamberlain , freebsd-security@freebsd.org References: <53C85F42.1000704@pyro.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C85F42.1000704@pyro.eu.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 19 Jul 2014 12:03:49 -0700 (PDT) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 19:03:56 -0000 Steven Chamberlain wrote this message on Fri, Jul 18, 2014 at 00:41 +0100: > FreeBSD is as far as I know, quite unique in using Yarrow to provide a > nice, fast CSPRNG for /dev/urandom > > But OpenSSL, LibreSSL, OpenSSH, and various reimplementations of > arc4random(), don't directly use it. They typically take only ~128 bits > from /dev/urandom or through other means, to seed a stream cipher, then > return the output of that. I understand why Linux, even OpenBSD must do > that. Good-quality random bits from the kernel are scarce, so they > *must* be stretched somehow. > > But isn't that essentially what Yarrow does already in FreeBSD? > > Is there a good reason arc4random_buf() can't take bytes directly from > /dev/urandom or sysctl KERN_ARND? Therefore no longer needing to seed > first, periodically reseed, or use any stream cipher? Wow, am I really seeing this right, that kern.arc4rand doesn't use the same interface that /dev/random/ uses? And there isn't a sysctl interface to /dev/random? This really needs to b e fixed... > There are a few reasons I mention it now: > > * arc4random relies on the stream cipher being cryptographically strong > between reseeds, or else you could guess previous/later output. FreeBSD > still uses RC4 for arc4random, and that seems increasingly risky; > OpenBSD moved recently to ChaCha-20, but who knows if even that will > prove to be safe in the longer term? We should move arc4random to just using the same interface as /dev/random, or, if you're talking about arc4random(3), we should just convert arc4random(3) to using the sysctl... Though this introduces a standard problem... People are using an implementation (arc4random) instead of a generic give me x interface, though it looks like there isn't a way to directly seed the arc4random pool, so hopefully people are expecting to use this to get reproducable random numbers (for testing)... > * after seeding, some arc4random implementations completely forget to > reseed after the process forks - the same 'random' stream of bytes could > occur twice, with security implications > > * LibreSSL tried to detect forking, and to reseed automatically, but > Andrew Ayer showed a corner-case where that still didn't work as > expected (CVE-2014-2970) > > * some arc4random implementations might not be thread-safe > > * (re)seeding can fail sometimes (fd's exhausted reading /dev/urandom, > or that is missing in a chroot; even a sysctl might return an error > code); OpenSSL and LibreSSL each have 'scary' ways to try to gather > entropy in userland as a fallback, especially for Linux; FreeBSD and > OpenBSD may have better expectations that the sysctl will work, and > maybe raise SIGKILL otherwise Yes, if there is an error from the sysctl or something, the process should abort or something similar... > So I wonder, could a simplified arc4random for FreeBSD use Yarrow > directly, to avoid making any of these sorts of mistakes we've seen? I assume you mean convert arc4random(3) to use the sysctl, or? > (There's also the benefit that having many readers from a single > pseudorandom stream, adds an additional kind of randomness to its output). Per other person's comment, this shouldn't matter if you have a good PRNG... > This is obviously a complex issue, and some of it will be subjective. > But I welcome your comments. Thanks! So, my suggestions: 1) Convert arc4random(9) in the kernel to use the random pool as /dev/random uses. I vaguely remeber there being an issue w/ arc4random(9) being used early in boot before /dev/random is initalized which would complicate this change... 2) Convert arc4random(3) to use the sysctl, and if the sysctl fails, kill the process. There are also some other improvements that can be made to the /dev/random frame work, but those are more code cleanup, not security related changes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."