Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Nov 2016 15:55:29 +0000
From: Jason Cooper <>
Subject: Re: CVE-2016-4484: - Cryptsetup Initrd root Shell

Hi Hector,

On Mon, Nov 14, 2016 at 08:45:51PM +0000, Hector Marco wrote:
> Affected package
> ----------------
> Cryptsetup <= 2:1
> ------
> CVE-2016-4484
> Description
> -----------
> A vulnerability in Cryptsetup, concretely in the scripts that unlock the
> system partition when the partition is ciphered using LUKS (Linux
> Unified Key Setup).

This wording appears to have caused a lot of misunderstanding.  afaict,
the binary executable 'cryptsetup' has nothing to do with this bug.
Rather, it is completely in the initrd's script for decrypting a
partition containing the rootfs.

On Debian based systems, the initrd script is in the cryptsetup package,
but if one looks at the upstream repository for cryptsetup:

There are no initrd scripts provided.  So, this is in distro-provided
scripting.  *Not* in cryptsetup [0].

We could argue that those scripts should be in a 'cryptsetup-initramfs'
package by itself, but Debian has their way of doing things, and I'm not
volunteering, so... :-P

> This vulnerability allows to obtain a root initramfs shell on affected
> systems. The vulnerability is very reliable because it doesn't depend on
> specific systems or configurations. Attackers can copy, modify or
> destroy the hard disc as well as set up the network to exflitrate data.

How does this differ from an attacker setting 'init=/bin/sh' on the
kernel command line?  Or, booting from attacker provided media?  Or, in
OS X, booting in single user mode?

Your Discussion section at the end mentions facilities (GRUB passwords,
BIOS passwords, etc) for preventing this "Developer friendliness".  How
do you envision the installer enabling these while providing a failsafe
that an attacker can't exploit?

> In cloud environments it is also possible to remotely exploit this
> vulnerability without having "physical access."

This is straining to add 'cloud' and 'remotely exploit' into this
summary.  I presume all cloud providers who also provide console access
to VM bootup also protect that access behind user credentials or ssh

On a side note, I recommend encrypting the *entire* internal hard disk,
and configuring the BIOS/UEFI to boot from USB.  Then, put grub, /boot,
and the LUKS header on the USB drive.  Which you keep on your physical
keychain.  After boot is complete, you should be able to remove the USB
drive.  Just make sure to plug it back in during system updates. ;-)



[0] note: the authors of cryptsetup have since updated their readme to
clarify the situation around this CVE.

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ