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

Linexit!

[Tablizer]

That does it, I'm moving to Windows 10!

-32768 Troll

If you can touch it, you can own it

[C3ntaur]

"Assuming an attacker has access to the computer's console"

I was always taught that this pretty much means game over. It might be an interesting way to get a root shell, but if I am sitting in front of the machine with console access, I can think of a number of other ways to get a root shell.

Re:If you can touch it, you can own it

[sexconker]

"If you can touch it, you can own it"

That's known as Trump's Postulate.

What is the Enter key supposed to do?

[daniel23]

but seriously: the problem does not seem that serious at all: encrypted media are still encrypted and what you get is like a rescue shell. You can damage the encrypted media, but this is the case as soon as there is physical access to the machine. TFA says you can install a keylogger but if you have physical access you can plug in the logger between keyboard and usb even faster.

Re:What is the Enter key supposed to do?

[complete loony]

You could probably build a new initramfs and install a key logger there to capture the encryption password. But if you have console access to the machine while it's booting you could probably do that anyway by removing and reinstalling the boot disk.

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.

So what? Tested this on Fedora 25

[passionplay]

How is dropping to initrd "root" access?

1. If you already have physical access to the console, all bets are off anyway. Security 101.

2. If you have WDE enabled, dropping to root gets you initrd only - no passwords, no privileges, nada - all it lets you do is try to mount the file system which can't be because it's encrypted. Only /boot should be unencrypted.

3. The only possible attack vector is to swap out the kernel image. But there are simpler ways to do that than run an exploit.

Did these guys watch too many episodes of the new MacGyver and consider themselves hackers instead of script kiddies?

Did they report the problem as only present if you encrypt specific volumes (which is stupid anyway because your passwords are visible now).

It takes a lot of effort to avoid WDE when installing linux these days. Only an idiot would misconfigure and render his system vulnerable like this. And only an idiot would give his keys to the castle to people he didn't trust.

Social Engineering wins every time and there is nothing you can do about it.

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.

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:What vulnerability?

[flyingfsck]

Exactly. The thing is encrypted. You can boot it various ways, but without the password, it remains encrypted.

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?

Total encryption

[pepa65]

I tried this on one of my systems, and indeed, it dropped me to a root busybox shell in initrd. Since my grub is not password protected, this kind of access (and worse) was already trivial on that system. But, LUKS is still encrypted.

Nowadays grub supports what I call total encryption. (It has support for a LUKS encrypted partition, no need for a separate unencrypted /boot directory.) Now a similar vulnerability was present on one of my total-encrypted systems, but in this case it dropped me to a grub rescue environment.

I would be interested to hear what the possibilities are for evil maid attacts in the grub rescue shell scenario, but I don't believe it's possible, because the kernel and the initrd are still encrypted.