The "cryptsetup initrd root shell" vulnerability [LWN.net]

Hector Marco and Ismael Ripoll report a discouraging vulnerability in many encrypted disk setups: simply running up too many password failures will eventually result in a root shell. "This vulnerability allows to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it doesn't depend on specific systems or configurations. Attackers can copy, modify or destroy the hard disc as well as set up the network to exfiltrate data. 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."

to post comments

Physical Access and all

Posted Nov 15, 2016 16:42 UTC (Tue) by fratti (subscriber, #105722) [Link] (2 responses)

Impact: The attacker can do what they could already do by just removing the harddisk and connecting it to their system.

They cannot actually access the encrypted data, but I've already seen sites reporting this as being the case. Lame.

Physical Access and all

Posted Nov 15, 2016 17:15 UTC (Tue) by matthias (subscriber, #94967) [Link] (1 responses)

> Impact: The attacker can do what they could already do by just removing the harddisk and connecting it to their system.

The article describes that keyboard access does not imply access to other hardware (like harddisks). I have seen a lot of systems, where I could have keyboard (and monitor) access, but no access to the harddisk. It is getting less, as for many of the usual subjects (public terminals), keyboard access is nowadays replaced by touchscreen access (which will not help in the emergency shell).

Even if access to the hardware might be possible, it will be a lot more suspicious if you use your screwdriver in public places than if you just type a few characters on the keyboard.

> They cannot actually access the encrypted data, but I've already seen sites reporting this as being the case. Lame.

Once you have a root shell, it will be usually possible to tweak the boot process in a way that you can gain root access again after the system is booted again, which will give you access to the data. It requires a carefully configured secure boot environment to prevent this scenario. So yes, this bug gives possibly access to the data.

Physical Access and all

Posted Nov 16, 2016 9:13 UTC (Wed) by nhippi (subscriber, #34640) [Link]

How many of the public terminal type systems have HD encryption to begin with? You need them to boot automatically, so either there are no encryption and thus no password prompt or (in the unlikely case of competent IT staff) LUKS with a keyfile. And locally stored keyfile opens other attack vectors.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 16:46 UTC (Tue) by corsac (subscriber, #49696) [Link] (1 responses)

The report actually has some inaccuracies.

First, some precision on the timeline: the bug was reported privately to us (Debian security team) on nov 3rd, requesting an embargo until nov 11th for the DeepSec 16 presentation. Considering the low-impact vulnerability and the fact we're not really fan of embargo when it can be avoided, we pushed for publishing a fix early, and it was uploaded to Debian unstable on nov 7th (https://tracker.debian.org/news/813298)

Then, the bug itself. It's *not* a bug in upstream cryptsetup but in the glue added in Debian (and thus propagated to Ubuntu and other Debian derivatives) to support unlocking an encrypted root partition from the initramfs (https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debia...). I don't think it affects Fedora/RedHat, Suse, Arch etc. Also, in our opinion, and as stated earlier, it's a low impact bug. Sure it's bad (and we want to thanks the reporters for that), so the maintainers fixed it in unstable, but it's not considered important enough to warrant a Debian Security Advisory (https://security-tracker.debian.org/tracker/CVE-2016-4484). What you gain is a root access to the initramfs, which you usually can access in other ways if you already have physical access to enter a passphrase to unlock the encrypted partition.

That beeing said, security is in the big picture and how tiny pieces fit together, and I'm all for defense in depth, so yes, the point is still valid. Just not the noise.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 18:45 UTC (Tue) by asalor (guest, #39266) [Link]

Cryptsetup upstream was never contacted by authors, we get information from Debian maintainers (thanks).

The talk title (Abusing LUKS to Hack the System) and directly mention of cryptsetup in CVE (while it is neither bug in cryptsetup upstream nor LUKS format) really does not help anyone.

This was really not the ideal example how researches should cooperate with opensource developers.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 17:39 UTC (Tue) by backslash (guest, #32022) [Link] (7 responses)

On the dracut side of things:

People who want to secure their Fedora/RHEL system have to:

- add a BIOS password
- add a grub password
- add “rd.shell=0” to the kernel command line

Anaconda does add “rd.shell=0” to the kernel command line automatically, if you setup the bootloader with a password.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 17:44 UTC (Tue) by backslash (guest, #32022) [Link] (6 responses)

On the flip side, you can also take out the hard disk and be root on another computer.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 17:55 UTC (Tue) by farnz (subscriber, #17727) [Link] (5 responses)

Depends on the degree of access you have to the system. If the system is a kiosk type setup, where the system is never expected to reboot unattended, and a password is required to decrypt, an "unprivileged" user may have limited keyboard (no function keys, limited subset of navigation keys, no numpad), mouse and touchscreen access, but not physical access to disconnect the HDD without triggering alarms. Because "Enter" is typically on the limited keyboard, this lets an attacker gain "silent" access to the HDD, attempt to root it, then leave the system in an apparently undamaged state (with the access alarm untriggered). That, in turn, is likely to result in a naïve operator simply entering the password to restart the kiosk, allowing the attacker to grab the password.

It's a niche attack, but in that niche it's dangerous.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 18:37 UTC (Tue) by nybble41 (subscriber, #55106) [Link] (4 responses)

> ... this lets an attacker gain "silent" access to the HDD, attempt to root it, then leave the system in an apparently undamaged state (with the access alarm untriggered). That, in turn, is likely to result in a naïve operator simply entering the password to restart the kiosk, allowing the attacker to grab the password.

In addition to manipulating the running system an attacker could modify the initramfs image to include software of their choice, including kernel modules, which will persist across restarts and have access to the encrypted HDD once the device is unlocked by an authorized user (provided the system boots from an unencrypted partition and does not employ Secure Boot). With root access they may also be able to modify BIOS settings through direct access to the CMOS.

How many kiosk-type systems actually require a password to start up, though? That seems like a rather odd combination of requirements; I would naively expect kiosks to be designed for hands-free automatic operation, including restarting into a usable state. If a key is needed to unlock an encrypted disk it should be kept in a TPM and/or obtained from a network server via a secure channel, not typed in at the console. The cryptsetup framework supports running an external program to obtain the decryption key. (Better yet, make the kiosk itself diskless, so there is nothing to encrypt or infect, and keep all data on a secure server.)

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 18:50 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

It's something I've seen in specialised use cases - the idea is to make the kiosks tamper-evident. If power fails, someone has to go round restarting the kiosks; the variation I saw had the operator open the kiosk (with the key), look at the tamper LED on the box around the embedded PC (battery-backed, and fails to "tamper!" if the battery goes flat), and then plug in a Yubikey to the exposed port, which enters the password. The use case was secure intranet terminals in a banking or military environment - and the kiosks also had an ISO 7816 smartcard reader for that purpose.

It's a niche use case, but this bug affects their security analysis in a significant manner. I can't think of any other niche that would be affected, though.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 16, 2016 10:09 UTC (Wed) by oldtomas (guest, #72579) [Link]

Yes that would be this vulnerability's "use case". Another would be a server in a data center with some form of remote console (but why would you encrypt a "server's" hard disk? Nevermind).

That said, if you got to such lengths (locked kiosk, tamper LED, having to send personnel on each reboot), you could at least audit that bit of init code which leads to LUKS unlocking, since it's *that* critical. You're not going to download a random Docker off the intrawebs?

Oh, wait...

The "cryptsetup initrd root shell" vulnerability

Posted Nov 17, 2016 1:39 UTC (Thu) by AdamW (subscriber, #48457) [Link] (1 responses)

Why wouldn't such a setup just have a firmware password? It's a much more inherently strong method of preventing unauthorized interaction with the boot process, after all. The encryption passphrase has never really been *for* that at all.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 17, 2016 10:11 UTC (Thu) by farnz (subscriber, #17727) [Link]

I couldn't get a straight answer on that from the manufacturer - something to do with wanting the system to remain tamper-evident if the disk is removed and replaced, but it sounded like that part of the analysis wasn't fully thought through.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 18:34 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (3 responses)

Which marketing nonce came up with "cryptsetup initrd root shell vulnerability"? How is a name like that supposed to fit on mugs, plushies and t-shirts? No logo or anything.

I propose we call it "Marco LUKS over your shoulder".

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 19:38 UTC (Tue) by misc (subscriber, #73730) [Link] (2 responses)

Maybe we can try to get more luks-urious goodies than mugs and tshirts.

The "cryptsetup initrd root shell" vulnerability

Posted Nov 15, 2016 19:50 UTC (Tue) by karkhaz (subscriber, #99844) [Link] (1 responses)

And if merchandise shoppers press the "Add to cart" button 93 times, they get the whole shop for free!

The "cryptsetup initrd root shell" vulnerability

Posted Nov 16, 2016 16:07 UTC (Wed) by diegor (subscriber, #1967) [Link]

But they can receive home, because they can't insert the address :)

The "cryptsetup initrd root shell" vulnerability

Posted Dec 5, 2016 14:56 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

This is stupid, to exploit this you need physical access anyway, which when you already have you already lose.

The protection is easy, password in grub, BIOS, etc. to prevent access from the initrd.

I actually think it is *required* to behave like currently, because if the initrd fails, you’re SUPPOSED to get a shell to debug things.