Cryptsetup Vulnerability Allows Easily Getting To A Root Shell

[phoronix]

Phoronix: Cryptsetup Vulnerability Allows Easily Getting To A Root Shell

CVE-2016-4484 was disclosed on Monday as a Cryptsetup issue that allows users to easily gain access to a root initramfs shell on affected systems in a little over one minute of simply hitting the keyboard's enter key...

http://www.phoronix.com/scan.php?page=news_item&px=Cryptsetup-Security-Fail

[lkundrak]

Too much drama.

1.) This is *not* a cryptsetup vulnerability. It's a Debian specific patch.

2.) The researcher asserts it affects Fedora. That is not true. The Fedora doesn't ship the problematic patch. You'll get a debug shell if your boot fails *and* you didn't setup a bootloader password. But in case you didn't secure your bootloader, there's an easier way to get a shell really...

[arekm]

Yah, stupid clickbaits are everywhere. Here, too. Shame on author!

[darkbasic]

It seems Debian doesn't really want their users to use encryption

[oleid]

According to the linked article, Fedora_is_ affected, too.

But as far as I understood it, it's a feature, not a bug - isn't it? the default policy of debian is dropping the user to a root shell in case of error. Adding the keyword "panic" to grub command line prevents that.

[oleid]

Edit : never mind about fedora.

[bibaheu]

I just tried on Arch. It doesn't work, the system keeps asking for the cryptsetup password (to continue booting), or for the root password to get a recovery shell.

[franglais125]

I tested this on Debian Jessie, it took me a while to get it to work... In any case, all the (relevant to me) data remains encrypted.
If an attacker has physical access, it would actually be much easier to plug a USB drive with whichever OS he/she prefers and modify stuff in a more convenient way.

I am not saying it's a non-issue, but when you think a bit about it...

Here is the tracker for debian: https://security-tracker.debian.org/.../CVE-2016-4484

[Amarildo]

Yet ANOTHER crypto vulnerability on Debian?

[Luke]

This is actually the result of making one of three possible choices about handling a device that does not unlock. In many cases, especially an encrypted root partition, this may save a user from having to boot another device and chroot to make a new initramfs if an initramfs problem prevents unlocking the device. Normally, a failure to find the root partition will always bring an initramfs shell after a delay and in single-user machines this should be kept. I can see how on multi-user or remote-bootable machines this should not be the case. For those all initramfs shells should either require the root password (requiring /etc/shadow in the initramfs) or be disabled entirely and a chroot used to fix any errors.

Many times have I used this behavior or "break" on the kernel command line deliberately to manually unlock encrypted partitions (with their normal passphrases) when using an initramfs from one system on the first boot of a cloned OS on different disks on another system.