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

Sven Eschenberg sven at whgl.uni-frankfurt.de
Tue Nov 15 20:42:51 CET 2016



Am 15.11.2016 um 20:19 schrieb Robert Nichols:
> On 11/15/2016 12:40 PM, Sven Eschenberg wrote:
>>
>>
>> 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).
>
> The machines I have all either (a) if a BIOS administrator password is
> set, requires that password in order to enter the boot menu, or (b)
> allow all alternative devices to be excluded as boot device candidates.
> Either way, you need the BIOS administrator password to get to an
> alternative boot device.
>

Surprisingly this seems to be the case for the machine I just tested. 
I'd assume an extra option+PW for the boot menu however, since it is not 
a direct access to the setup nor a persistent change. So, yes, admitted, 
with an admin PW one can get all the way to the initram without entering 
an extra password. I wonder however how securely that password is stored?

>>> 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.
>
> sulogin is going to be hard to do if the root filesystem (where
> /etc/shadow resides) has not been decrypted. You would have to have some
> alternative password mechanism, and you can already accomplish that in
> GRUB with password-protected alternatives.
>

No, the root filesystem is the initram (initrd) until rootfs is switched 
over - all you have to do is adding a passwd(file) with an entry to it. 
You won't need shadow anyway, since the only login supported is a root 
login, which implies full access to shadow (usually). Of course you 
would probably not want to just grep the root line from the system, but 
generate a single line passwd(file) with an entry for root with some 
seperate password. If you trust on the cryptographic strength of the 
hashing and salting in the passwd/shadow files, you could include them 
aswell and support user and root logins with sulogin (during initrd). 
Using shadow in this particular case makes sense again.

-Sven



More information about the dm-crypt mailing list