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
Touch seeded packages, 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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
