You Can Pop A Root Shell On A Linux Machine By Holding Down The ‘Enter’ Key For 70 Seconds (Here’s How To Fix It)

You Can Pop A Root Shell On A Linux Machine By Holding Down The ‘Enter’ Key For 70 Seconds (Here’s How To Fix It)
Image: Lifehacker

By exploiting a design fault in the Linux boot process that decrypts encrypted hard drives, you can launch a shell with root privileges on the operating system. This security flaw has been confirmed to affect Debian, Ubuntu and Fedora with many other Linux distributions likely to be vulnerable. We have a detailed breakdown of how this vulnerability works and a way to fix the problem on affected systems.

This fault is brought to you by the same researchers that found a way to break into Linux machines by pressing the backspace key 28 times, Hector Marco and Ismael Ripoll from the Cybersecurity Group in Spain.

The issue affects Debian-based distributions, as well as systems that use Dracut instead of initramfs (this was tested on Fedora 24 x86_64 by the researchers).

A utility called Cryptsetup that is used to encrypt hard drives via Linux Unified Key Setup (LUKS) has a fault in the way it handles password failures for the decryption process when a system boots up. The Cryptsetup script file has a design error that lets a user retry the password multiple times. While this isn’t enough to facilitate a brute-force attack, it leads to an bigger problem.

Once a user has used up all the password attempts, it drops them to a shell (Busybox in Ubuntu) that has root privileges. You can prompt the shell to appear by pressing the Enter key for around 70 seconds when the drive decryption password prompt appears during system startup. If you use cloud-based services that use Linux, this vulnerability can be exploited remotely.

It’s important to note that this fault doesn’t give you access to the contents of the encrypted drive. According to the researchers, this fault allows for:

  • 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.
  • 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 later be brute forced. Obviously, it is possible to access non-encrypted information in other devices.
  • Denial of service: The attacker can delete the information on all the disks.

We ran a test to see how much damage we could do with this vulnerability on a fresh Ubuntu Server 16.04.01 LTS installation. We bricked it by simply issuing a command that deletes everything in the boot partition:

How To Fix This Problem

First off, you’ll want to find out if any of your partitions are encrypted using LUKS. You can do this with the following command: dmsetup status | awk 'BEGIN {FS=":"} ; /crypts*$/ {print "Encrypted: " $1}'

This will spit out the names of any encrypted partitions. If none are listed, then you don’t have any encrypted partitions and you shouldn’t be affected by this vulnerability.

If your system is affected, you’ll want to check with your distribution support vendor (Canonical for Ubuntu) to find out whether a patch is available.

If no patch is available, there is a workaround. According to the researchers, the function that launches the busybox shell can be used to prevent console access if the kernel is booted with the “panic” parameter. You can add this to your boot configuration with the following commands:

sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="panic=5 /' /etc/default/grub


You can find the technical details of this vulnerability over at Hector Marco’s website.


  • Nice write-up.

    Other articles online have alluded that this vulnerability will decrypt and infiltrate data that’s encrypted; to my understanding, this is incorrect.

    The worse that can happen is gain access to the initramfs (which is bad) but you’ll not have the ability to mount/read encrypted partitions.
    However, you could gain access to unencrypted partitions or execute a subset of binaries that busybox has.

    In any case, it’s a worry if someone nefarious already has first-person or KVM access to begin with… a minimal requirement to exploit this.

  • Thank you!

    I’ve read some of those articles as well. Definitely incorrect, according to what the researchers have published.

Show more comments

Comments are closed.

Log in to comment on this story!