Serious Linux Vulnerability Found By Just Holding Down The Enter Key For 70 Seconds
Security researchers have found a rather alarming vulnerability in Linux that could ultimately allow an attacker to copy, modify, or destroy the contents of a hard drive, along with with configure the network to exfiltrate data. That in and of itself is cause for concern, but the real harrowing part about this is how easy it is to activate—an attacker need only boot up the system and hold down the enter key for 70 seconds.
In less time than it takes to microwave a bag of popcorn, an attacker could compromise a Linux machine with potentially serious consequences. The vulnerability that makes it possible lies in Cryptsetup and the scripts it uses to unlock the system partition when it's been encrypted using LUKS (Linux Unified Key Setup). Many Linux distributions use this.
How serious is it really? The researchers say that generally speaking, if an attacker has physical access to a system then it is "game over."
"This vulnerability allows [attackers] to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it doesn't depend on specific systems or configurations... This vulnerability is specially [sic] serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect [sic] (password in BIOS and GRUB) and we only have a keyboard or/and a mouse," note Hector Marco and Ismael Ripoll, the security researchers who discovered the vulnerability.
The fault that triggers the exploit is in the script file /scripts/local-top/cryptroot. Once the user exceeds the maximum number of password attempts (the default is 3), the boot sequence continues and calls up a local script that treats the error as if it's a device that needs more time to warm up. The boot script then tries to cover/mount what it thinks is a failing device. When the maximum number of attempts is reached, it drops a shell to the user.
"The attacker just have [sic] to press and keep pressing the [Enter] key at the LUKS password prompt until a shell appears, which occurs after 70 seconds approx," the researchers say.
Ready for the bombshell? While this is far easier to exploit when having physical access to a Linux machine, it isn't necessarily required. In cloud environments, it is possible to remotely exploit the vulnerability. That's bad news for Ubuntu, which is the most popular Linux OS in the cloud.
The good news is this is an easy exploit to fix. A user just needs to edit the cryptroot file and configure it to stop the boot sequence when the number of password guesses has been exhausted. We have to think patches throughout the Linux community will be in full swing soon, but in the meantime, admins may want to take matters into their own hands.
Update, 11/18/16 - 4:11PM: As some readers have pointed out, it should be noted that encrypted data remains unexposed and secure in spite of this vulnerability.
In less time than it takes to microwave a bag of popcorn, an attacker could compromise a Linux machine with potentially serious consequences. The vulnerability that makes it possible lies in Cryptsetup and the scripts it uses to unlock the system partition when it's been encrypted using LUKS (Linux Unified Key Setup). Many Linux distributions use this.
How serious is it really? The researchers say that generally speaking, if an attacker has physical access to a system then it is "game over."
"This vulnerability allows [attackers] to obtain a root initramfs shell on affected systems. The vulnerability is very reliable because it doesn't depend on specific systems or configurations... This vulnerability is specially [sic] serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect [sic] (password in BIOS and GRUB) and we only have a keyboard or/and a mouse," note Hector Marco and Ismael Ripoll, the security researchers who discovered the vulnerability.
The fault that triggers the exploit is in the script file /scripts/local-top/cryptroot. Once the user exceeds the maximum number of password attempts (the default is 3), the boot sequence continues and calls up a local script that treats the error as if it's a device that needs more time to warm up. The boot script then tries to cover/mount what it thinks is a failing device. When the maximum number of attempts is reached, it drops a shell to the user.
"The attacker just have [sic] to press and keep pressing the [Enter] key at the LUKS password prompt until a shell appears, which occurs after 70 seconds approx," the researchers say.
Ready for the bombshell? While this is far easier to exploit when having physical access to a Linux machine, it isn't necessarily required. In cloud environments, it is possible to remotely exploit the vulnerability. That's bad news for Ubuntu, which is the most popular Linux OS in the cloud.
The good news is this is an easy exploit to fix. A user just needs to edit the cryptroot file and configure it to stop the boot sequence when the number of password guesses has been exhausted. We have to think patches throughout the Linux community will be in full swing soon, but in the meantime, admins may want to take matters into their own hands.
Update, 11/18/16 - 4:11PM: As some readers have pointed out, it should be noted that encrypted data remains unexposed and secure in spite of this vulnerability.
