[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161116155529.GJ5329@io.lakedaemon.net>
Date: Wed, 16 Nov 2016 15:55:29 +0000
From: Jason Cooper <osssecurity@...edaemon.net>
To: oss-security@...ts.openwall.com
Cc: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
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-ID
> ------
> 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:
https://gitlab.com/cryptsetup/cryptsetup.git
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
keys...
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. ;-)
thx,
Jason.
[0] note: the authors of cryptsetup have since updated their readme to
clarify the situation around this CVE.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
