Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
Simon L. B. Nielsen si...@freebsd.org wrote: On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein u...@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 signature.asc Description: PGP signature
Re: [HEADSUP] geli(4) weak master key generation on -CURRENT
On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein u...@freebsd.org 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 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. 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
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 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. 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
[HEADSUP] geli(4) weak master key generation on -CURRENT
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 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. 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. -- Simon L. B. Nielsen FreeBSD Security Officer signature.asc Description: OpenPGP digital signature