CVE-2016-4484.txt

Hector Marco and Ismael Ripoll raised a issue with cryptsetup affecting various
initramfs systems, see
http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

In kinitram, such behaviour is intended.
kinitram aims to provide a base system that can be of help for developing your
own initramfs. In such an environment you want the system to fail safe if
problems arise. Because of this, kinitram runs a rescue shell by default if the
local cryptsetup process fails so that the developer can debug the issue and
prepare a new initramfs. This is particularly relevant if the kernel has a
builtin initramfs as replacement isn't easy in that case.
Such local features aren't very different from the root account kinitram
provides to run an early shell. Whilst the first feature relies on the user
having local access to the machine for authentication, the second one relies on
the user having a valid ssh key.

The reason why this was considered safe is because you shouldn't keep mounted
your /boot partition unless really needed for bootloader, kernel or initramfs
and even so, features like noexec can (and should) be used. The rest of the
system disks were expected to be encrypted with the master ckey contents and,
since no TPM support is yet built-in, the user wasn't expected to be able to do
much more than if he just stole the disks in the device. This is particularly
true if secure boot is not used.

kinitram was designed to avoid the need of a KVM for remote administration so
that FDE could be used more or less securely on cheap consumer grade systems
repurposed as servers, hence enabling a remote KVM on a kinitram system is kind
of pointless because that's what the root account on busybox intends to fix.

You may want to change that behaviour though. For that just replace the contents
of the rescue_shell() function by "exit 1" on the initramfs/init file. This will
kill the init process and make the kernel panic but the local user won't get a
shell.