FreeBSD 'bsdinstall' Lets Local Users Obtain the GEOM ELI Keyfile
SecurityTracker Alert ID: 1032042|
SecurityTracker URL: http://securitytracker.com/id/1032042
(Links to External Site)
Date: Apr 8 2015
Disclosure of authentication information|
A vulnerability was reported in FreeBSD 'bsdinstall'. A local user can obtain keys on the target system.|
The bsdinstall module uses insecure default GEOM ELI (GELI) keyfile permissions when configuring full disk ZFS encryption. A local user can obtain a copy of the GELI provider's key file.
Pierre Kim reported this vulnerability.
A local user can obtain the GELI keyfile.|
The vendor has issued a fix.|
[Editor's note: The vendor advises that the keyfile should be considered as compromised and that a new keyfile should be generated.]
Access control error|
Source Message Contents
Subject: FreeBSD Security Advisory FreeBSD-SA-15:08.bsdinstall|
-----BEGIN PGP SIGNED MESSAGE-----
FreeBSD-SA-15:08.bsdinstall Security Advisory
The FreeBSD Project
Topic: Insecure default GELI keyfile permissions
Credits: Pierre Kim
Affects: FreeBSD 10.1.
Corrected: 2015-04-07 20:20:24 UTC (stable/10, 10.1-STABLE)
2015-04-07 20:21:01 UTC (releng/10.1, 10.1-RELEASE-p9)
CVE Name: CVE-2015-1415
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/>.
The GEOM ELI class, or geli(8) implements encryption on GEOM providers which
supports various cryptographic encryption and authentication methods as
well as hardware acceleration. Each geli(8) provider has two key slots,
and each slot holds a copy of its master key encrypted by a keyfile and/or
a passphrase chosen by the system administrator.
The bsdinstall(8) installer is the default system installer of FreeBSD since
II. Problem Description
The default permission set by bsdinstall(8) installer when configuring full
disk encrypted ZFS is too open.
A local attacker may be able to get a copy of the geli(8) provider's
keyfile which is located at a fixed location.
Note well: due to the nature of this issue, there is no way to fix this
issue for already installed systems without human intervention. System
administrators are advised to assume that the keyfile have already been
leaked and a new keyfile is necessary.
The system administrator can create a new keyfile with the correct
permissions, and change the key slot that holds the master key encrypted
with the old keyfile.
For example, if the GELI provider is /dev/ada0, the system administrator
can do the following:
# umask 077
# dd if=/dev/random of=/boot/encryption.key.new bs=4096 count=1
# umask 022
# geli setkey -K /boot/encryption.key.new /dev/ada0p3
Enter new passphrase:
Reenter new passphrase:
(Repeat the geli setkey command if multiple providers are used)
# mv /boot/encryption.key.new /boot/encryption.key
# ls -l /boot/encryption.key
Make sure that the new /boot/encryption.key can only be read by root.
The FreeBSD stable and security branch (releng) and the changes are mainly
intended for system integrators who build their own installation image for
V. Correction details
The following list contains the correction revision numbers for each
To see which files were modified by a particular revision, run the
following command, replacing NNNNNN with the revision number, on a
machine with Subversion installed:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
The latest revision of this advisory is available at
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.2 (FreeBSD)
-----END PGP SIGNATURE-----
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"