Cryptsetup Vulnerability Grants Root Shell Access On Some Linux Systems (threatpost.com)

msm1267 quotes a report from Threatpost: A vulnerability in cryptsetup, a utility used to set up encrypted filesystems on Linux distributions, could allow an attacker to retrieve a root rescue shell on some systems. From there, an attacker could have the ability to copy, modify, or destroy a hard disk, or use the network to exfiltrate data. Cryptsetup, a utility used to setup disk encryption based on the dm-crypt kernel module, is usually deployed in Debian and Ubuntu. Researchers warned late last week that if anyone uses the tool to encrypt system partitions for the operating systems, they're likely vulnerable. Two researchers, Hector Marco of the University of the West of Scotland and Ismael Ripoll, of the Polytechnic University of Valencia, in Spain, disclosed the vulnerability on Friday at DeepSec, a security conference held at the Imperial Riding School Renaissance Vienna Hotel in Austria. According to a post published to the Full Disclosure mailing list, the vulnerability (CVE-2016-4484) affects packages 2.1 and earlier. Systems that use Dracut, an infrastructure commonly deployed on Fedora in lieu of initramfs -- a simple RAM file system directory, are also vulnerable, according to the researchers. The pair say additional Linux distributions outside of Debian and Ubuntu may be vulnerable, they just haven't tested them yet. The report adds: "The problem stems from the incorrect handling of a password check when a partition is ciphered with LUKS, or Linux Unified Key Setup, a disk encryption specification that's standard for Linux. Assuming an attacker has access to the computer's console, when presented with the LUKS password prompt, they could exploit the vulnerability simply by pressing 'Enter' over and over again until a shell appears. The researchers say the exploit could take as few as 70 seconds. After a user exceeds the maximum number of three password tries, the boot sequence continues normally. Another script in the utility doesn't realize this, and drops a BusyBox shell. After carrying out the exploit, the attacker could obtain a root initramfs, or rescue shell. Since the shell can be executed in the initrd, or initial ram disk, environment, it can lead to a handful of scary outcomes, including elevation of privilege, information disclosure, or denial of service."

Comments

Re:This is the year

[unrtst]

While this news isn't great, the encrypted image remains encrypted. If you allow your computer to boot to anything other than your main secure and encrypted setup, then someone with physical access at boot that has made it to that point in the boot process could simply boot to a rescue disk (usb/cd/network/etc), and then do even more damage. Also, since they have physical access, they could just pop out the drive and mirror it via any other system, or reset the bios (to clear bios password) and allow boot by other media. And if you had a bios password, how did they get past that to get to the exploit step?

This isn't good, but it doesn't seem to be a big deal either.

It will if you have a flash drive, same as ctrl-al

[raymorris]

> if you have physical access to the machine. But to be clear I don't think my Windows install will drop me to the desktop if I press enter on the password prompt for 70 seconds! LOL. Not to Linux bash

It'll give you a desktop if you put in a bootable flash drive first.

Btw the "issue" discussed here isn't a Linux bash shell either. It's an initrd nash. You're not logged into the OS, which is still securely encrypted.

Sure you could damage the data by reformatting the drive, but given you need physical access you could just as easily damage the drive with a hammer.

Re:Linux sUKS -not!

[Sun]

What we know about the system:

1. The system's hard disk is encrypted
2. The attacker doesn't have the password (or else this isn't an attack)
3. The attacker has physical access to the system during boot

What's the difference between this "attack" and inserting a live CD?

Re:So what? Tested this on Fedora 25

[gweihir]

Indeed. You basically get the same as booting a rescue-system or removing the disk and accessing it directly gets you. In all, but a few very special set-ups, this means this is not actually a vulnerability or a bug that needs fixing. However, in these few very special set-ups, the standard distro-mechanisms are not enough to protect you anyways and if you rely on them, you have bigger problems than a root-shell with an unlocked encrypted root partition.

This is not worthy of a CVE. My guess is some big egos with rather small skills are at work here.