1. 2

  2. 6

    Wtf? How is this an exploit?

    The default behavior is to drop to an initramfs recovery shell if / can’t be mounted. If you have an encrypted root partition/volume, and you don’t provide the password, then you get the shell. It is an extremely limited environment where none of the filesystems are mounted (and if they’re all encrypted then they can’t be mounted without a valid passphrase/keyfile). Additionally, you can control what functionality initramfs or dracut has when building it. If you’re truly paranoid you can make it very minimal with no network abilities.

    Also if you exclusively use keyfiles on external media (no LUKS keyslots hold a passphrase) then there is no prompt and initramfs just waits without saying anything until the keyfile device becomes available. In this mode I haven’t figured out how to break out to the recovery shell. It’s a very nice mechanism to have a system appear hung/idle until the moment the keyfile device becomes available.

    I can’t believe this gets a CVE.

    1. 7

      Mismatch between expectations and reality. People may (quite reasonably imo) assume that in a kiosk like environment, an encrypted disk implies the computer can’t be used.

      1. [Comment removed by author]

        1. 1

          Yes, but you can configure Grub to disallow command line editing without password.

          If you have a BIOS password to enter setup, a password in the boot loader to prevent command line editing (neither needed for normal boot-up) and have a encrypted root partition, this bug leaves an unexpected opportunity to place suid-binaries into /boot or to tamper with the boot options.

          In most scenarios this is probably not relevant, but that’s no reason to disregard the issue completely.