From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Tue, 15 Nov 2016 20:20:29 +0100 (CET) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c6jGy-0007gL-Hn for dm-crypt@saout.de; Tue, 15 Nov 2016 20:20:00 +0100 From: Robert Nichols Date: Tue, 15 Nov 2016 13:19:26 -0600 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [dm-crypt] About CVE-2016-4484: - Cryptsetup Initrd root Shell List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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. >> 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 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. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.