Public bug reported:

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?

** Affects: initramfs-tools (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: encryption initramfs-tools leak secret

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1835095

Title:
  Lubuntu initrd images leaking cryptographic secret when disk
  encryption is used

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835095/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to