Re: [HEADSUP] geli(4) weak master key generation on -CURRENT

"Simon L. B. Nielsen" <simon_at_FreeBSD.org> wrote:

> On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein <uqs_at_freebsd.org> wrote:
> > 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 <provider> | 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).
> 
> 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