How does your encrypted Linux system respond to the Cryptsetup bug?

The news making the rounds in the Linux security arena is the one about a bug discovered in Cryptsetup, the program used to set up disk encryption in Linux.

The bug, detailed here, was discovered by Hector Marco and Ismael Ripoll.

As described by the authors, the bug is basically the result of incorrect error handling after several failed attempts to decrypt a LUKS encrypted disk. And the failure could be triggered when a user inputs the wrong encryption passphrase, or repeatedly presses the ENTER key.

In their report, they noted that:

An attacker with access to the console of the computer and with the ability to reboot the computer can launch a shell (with root permissions) when he/she is prompted for the password to unlock the system partition. The shell is executed in the initrd environment. Obviously, the system partition is encrypted and it is not possible to decrypt it (AFAWK). But other partitions may be not encrypted, and so accessible. Just to mention some exploitation strategies:

Their report appears to be based on tests of Debian and Ubuntu systems. From my own experience, I can report that every major distribution seems to handle failed hard disk decryption a bit differently. To start with Ubuntu, the system will drop to an initramfs shell after 181 failed attempts (you can simulated it by pressing the ENTER key that many times). If you have such a system, give it a try. After 181 failed attempts, you’ll be presented with a shell like the one shown in Figure 1.

Decrypt Ubuntu 16.10 system partition
Figure 1: Result of failed attempt to decrypt Ubuntu 16.10 system partition

With Fedora 25 Rawhide, you have just three attempts before the system gives you a shell. And that has been the case with Fedora systems for as long as I can remember. Compare that to the 181 attempts on Ubuntu 16.10.

Decrypt Fedora 25 Rawhide system partition
Figure 2: Result of failed attempt to decrypt Fedora 25 Rawhide system partition

Manjaro 16.10, which uses the Calamares installer, is even less forgiving. It gives you just one attempt before it drops you into a shell.

Decrypt Manjaro 16.10 system partition
Figure 3: Result of failed attempt to decrypt Manjaro 16.10 system partition

In all three case, the encrypted system partition is still encrypted, so you data is still save. However, as detailed in the bug report, unencrypted partitions, like ones mounted at /boot and /boot/efi (on UEFI systems) might still be open for exploitation. But how far can an attacker go on such system, when the system partition is still encrypted? Not far, I hope.

Related Post:  Kazam vs. recordMyDesktop. Kazam won

A bug always has a solution, and in this case, the authors provided an easy-to-apply workaround. I’ve expanded on it a bit in the code block below. If after applying the workaround you discover that it does not work, welcome to the club. It didn’t work on all the encrypted systems I applied it on – Ubuntu 16.10, Manjaro 16.10, and Fedora Rawhide. By the way, all three distributions were running either Cryptsetup 1.7.2 or 1.7.3.

Related Post:  Accessing Bingo Sites through Linux

If the workaround stopped your system from dropping into a shell on failed decryption attempts, which means it worked, post a comment. I’ve contact the authors with my findings, so I’ll update this article when I get some feedback from them. Perhaps there’s something I missed.

LinuxBSDos needs your donation to continue!

I hope this article has saved you valuable time and effort to fix a problem that would have taken more time than is necessary. That makes me happy, and why I love doing this. But because more people than ever are reading articles like this with an adblocker, ad revenues have fallen to a level that's not enough to cover my operating costs. That's why I want to ask you a favor: To make a one-time or recurring donation to support this site and keep it going. It's a small favor, but every one counts. And you can make your donation using Patreon or directly via Paypal. Thank you for whatever donation you're able to make.

Donate via Patreon. Donate via Paypal.

Aside from donation, you may also signup to receive an email once I publish new content. Your email will not be shared or traded to anyone. And you can unsubscribe at any time.

Please share:

We Recommend These Vendors and Free Offers

Launch an SSD VPS in Europe, USA, Asia & Australia on Vultr's KVM-based Cloud platform starting at $5:00/month (15 GB SSD, 768 MB of RAM).

Deploy an SSD Cloud server in 55 seconds on DigitalOcean. Built for developers and starting at $5:00/month (20 GB SSD, 512 MB of RAM).

Want to become an expert ethical hacker and penetration tester? Request your free video training course of Online Penetration Testing and Ethical Hacking

Whether you're new to Linux or are a Linux guru, you can learn a lot more about the Linux kernel by requesting your free ebook of Linux Kernel In A Nutshell.


  1. Hi,

    I think i found a workaround on Fedora.
    You can add the rd.shell=0 option to your Grub command line to disable the dracut shell.

    – Edit the /etc/grub2.cfg file
    – Add rd.shell=0 to the /vmlinuz… line
    – Reboot and test it

    That works for me.


Leave a Comment

Your email address will not be published. Required fields are marked *