X
Tech

Major Linux security hole gapes open

An old Linux security 'feature' script, which activates LUKS disk encryption, has been hiding a major security hole in plain sight.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

Sometimes Linux users can be smug about their system's security. And sometimes a major hole that's been hiding in Linux since about version 2.6 opens up and in you fall.

Cryptosetup Security Hole Code

Please do not code this way. When a system fails, falling through to a root shell is not a good idea.

The security hole this time is with how almost all Linux distributions implement Linux Unified Key Setup-on-disk-format (LUKS). LUKS is the standard mechanism for implementing Linux hard disk encryption. LUKS is often put into action with Cryptsetup. It's in Cryptsetup default configuration file that the problem lies and it's a nasty one. Known Linux distributions with this bug include Debian, Ubuntu, Fedora, Red Hat Enterpise Linux (RHEL), and SUSE Linux Enterprise Server (SLES).

As described in the security report, CVE-2016-4484, the hole allows attackers "to obtain a root initramfs [initial RAM file system] 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 exflitrate data. This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protected (password in BIOS and GRUB) and we only have a keyboard or/and a mouse."

Now for the really embarrassing part. Want to know how to activate it? Boot the system and then hold down the enter key. Wait. After about a minute and a half, you'll find yourself in a BusyBox root shell. You now control the horizontal, you now control the vertical, and whoever owns the system is not going to be happy with you.

The root of this root problem is in the /scripts/local-top/cryptroot file. Once you've gone past the maximum number of trials for transient hardware faults, 30 on x86 architectures, you gain root-level access.

This is an example of how open source fails. Just like the OpenSSL Heartbleed security hole, once you look at the code, the problem leaps out at you. But, if you don't look, it just hides there in plain sight. Open-source security only works if you actually read the code.

What's even more annoying, this only works if you've encrypted your system partition. Yes, by doing the smart thing of using encryption, you've actually opened the door to this attack. Fun!

You can't use this to break into users' encrypted partitions. Of course, you can still wreck them.

Now, some of you are saying, "What does this matter! You still need to be at a console to do it and if you're at the machine, you're already three quarters of the way to wrecking any system." True, but I have one word for you: Cloud.

You can use this attack to "remotely exploit this vulnerability without having 'physical access'". Since Ubuntu is the most popular cloud operating system of them all, this has the potential to be a truly damaging security hole.

How bad? This bad:

  • Elevation of privilege: Since the boot partition is typically not encrypted. Then:
    • 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 be 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.

Fortunately, it's easy to fix. Just edit the cryptroot file so that when the number of password guesses has been exhausted, the system stops the boot sequence.

Cryptsetup Fix

Here's one example of how to patch this problem.

The Linux distributors will soon have this fixed. But, in the meantime, we've got another security headache. Savvy Linux administrators shouldn't wait. They should patch the configuration file.

The hole was found by Hector Marco Gisbert, a computer science lecturer at the University of the West of Scotland. He presented a speech, "Abusing LUKS to Hack the System" at the DeepSec 2016 security conference.

Related Stories:

Editorial standards