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.
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?”
