An error in the implementation of the Cryptsetup utility used for encrypting hard drives allows an attacker to bypass the authentication procedures on some Linux systems just by pressing the Enter key for around 70 seconds. This results in the attacked system opening a shell with root privileges.

The issue, tracked as CVE-2016-4484, was discovered by Spanish security researcher Hector Marco, who also found last year that you could bypass GRUB2 authentication on Linux systems just by pressing Backspace in the username field 28 times.

This time, Marco was studying Cryptsetup, a utility that allows users to encrypt their hard drives via LUKS (Linux Unified Key Setup).

Cryptsetup allows users to retry passwords over and over again

The researcher discovered problems in how Cryptsetup scripts handle the boot process when the user is asked for the encryption password. This password is needed to decrypt information on protected hard drives, boot the system, and grant the authenticated user access to his data.

"The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/crypt rot," Marco explains. "When the user exceeds the maximum number of password tries (by default 3), then boot sequence continues normally."

Marco says that Cryptsetup interprets this error as a "slow device" that needs more time to warm-up. Because of this design error on the developer's part, Cryptsetup allows the user to retry his encryption password by reloading the authentication procedure.

This procedure is reloaded up to 30 times on an x86 system (93 total password tries), and 150 times on a PowerPC machine (452 total password retries).

Cryptsetup opens a shell with root privileges

While the password retries aren't enough to carry out a brute-force attack, Marco says that the bigger problem appears when the user has exhausted all authentication attempts.

As you can see from the image above, instead of blocking access to the user's system, Cryptsetup starts an Initrd shell with root privileges, most likely for debugging purposes.

An attacker could use this shell to perform a series of actions, as described by Marco:

Elevation of privilege: Since the boot partition is typically not encrypted: It can be used to store an executable file with the bit SetUID enabled. Which can later be used to escalate privileges by a local user. If the boot is not secured, then it would be possible to replace the kernel and the initrd image.

Since the boot partition is typically not encrypted: Information disclosure: It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access to non-encrypted information in other devices.

It is possible to access all the disks. Although the system partition is encrypted it can be copied to an external device, where it can be later be brute forced. Obviously, it is possible to access to non-encrypted information in other devices. Denial of service: The attacker can delete the information on all the disks.

All in all, an attacker wanting to skirt all the repeated password prompts and just access the shell, needs to hold down the Enter key for approximately 70 seconds or more.

Some Linux systems affected, including cloud servers

LUKS is one of the standard methods for encrypting hard drives on Linux. The issue Marco discovered affects only Linux distros based on the Debian distribution, such as Ubuntu.

"The initrd script is a Debian-specific patch only affecting the distributions derived from Debian (such as Ubuntu)," Lubomir Rintel tells Bleeping Computer. "It does *not* affect other distributions that use Linux, LUKS or cryptsetup. E.g. Fedora utilizes unmodified cryptsetup along with systemd to deal with the device unlocking and is not affected by the problem."

UPDATE [10:45 EST]: A few hours after this article went live, Marco announced on his site that after further tests, Fedora distros are vulnerable as well. "We have found that systems that use Dracut instead of initramfs are also vulnerables (tested on Fedora 24 x86_64)," Maroc wrote.

Furthermore, exploiting the flaw requires physical access to the affected device, in order to trigger the boot procedure and access the terminal. For cloud-based services, where Linux systems are used en-masse, the attacker can exploit this flaw remotely.

Marco blames the presence of this shell at the end of a failed authentication system on the Linux community itself.

"In general, the GNU/Linux ecosystem (kernel, system apps, distros, ...) has been designed by developers for developers. Therefore, in the case of a fault, the recovery action is very 'developer friendly', which is very convenient while developing or in controlled environments," Marco says. "But then Linux is used in more hostile environments, this helpful (but naive) recovery services shall not be the default option."

For his part, Marco says he proposed a fix that halts the boot execution and prevents the repeated password guesses. He also recommends that Cryptsetup developers remove the problematic functionality, for the sake of security.

A fix for CVE-2016-4484 was added to Cryptosetup version 2:1.7.3-2, albeit not in the stable branch. The fix was incorporated in Debian distributions on November 7, while Canonical has delayed the patch.

UPDATE [06:15 EST]: Article was updated with information about Cryptosetup, Debian, and Ubuntu patch status, along with a quote from Mr. Rintel that clarifies the vulnerable attack surface. Title was also updated to reflect that the flaw allows bypassing disk encryption authentication procedures, not the actual encryption. Encrypted data is safe, but attackers can get root privileges on targeted systems.