Headline
CVE-2023-0751
When GELI reads a key file from standard input, it does not reuse the key file to initialize multiple providers at once resulting in the second and subsequent devices silently using a NULL key as the user key file. If a user only uses a key file without a user passphrase, the master key is encrypted with an empty key file allowing trivial recovery of the master key.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-23:01.geli Security Advisory The FreeBSD Project Topic: GELI silently omits the keyfile if read from stdin Category: core Module: geli Announced: 2023-02-08 Credits: Nathan Dorfman Affects: All supported versions of FreeBSD. Corrected: 2023-02-08 18:03:19 UTC (stable/13, 13.1-STABLE) 2023-02-08 18:06:31 UTC (releng/13.1, 13.1-RELEASE-p6) 2023-02-08 18:05:45 UTC (stable/12, 12.4-STABLE) 2023-02-08 18:30:27 UTC (releng/12.4, 12.4-RELEASE-p1) 2023-02-08 18:28:31 UTC (releng/12.3, 12.3-RELEASE-p11) CVE Name: CVE-2023-0751 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background GELI is a block device-layer disk encryption utility. It uses a random master key to perform symmetric cryptography on sectors. The master key is encrypted using a user key, which might consist of up to two components: a user passphrase and a key file. The key file might be read from a file or a standard input. GELI also allows to initialization of multiple devices with a single command. II. Problem Description When GELI reads a key file from a standard input, it doesn’t store it anywhere. If the user tries to initialize multiple providers at once, for the second and subsequent devices the standard input stream will be already empty. In this case, GELI silently uses a NULL key as the user key file. If the user used only a key file without a user passphrase, the master key was encrypted with an empty key file. This might not be noticed if the devices were also decrypted in a batch operation. III. Impact Some GELI providers might be silently encrypted with a NULL key file. IV. Workaround On affected systems, instead of initializing GELI devices in a batch operation, the recommended way is to do this operation on a single provider. V. Solution If the system already has the device initialized with a null key, the master key has to be encrypted: echo -n | geli setkey -k- -p -K /path/to/keyfile -P /dev/provider Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date, and reboot. Perform one of the following: 1) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the amd64, i386, or (on FreeBSD 13 and later) arm64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install # shutdown -r +10min “Rebooting for a security update” 2) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-23:01/geli.patch # fetch https://security.FreeBSD.org/patches/SA-23:01/geli.patch.asc # gpg --verify geli.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details This issue is corrected by the corresponding Git commit hash or Subversion revision number in the following stable and release branches: Branch/path Hash Revision - ------------------------------------------------------------------------- stable/13/ 88bb08452ee3 stable/13-n254412 releng/13.1/ 98933c7013a5 releng/13.1-n250179 stable/12/ r372910 releng/12.4/ r372917 releng/12.3/ r372913 - ------------------------------------------------------------------------- For FreeBSD 13 and later: Run the following command to see which files were modified by a particular commit: # git show --stat Or visit the following URL, replacing NNNNNN with the hash: To determine the commit count in a working tree (for comparison against nNNNNNN in the table above), run: # git rev-list --count --first-parent HEAD For FreeBSD 12 and earlier: Run the following command to see which files were modified by a particular revision, replacing NNNNNN with the revision number: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEthUnfoEIffdcgYM7bljekB8AGu8FAmPj8B8ACgkQbljekB8A Gu8Q2g//WfBcATFcQsXQC/fO8oGa90pZl3+mBIBabMO7bMsZ3jzmsZM0DjEuztDM sOY6g9ExN5Fmh4O6Mvg12FjtsbJwp/4KxsrfjG3F8aTKjTKTdbBqhDodwQwCL9ZF u+qkNMrtdqFvigGqmCpKq6vC7kYx12NVFvr4X81kgBmwCOPUKlD351lnkQKv0C5B G3HeLdQb7stMRcnHWcqOw7m98aRSU0gE2/9BAMqfvtVWboa6LrdF6PQVav8Lq417 qh8Md71IAAWyFm8jcOtsX949KdtI1kcwDbVyuO5mT6TNFTuEu/lIx78/YpvGVZUt 1a7FAkiekr6c19xC01o6muc6E1XiwxO/vQMMwEsW9lv+N2fm4d7EGUP3nvFZTzgt OOKVORcqEsdZj92/UDdUXsIFV7fja0t7rGUXhI/YTAtnOvESTvDkUzfNQ3fxIMcG COFQdxJ0+P2oItMSeY2dlN8A/z41N6BqAilmg/LxuzZkCblC8q0JxLoAsAEydT4j RHA7dTwFNeM+6kVluERX302l6JGogg6mB+o/O+vqKWfDrvEzv7CLHEGnBT6lcAkX x1RQwXFd84fHwWXAffsUNKxrQe0QI+dbPcGH0YtHZntno1Azds3oVBAFa5nUcYVD 3A8ShP18hwkVLRyG9680fSD5cQwYKZpLuasujikLqnme/PkYDy4= =6d7v -----END PGP SIGNATURE-----