Home / mailings FreeBSD Security Advisory FreeBSD-SA-23:01.geli
Posted on 08 February 2023
FreeBSD security notificat=============================================================================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 <ndorf@rtfm.net>
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 <URL:https://security.FreeBSD.org/>.
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
<URL:https://www.FreeBSD.org/handbook/kernelconfig.html> 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 <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>
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:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
VII. References
<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0751>
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-23:01.geli.asc>
