[dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell

Sven Eschenberg sven at whgl.uni-frankfurt.de
Tue Nov 15 19:40:13 CET 2016

Am 15.11.2016 um 16:18 schrieb Robert Nichols:
> On 11/15/2016 07:32 AM, Sven Eschenberg wrote:
>> Obviously it is not a bug in cryptsetup, but rather in dracut and some
>> distributions initrd scripts. What's really annoying about the CVE is
>> the fact, that it is mostly irrelevant. If I can get to the password
>> entry of an initrd, I obviously have control over the boot process. If I
>> do have control over the boot process I have a splendid variety of
>> options to do all the things described in the CVE.
>> I wonder why the authors of the CVE recommend to freeze the system,
>> instead of adding auth to get a shell. Seems quite stupid to completely
>> remove the ability to investigate problems.
> The boot process can be configured to deny that control (BIOS configured
> to boot from the internal drive only, GRUB set up to require a password
> for all except the default selection).

Interesting, haven't seen any such firmware so far for PC. A firmware 
that indeed can disable the bootmenu etc. whilst not requiring a 
password during boot would be the one exception of course.
Most firmwares will actually happily boot the configured port, even when 
the device is switched over, with one exception: Secure Boot with a 
uniquely signed bootloader and a unique key installed in the firmware. 
(Requires a non vendor key).
> On a Red Hat system with an encrypted root filesystem, I get 5 attempts
> to enter the encryption password. Then the system locks up, and the only
> options are to (a) press <ESC> to dismiss the graphical boot screen and
> see a "wrong password" message, and/or (b) press CTRL-ALT-DEL to reboot.

I'm still considering this a stupid approach, I prefer a sulogin with 
auth approach and happily live with it.


More information about the dm-crypt mailing list