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 16:19:51 +0100 (CET) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c6fWJ-0001LF-TC for dm-crypt@saout.de; Tue, 15 Nov 2016 16:19:35 +0100 From: Robert Nichols Date: Tue, 15 Nov 2016 09:18:51 -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 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). 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. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.