From owner-freebsd-security@FreeBSD.ORG Sat Aug 25 20:43:28 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEE61106564A; Sat, 25 Aug 2012 20:43:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF098FC12; Sat, 25 Aug 2012 20:43:27 +0000 (UTC) Received: from [78.35.178.199] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T5NCS-0005Zi-Mb; Sat, 25 Aug 2012 22:43:20 +0200 Date: Sat, 25 Aug 2012 22:33:31 +0200 From: Fabian Keil To: freebsd-security@freebsd.org Message-ID: <20120825223331.39d56334@fabiankeil.de> In-Reply-To: References: <5032AB28.9070306@FreeBSD.org> <20120821120537.GL1202@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ddw_HLgqahnHezVLZtNCKE1"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] geli(4) weak master key generation on -CURRENT 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: Sat, 25 Aug 2012 20:43:28 -0000 --Sig_/ddw_HLgqahnHezVLZtNCKE1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "Simon L. B. Nielsen" wrote: > On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Sp=F6rlein wrot= e: > > On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: > >> -CURRENT users of geli(4) should be advised that, a geli(4) device may > >> have weak master key, if the provider is created on -CURRENT system > >> built against source code between r238116 (Jul 4 17:54:17 2012 UTC) > >> and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). > >> > >> One can verify if its provider was created with weak keys by running: > >> > >> # geli dump | grep version > >> > >> If the version is 7 and the system did not include this fix (r239184) > >> when provider was initialized, then the data has to be backed up, > >> underlying provider overwritten with random data, system upgraded and > >> provider recreated. > > I haven't read commit mails in a very long time, but is there code in > > place that will issue a warning upon geli attach if version 7 is > > detected? While -CURRENT is not supported, there might be a lot of disks > > initialized with version 7 and they'll eventually be upgraded to > > 10.0-RELEASE (the OS, not necessarily the geli volumes). >=20 > No, the bad code was only in head for about a month. I'm fine with > having a warning, but somebody has to code it. The weak keys weren't stored on disk, but generated at attach-time. A patched kernel will generate different keys which means it shouldn't be backwards compatible to a vulnerable kernel as far as reading and writing geli version 7 is concerned. If a user doesn't follow the recommended mitigation steps and simply updates the kernel without migrating the data first, he shouldn't be able to read the encrypted data written with the previous kernel version, which I consider kinda hard to miss. I believe if there really were "a lot of disks" initialized with affected kernels, there would have been at least a couple of complaints on the mailing lists already. Fabian --Sig_/ddw_HLgqahnHezVLZtNCKE1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA5Np4ACgkQBYqIVf93VJ0EpgCfY9jr+hFBRWn1UAMK4x86b5Km nUoAoL8GHxYkNumdBjHTCgZ/tgYJStvz =xTKj -----END PGP SIGNATURE----- --Sig_/ddw_HLgqahnHezVLZtNCKE1--