Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: > Hello, > > If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely > ignore this mail. If you are, please read on! > > -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. > > Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for > fixing it, and Xin Li for drafting this text. > > PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't > supported by the FreeBSD Security Team, we are not releasing an > advisory, just this heads up. 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). Thanks Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein wrote: > On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: >> Hello, >> >> If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely >> ignore this mail. If you are, please read on! >> >> -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. >> >> Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for >> fixing it, and Xin Li for drafting this text. >> >> PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't >> supported by the FreeBSD Security Team, we are not releasing an >> advisory, just this heads up. > > 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. -- Simon L. B. Nielsen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
"Simon L. B. Nielsen" wrote: > On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein 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 | 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 signature.asc Description: PGP signature
