An attacker can abuse a vulnerability to launch a shell with root privileges on most Linux machines just by holding the ‘Enter’ key for 70 seconds.
Researchers Hector Marco & Ismael Ripoll unveiled the bug (CVE-2016-4484) in their presentation “Abusing LUKS to Hack the System” at the DeepSec 2016 security conference.
The flaw is no laughing matter, as Marco notes in a blog post:
“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 exflitrate 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.”
CVE-2016-4484 resides in Cryptsetup, a utility which is responsible for implementing disk encryption. More specifically, it’s found in a script that unlocks the system partition when the partition is ciphered using LUKS (Linux Unified Key Setup). The vulnerable script file is responsible for a password check.
Here’s how it works. When you install a Linux OS like Debian or Ubuntu, you are prompted to encrypt the installation.
For security purposes, you should encrypt the disk. But there’s a problem: the script file /scripts/local-top/cryptroot doesn’t handle the check for a single password that protects the system and swap partitions.
The booting scripts in essence tries to mount the “failing” device a total of 30 times. Each time boot fails, a user is given three additional chances to supply a password. That means they have a total of 93 password guesses to get it right.
Or not. Marco explains:
“But the real problem happens when the maximum number of trials for transient hardware faults is reached (30 times for non ppc systems), line 114 at function local_device_setup(). In this case, the top level script is not aware of the root cause of the fault and drops a shell (busybox) to the user, line 124. The panic() function (see below) tries to insert additional drivers and runs a shell…
“The attacker just have to press and keep pressing the [Enter] key at the LUKS password prompt until a shell appears, which occurs after 70 seconds approx.”
So what does that root shell? On its own, it doesn’t allow an attacker to decrypt the disk. But an attacker could copy the disk to an external drive and brute-force it there.
They could also simply delete all of the disk’s information or abuse the unencrypted boot partition to store an executable that they could leverage to escalate privileges at a later time.
In most cases, an attacker would need the ability to access the console and to initiate a reboot on the target machine in order to exploit this vulnerability, though there are some situations (i.e. cloud environments) where remote exploitation could be possible.
With that being said, it’s important that users plug their vulnerable machines by applying a fix or workaround.
For more information, please be sure to read Hector Marco’s blog post.
What a beautifully simple vulnerability but one which is worrying considering how long it has taken to be discovered and the open source nature of Linux.
Whilst it's simple to repair manually let's hope that major distributions push out a patch sooner rather than later.
Well, it's not really a vulnerability. I've known about this one for months. I never even bothered to mention it since it's not serious at all. Considering how it works, it's not really imposing a danger. Yes, you could copy all of the content with it, but you could do that with a USB stick loaded with a disk copy tool. It's not really a threat in any way. There are enough alternatives to reach the same thing which makes this not a danger. You could load the system up to a shell using a boot stick, you could copy it with a disk copy tool, you could start the computer in single user mode (also active by default). All reach the same thing, which is a system with a still encrypted hard disk which you can't access unless you have a key or enough time to decrypt it, which will take a seriously long time.
The unencrypted boot partition is at risk here. Think of a scenario whereby an attacker has access to a critical system and then the boot partition is tampered with. Would you feel comfortable operating a critical system if you knew the integrity of the boot partition was questionable?
This flap is based on a straw man. A computer with or without an encrypted file system, is not secure against compromise by someone with physical or logical console access than one. One with encrypted file systems is significantly more secure, even with this vulnerability (as it certainly is), than one without: in the first case, there is no protection beyond whatever prevents console access. In the second, there is data encryption, which Mallory still has to defeat if she wants access to the data; destruction or modification to deny service still are available, but the data remains protected. She might manage to install exfiltration software that would operate after a normal (with-passphrase) boot, that might be rendered useless by physical or firewall isolation, and copying the encrypted partitions leaves the task of decryption to still be done.
I disagree; it's a textbook vulnerability from what I can see. Being able to elevate a shell with root privileges is a major vulnerability.
One obvious example is where the vulnerable system is in a public place – do you really want a person being able to gain root access?
oh god OF COURSE YOU CAN GET ROOT ACCESS USING PHYSICAL ACCESS and people want it that way. Windows has that mac has that linux has that everyone likes it that way.
Just encrypt the drive and use a bios password.
Clearly nobody is reading or understanding the background:
"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 especially 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."
"The attacker needs to have physical access to the machine in order to exploit this flaw. The attack consists of gaining access to the shell after wrong LUKS password has been entered during the boot process. Once shell access is obtained various brute force attacks (both manual and automated) can be carried out. The contents of the drive can also be copied off to do conduct offline brute force attacks on another computer."
A brute force attack against a 256 bit key protected by a good pass phrase has an expected time to success in the order of 10^51 years, for those who have an exaflop scale computer to put on the task full time.
Which is totally unnecessary (brute force) if you can alter the boot process and capture the key.
'So what does that root shell? On its own, it doesn't allow an attacker to decrypt the disk. But an attacker could copy the disk to an external drive and brute-force it there.'
Of course if they have physical access they probably don't even need to go through that much effort so quickly since they could just steal the hardware. That shouldn't take much thought. Makes the vulnerability less impressive though obviously it still is a grave vulnerability.