[Bug 1835095] Re: Lubuntu initrd images leaking cryptographic secret when disk encryption is used

[Launchpad Bug Tracker]

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

** Changed in: initramfs-tools (Ubuntu)
       Status: New => Confirmed

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

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

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in lubuntu-meta package in Ubuntu:
  New

Bug description:
  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?

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