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 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: 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
