Bug 1009220 - (CVE-2016-4484) VUL-0: CVE-2016-4484: dracut, grub2: LUKS prompt may drop to initrd shell
(CVE-2016-4484)
VUL-0: CVE-2016-4484: dracut, grub2: LUKS prompt may drop to initrd shell
Status: RESOLVED INVALID
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Normal
: ---
Assigned To: dracut maintainers
Security Team bot
https://smash.suse.de/issue/175218/
CVSSv2:SUSE:CVE-2016-4484:4.7:(AV:L/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-09 08:54 UTC by Sebastian Krahmer
Modified: 2020-06-16 22:06 UTC (History)
17 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
researcher proposed fix (800 bytes, patch)
2016-11-14 20:20 UTC, Andreas Stieger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Sebastian Krahmer 2016-11-09 08:55:28 UTC
I could not find any info on what this CVE is about, but according
to the Debian bug tracker its just a minor issue. So setting it to VUL-1
(to be fixed only in Factory).
Comment 4 Ludwig Nussel 2016-11-09 12:10:28 UTC
what am I supposed to do here?
Comment 7 Andreas Stieger 2016-11-14 20:16:37 UTC
Public blog post:
http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

User with access to boot prompt may cause the initrd to drop from the LUKS password prompt to a shell.
Comment 9 Andreas Stieger 2016-11-14 20:20:11 UTC
Created attachment 701942 [details]
researcher proposed fix
Comment 10 Andreas Stieger 2016-11-14 20:40:52 UTC
Probably not even in cryptsetup but in dracut and friends?
Comment 12 Ludwig Nussel 2016-11-15 09:42:02 UTC
(In reply to Andreas Stieger from comment #10)
> Probably not even in cryptsetup but in dracut and friends?

yes.

In our default setup grub isn't locked down so one could pass arbitrary parameters to the initrd or load a different one anyway. So not a big deal for the default setup. Relevant for admins who locked down bios and bootloader though.
IMO the fix should just ask for the passphrase in an endless loop as there is no useful alternative. ctrl-alt-del or power button works independent of a prompt or "maximum amount of retries" dead end.
Comment 13 Alexander Bergmann 2016-11-15 16:17:45 UTC
It looks like dracut is enforcing the debug mode at the end of modules.d/90crypt/cryptroot-ask.sh even if the LUKS partition got decrypted.

The script is calling 'need_shutdown' that creates a file inside the initramfs root.

// modules.d/99base/dracut-lib.sh
need_shutdown() {
    >/run/initramfs/.need_shutdown
}

This enables "Debugging dracut on shutdown" as explained inside dracut.html.
----------------------------
To debug the shutdown sequence on systemd systems, you can rd.break on pre-shutdown or shutdown.

To do this from an already booted system:
# mkdir -p /run/initramfs/etc/cmdline.d
# echo "rd.debug rd.break=pre-shutdown rd.break=shutdown" > /run/initramfs/etc/cmdline.d/debug.conf
# touch /run/initramfs/.need_shutdown

This will give you a dracut shell after the system pivot’ed back in the initramfs.
----------------------------

So it looks like 'need_shutdown' shouldn't be called after cryptsetup execution.
Comment 14 Daniel Molkentin 2016-11-16 08:25:18 UTC
I tried that and it isn't enough. Here is the suggestion by upstream, which I find more resilient:

"Anaconda (the Fedora/RHEL installer) does add “rd.shell=0” to the kernel
command line automatically, if you setup the bootloader with a password at
installation time."

The equivalent would be to add this functionality to YaST, or yast-bootloader more specifically, in the same way the console parameters are added: YaST needs to add/remove "rd.shell=0" to /etc/default/grub2 depending on whether or not a password is set.
Comment 15 Sebastian Krahmer 2016-11-16 08:47:30 UTC
(In reply to Ludwig Nussel from comment #12)
> (In reply to Andreas Stieger from comment #10)
> > Probably not even in cryptsetup but in dracut and friends?
> 
> yes.
> 
> In our default setup grub isn't locked down so one could pass arbitrary
> parameters to the initrd or load a different one anyway. So not a big deal
> for the default setup. Relevant for admins who locked down bios and
> bootloader though.
> IMO the fix should just ask for the passphrase in an endless loop as there
> is no useful alternative. ctrl-alt-del or power button works independent of
> a prompt or "maximum amount of retries" dead end.

Since the talk mentions cloud setups exploited via VNC, would we need to lock
down our grub, so nobody can add "init=/bin/bash" in the first place?

If CVE-2016-4484 is considered an issue in cloud environments, we
should make sure nobody can play with boot cmdline at all, right?

I dont know how easy it would be to access foreign terminals
via VNC/web-VNC on suse cloud (for instance
if you purchased a neighboring VM), or if you need a session-id/token to do so.
Comment 16 Daniel Molkentin 2016-11-16 11:08:55 UTC
I talked to jreidinger about the proposal to fix it in yast-bootloader. His response (quoted with permission):

"If there is agreement in security team about [controlling the rd.shell parameter in yast-bootloader depending on whether the password is set], then it is fine for me. Just note, that currently we do not support password protection grub in autoyast ( we should add it in future ), but it is question for jsrain or kobliha about adding it."
Comment 17 Ludwig Nussel 2016-11-16 14:06:32 UTC
I wouldn't move the problem to YaST. I suppose grub-install knows if a password is set I suppose so it could put this parameter automatically itself. That also works if yast isn't used to configure the bootloader.

Nevertheless although dropping to a shell is not a security issue if no password is used it's still user unfriendly. dracut should do an endless loop asking for the passphrase independent of any other hardening measures. I hope the exit codes of cryptsetup are useful enough to distinguish wrong passphrase from other error conditions.
Comment 18 Josef Reidinger 2016-11-16 14:24:58 UTC
fix is under review https://github.com/yast/yast-bootloader/pull/379

please note that I use it only when password protection of kernel param modification is used. For global password protection it is useless because after unlocking it, you can modify kernel parameters.
Comment 19 Josef Reidinger 2016-11-16 14:26:17 UTC
but if ludwig would like to fix it in grub2 scripts, it is fine for me and just scrap my patch in yast. ( as it have nasty side-effect of removing even if user want rd.shell variable )
Comment 20 Marcus Meissner 2016-11-17 10:50:45 UTC
I would say:

- dracut should have an endless loop on querying the passphrase
- grub2 should do lockdown with rd.shell=0 if there is a grub password

If grub2 can handle that, yast2 bootloader does not need to take care I think.
Comment 22 Josef Reidinger 2016-11-18 06:40:53 UTC
mchang- how do you see difficulty of implementing it in grub2 itself? as it do not have drawback I described, but if it is too hard I am fine with having it in y2-bl.
Comment 23 Michael Chang 2016-11-18 09:10:22 UTC
(In reply to Josef Reidinger from comment #22)
> mchang- how do you see difficulty of implementing it in grub2 itself? as it
> do not have drawback I described, but if it is too hard I am fine with
> having it in y2-bl.

I don't really get what is the real deal on lock-down rd.shell=0 from grub2 ? As you know grub2 has editor interface to any selected boot entries, in which one could easily modify it to whatever his likes. (or to boot the system manually by typing commands).

Well, then it sounds more complicated to me, :( though my understanding could be wrong in some way.

1. (In YaST) enforce password protection to the command and editor interface in addition to setting rd.shell=0 in the script.

Or

2. discard any rd.shell= in linux/linuxefi/multiboot/chainloader (ie any supported boot protocol) and enforce to rd.shell=0 before handing over control. But may be inconvenient (ie no flexibility) while comes to "debugging issues".
Comment 24 Josef Reidinger 2016-11-18 12:09:35 UTC
(In reply to Michael Chang from comment #23)
> (In reply to Josef Reidinger from comment #22)
> > mchang- how do you see difficulty of implementing it in grub2 itself? as it
> > do not have drawback I described, but if it is too hard I am fine with
> > having it in y2-bl.
> 
> I don't really get what is the real deal on lock-down rd.shell=0 from grub2
> ? As you know grub2 has editor interface to any selected boot entries, in
> which one could easily modify it to whatever his likes. (or to boot the
> system manually by typing commands).
> 
> Well, then it sounds more complicated to me, :( though my understanding
> could be wrong in some way.
> 
> 1. (In YaST) enforce password protection to the command and editor interface
> in addition to setting rd.shell=0 in the script.
> 
> Or
> 
> 2. discard any rd.shell= in linux/linuxefi/multiboot/chainloader (ie any
> supported boot protocol) and enforce to rd.shell=0 before handing over
> control. But may be inconvenient (ie no flexibility) while comes to
> "debugging issues".

we are talking about situation when --restricted password protection mode is used. When it is used, then this rd.shell=0 would prevent to get into initrd shell without password.
Comment 25 Andy Huang 2016-11-21 05:04:47 UTC
Hello All,

  Does this issue exist suse11sp3/suse11sp1/suse10sp4? 

Thanks!
Comment 26 Xuanke Han 2016-11-21 06:46:35 UTC
(In reply to Andy Huang from comment #25)
> Hello All,
> 
>   Does this issue exist suse11sp3/suse11sp1/suse10sp4? 
> 
> Thanks!

I have the same confusion.
Comment 27 Michael Chang 2016-11-21 08:06:17 UTC
(In reply to Josef Reidinger from comment #24)
> we are talking about situation when --restricted password protection mode is
> used. When it is used, then this rd.shell=0 would prevent to get into initrd
> shell without password.

OK. I was mislead by the $subject to think the password was used to unlock the LUKS partition.

If it's "--restricted password protection mode" then I think YaST is more feasible here, as it's not part of grub2 shipped scripts and instead YaST generates them for users. If anyone works out such setup without YaST, he must be doing it though his own scripts and we should not put a hand in it.

Thanks. :)
Comment 28 Josef Reidinger 2016-11-21 10:22:36 UTC
(In reply to Marcus Meissner from comment #20)
> I would say:
> 
> - dracut should have an endless loop on querying the passphrase
> - grub2 should do lockdown with rd.shell=0 if there is a grub password
> 
> If grub2 can handle that, yast2 bootloader does not need to take care I
> think.

according to michael comment, are you fine with merging fix in yast2-bootloader?
Comment 29 Marcus Meissner 2016-11-21 15:33:22 UTC
https://github.com/yast/yast-bootloader/pull/379 looks good to me.
Comment 30 Josef Reidinger 2016-11-21 15:39:41 UTC
thanks, so yast2-bootloader fixed for TW and SP3

Please reassign to whoever is responsible for dracut for endless loop for password query
Comment 31 Marcus Meissner 2016-11-21 17:37:38 UTC
(In reply to 玄科 韩 from comment #26)
> (In reply to Andy Huang from comment #25)
> > Hello All,
> > 
> >   Does this issue exist suse11sp3/suse11sp1/suse10sp4? 
> > 
> > Thanks!
> 
> I have the same confusion.

you mean question.

I tested the encrypted volume booting for SLE11, it does not launch an emergency shell, but instead just proceeds withoiut mounting the filesystem.

So.

SLES 11 and SLES 10 are not affected by this problem.
Comment 32 Josef Reidinger 2016-11-30 08:51:15 UTC
reassigning to dracut maintainer.
Comment 33 Daniel Molkentin 2016-11-30 10:38:10 UTC
With the fix in YaST, changes in Dracut are no longer applicable. Security, pls handle this bug at your discretion.
Comment 35 Daniel Molkentin 2017-01-13 15:07:27 UTC
Reassigning to YaST Bootloader maintainer.
Comment 36 Josef Reidinger 2017-01-30 13:34:19 UTC
(In reply to Daniel Molkentin from comment #33)
> With the fix in YaST, changes in Dracut are no longer applicable. Security,
> pls handle this bug at your discretion.

Daniel - why it is no longer applicable? 

from comment#17 It looks like good practice, to not go to rescue shell if wrong password is used.
Comment 37 Ludwig Nussel 2017-03-09 10:26:43 UTC
42.3 just dropped me to a dracut shell on an installation with full disk encryption. Please make sure this gets fixed.
Comment 38 Josef Reidinger 2017-03-09 11:18:40 UTC
(In reply to Ludwig Nussel from comment #37)
> 42.3 just dropped me to a dracut shell on an installation with full disk
> encryption. Please make sure this gets fixed.

so rd.shell=0 is not set? if so, then please attach yast logs.
Comment 45 Marcus Meissner 2020-06-04 15:47:14 UTC
As Daniel asked me to review:

What do we want to protect here?

We have certain scenarios where the boot process needs to be locked down, and a local user should not be able to go into a shell before the system login prompt.

E.g. for Common Criteria certification. Some physical access scenarios as described in:

http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html


In these systems it should not be possible to get a shell except from the defined "login" context, so no dracut or other emergency shells.

Question was:
- How do we detect such conditions?

  Currently we do this with yast2 bootloader password.

  "Protect Boot Loader with Password"

When this is enabled, an emergency shell must not be reachable just by typing on the keyboard or mouse clicks.
Comment 46 Daniel Molkentin 2020-06-05 16:25:20 UTC
Thank you, Marcus. Since all we are discussing here is trailing behind the bootloader password prompt, I will finally close this issue as non-applicable.