oss-sec mailing list archives
Re: CVE-2016-4484: - Cryptsetup Initrd root Shell
From: Jason Cooper <osssecurity () lakedaemon net>
Date: Wed, 16 Nov 2016 15:55:29 +0000
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.
Current thread:
- CVE-2016-4484: - Cryptsetup Initrd root Shell Hector Marco (Nov 14)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell - Update: Dracut is also vulnerable Hector Marco-Gisbert (Nov 14)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell Leo Famulari (Nov 14)
- Re: [FD] [oss-security] CVE-2016-4484: - Cryptsetup Initrd root Shell Hector Marco (Nov 15)
- Re: Re: [FD] [oss-security] CVE-2016-4484: - Cryptsetup Initrd root Shell Jeremy Stanley (Nov 15)
- Re: [FD] [oss-security] CVE-2016-4484: - Cryptsetup Initrd root Shell Hector Marco (Nov 15)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell Jason Cooper (Nov 16)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell John Haxby (Nov 16)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell Jason Cooper (Nov 17)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell John Haxby (Nov 17)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell Jason Cooper (Nov 17)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell John Haxby (Nov 17)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell Jacobo Avariento (Nov 17)
- Linux encrypted boot security, was: CVE-2016-4484: - Cryptsetup Initrd root Shell Jason Cooper (Nov 18)
- Re: CVE-2016-4484: - Cryptsetup Initrd root Shell John Haxby (Nov 16)