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 the researchers, the script with the vulnerability (CVE-2016-4484) is in the Debian cryptsetup package 2:1.7.2-3 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 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.

The researchers warn that the vulnerability is especially dangerous in public situations.

“This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect (password in BIOS and GRUB) and we only have a keyboard or/and a mouse,” the vulnerability disclosure reads.

All an attacker would need in those instances – assuming the system is running Linux – would be access to the keyboard or mouse, Marco and Ripoll say. Tourist information kiosks or airport check in kiosks could be prime targets, the two write.

While an attacker would have to have physical access to carry out the attack in most instances, the two warn that in some cloud environments, like those deployed by Ubuntu, the vulnerability could be exploited without physical access.

screen-shot-2016-11-15-at-2-53-40-pm

Users can remedy the vulnerability by fixing the cryptroot script file – /scripts/local-top/cryptroot – directly, suspending execution forever, according to the researchers.

It’s unclear when a true fix will make its way to the Linux distributions. Neither Debian or Ubuntu immediately returned a request for comment on the vulnerability Tuesday.

Marco and Ripoll claim they reported the issue to Debian two weeks ago and while the distribution fixed it, the researchers claim they don’t fully agree with the way it did it.

“This is just one of the problems that the boot sequence has in GNU/Linux. It is too permissive on errors, that is. There is the general idea that if the user has physical access to the computer, then the user IS THE OWNER of the computer (this dates from the very beginning of computing). The IoT will dramatically change this assumption,” Marco and Ripoll told Threatpost.

“When Windows detects an error… it just shows the blue screen… which is very bad if you are a developer but it is the best solution for 99.9% of the users. Shall the system be developer/hacker friendly, or user secure?”

Categories: Cryptography, Vulnerabilities, Web Security

Comments (2)

  1. Eric
    1

    I don’t think these guys have thought this all the way through because getting a shell doesn’t mean you have actual access to my encrypted FS in its unencrypted state. Sure you can damage the FS or the like but you already have physical access so that’s a given, but the boot process continuing doesn’t automagically unlock the FS. I ran into this situation years ago and there’s nothing to fear that isn’t already to fear from someone having physical access.

  2. LuksUser
    2

    The issue has been blown over proportions, say on an ATM there ain’t a traditional keyboard, so you don’t even have a enter button to push. Most IoT’s don’t have user interaction during boot sequence and if they have encrypted / they use a key.
    If someone can do this on a laptop, then they can also choose to boot from an USB and do a lot more than a busybox would allow.
    There is little data disclosure that can be done, you can see what’s in /boot, sure you can get the grub password hash.

    There are a lot worse things, just look at Trump, the rise of far-right-wing power in the world is far more dangerous than this.

Comments are closed.