Lubuntu initrd images leaking cryptographic secret when disk encryption is used

[Plecton]

Hello!

I've had a short discussion about this issue on lubuntu irc, and I was asked to open a bug report. Basically I only tested this on lubuntu 19.04 x64 live image on a UEFI system, I haven't tested other ubuntu flavors.

Anyway, I was poking around with disk encryption, and I noticed that lubuntu live image uses a graphical installation tool called Calamares. This tool has an option to encrypt the hard disk during installation, and the encryption setup that is used is the newer one with /boot folder as part of the encrypted rootfs. Traditionally the installers used to setup encryption where there is a main LUKS-encrypted rootfs volume on the HDD and a separate unencrypted /boot partition where the grub config files, the kernel and the initrd images reside. Ever since grub2 added support for LUKS several distros have apparently moved to the newer scheme which is very similar to the one that was first described by Pavel Kogan in his blog.

A) https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
B) https://www.pavelkogan.com/2015/01/25/linux-mint-encryption/

This new scheme stores the rootfs (including the /boot folder) on a single LUKS-encrypted partition with two keyslots in use. One of the keyslots is normally a passphrase that is used in the first stage by the grub2 EFI image as pre-boot authentication. It serves to decrypt the rootfs, access the contents of /boot and copy the config, kernel and initrd image to RAM. Once done, grub2 then forgets the passphrase and closes the encrypted volume. The system will continue to boot, but at this point the rootfs will now have to be decrypted a second time - this time by the kernel/initrd so it can be mounted. Normally this is the point where the user would be asked to enter a passphrase for the second time, but for convenience reasons (to automate the process) a second LUKS keyslot and a keyfile are used instead.

The file /crypto_keyfile.bin is generated during the installation phase. This is the secret keyfile that is used to unlock the other LUKS keyslot and decrypt the rootfs. It is properly protected with owner set to root:root and file permissions 600 (-rw-------). Unfortunately the key is not of much use while it resides inside the encrypted volume that it is supposed to decrypt. This is where initramfs-tools comes into play. I believe there is a special hook inside /usr/share/initramfs-tools/hooks that is responsible for copying this crypto_keyfile.bin file into appropriate initrd image. This image that now contains the secret keyfile is copied into RAM during the first decryption stage by the grub2.

While the original secret keyfile /crypto_keyfile.bin is protected:

$ ls -l /
...
-rw------- 1 root root 2048 jul 2 18:34 crypto_keyfile.bin
...
$ sha1sum /crypto_keyfile.bin
sha1sum: /crypto_keyfille.bin: Permission denied
$ sudo sha1sum /crypto_keyfile.bin
7a1c44fd036510cc02e32c094bd16b4a76a7f14c /crypto_keyfile.bin

The second copy (the one inside initramfs image) is not:

$ ls -l /boot
...
-rw-r--r-- 1 root root 68149041 jul 2 18:35 initrd.img-5.0.0-13-generic

As you can see, the initramfs images that are generated by mkinitramfs will have the user:group set to root:root, but their access flags will be 644 (-rw-r--r--). This means that any user or even a script that has read access to the file system can read and extract the secret keyfile from an initramfs image.

Run as user:
$ unmkinitramfs /boot/initrd.img-5.0.0-13-generic /tmp
$ sha1sum /tmp/main/crypto_keyfile.bin
7a1c44fd036510cc02e32c094bd16b4a76a7f14c /tmp/main/crypto_keyfile.bin

Would there be any adverse effects, if we were to set mkinitramfs (i.e. via a hook) to always set file permissions of initramfs images to 600 whenever this type of disk encryption is used?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tom Reynolds (tomreyn)]

On 18.04, package cryptsetup provides /etc/cryptsetup-initramfs/conf-hook which states:

# WARNING: If the initramfs image is to include private key material,
# you'll want to create it with a restrictive umask in order to keep
# non-privileged users at bay. For instance, set UMASK=0077 in
# /etc/initramfs-tools/initramfs.conf

Note that there is also /etc/initramfs-tools/conf.d/

[Thomas Ward (teward)]

The following CVE IDs have been issued for Calamares in this instance by MITRE, IDs were requested via the CVE form:

CVE-2019-13178 was assigned for the race condition that Seth Arnold identified in https://github.com/calamares/calamares/issues/1190 regarding unsafe UMask and file permissions during creation of the keyfile.

CVE-2019-13179 was assigned for the improper handling of the LUKS encryption keyfile from /crypto_keyfile.bin to /boot in a globally readable initramfs issue for which upstream issue https://github.com/calamares/calamares/issues/1191 was created.

[Launchpad Janitor (janitor)]

This bug was fixed in the package calamares - 3.2.11-0ubuntu1

---------------
calamares (3.2.11-0ubuntu1) eoan; urgency=medium

  * New upstream release.
  * Proper handling of files and permissions with FDE: (LP: #1835095)
    - CVE-2019-13178 Set proper umask for luks crypto_keyfile.
    - CVE-2019-13179 Set proper umask for initramfs.
  * Bump Standards-version to 4.4.0, no changes needed.

 -- Dan Simmons <email address hidden> Fri, 12 Jul 2019 19:52:38 -0400