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 . 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.  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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ