If you use Debian or Ubuntu/ (probably many derived distributions are also vulnerable, but we have not tested), and you have encrypted the system partition, then your systems is vulnerable.
During the installation of Ubuntu, one of the first steps is to prepare the target partition (make partitions if needed, and/or format them). At this stage, the user is asked to "Encrypt the new (LXK)ubuntu installation for security". Nowadays, there is very little performance penalty working with an encrypted disk and it is an effective solution to protect data when the computer is not running. It is advisable to enable this feature.
If you didn't installed the system, the you can figure out the organization by running the blkid command.
$ blkid /dev/sda1: UUID="db96cdf9-99c3-4239-95f2-6af2651ef3ac" TYPE="ext2" /dev/sda5: UUID="d491bf52-a9ea-466f-be9b-3a5df954699e" TYPE="crypto_LUKS" /dev/mapper/sda5_crypt: UUID="30xz0y-4LeG-LwuL-QHI9-pWWi-BxHf-F3udoC" TYPE="LVM2_member" /dev/mapper/lubuntu--vg-root: UUID="53f95bd1-9e1c-4e23-9ff3-990d90c5cc92" TYPE="ext4" /dev/mapper/lubuntu--vg-swap_1: UUID="9eac532c-1b54-4cac-9995-b4b921222422" TYPE="swap" /dev/zram0: UUID="c2929c6e-2432-40ee-99a5-deadbeefa53e" TYPE="swap" /dev/zram1: UUID="d1bf1e22-dead-beef-9c49-e6462449d6e2" TYPE="swap" /dev/zram2: UUID="12a9232d-c62e-0df6-93ea-22ac3600bdf0" TYPE="swap" /dev/zram3: UUID="bf777ad3-13fc-4ad5-914b-002e67262939" TYPE="swap"
This is the classic structure where the partition "/dev/sda5" is encrypted and then used as a physical_volume in the "lubuntu-vg" volume_group which contains two logical_volumes: lubuntu--vg-root and lubuntu--vg-swap_1. As a result, the system and the swap partitions are encrypted by LUKS and protected by a single password. This system is vulnerable.
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:
The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/cryptroot. When the user exceeds the maximum number of password tries (by default 3), then boot sequence continues normally.
0#!/bin/sh . . . 171setup_mapping() 172{ . . . 273 # Try to get a satisfactory password $crypttries times 274 count=0 275 while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do 276 export CRYPTTAB_TRIED="$count" 277 count=$(( $count + 1 )) . . . 298 if [ ! -e "$NEWROOT" ]; then # cryptkeyscript = /lib/cryptsetup/askpass # cryptopen = /sbin/cryptsetup -T 1 # The user is asked the password and then passed to $cryptopen 299 if ! crypttarget="$crypttarget" cryptsource="$cryptsource" \ 300 $cryptkeyscript "$cryptkey" | $cryptopen; then 301 message "cryptsetup: cryptsetup failed, bad password or options?" 302 continue 303 fi 304 fi 305 . . . 342 #if [ -z "$FSTYPE" ] || [ "$FSTYPE" = "unknown" ]; then 343 if [ -z "$FSTYPE" ]; then 344 message "cryptsetup: unknown fstype, bad password or options?" 345 udev_settle 346 $cryptremove 347 continue 348 fi 349 350 message "cryptsetup: $crypttarget set up successfully" 351 break 352 done 353 # Always false -> never taken the if 354 if [ $crypttries -gt 0 ] && [ $count -gt $crypttries ]; then 355 message "cryptsetup: maximum number of tries exceeded for $crypttarget" 356 return 1 357 fi 358 359 udev_settle 360 return 0 361} . . . 402# Do we have any settings from the /conf/conf.d/cryptroot file? 403if [ -r /conf/conf.d/cryptroot ]; then 404 while read mapping <&3; do 405 setup_mapping "$mapping" 3<&- # Try to unlock each encrypted partition. 406 done 3< /conf/conf.d/cryptroot 407fi 408 409exit 0
The calling script, /scripts/local, handles the error as if it were caused by a slow device that needs more time to warm-up.
The booting scripts then tries to recover/mount the "failing" device, in the function local_deveice_setup(), multiple times (up to 30 times on an x86 system, and 150 on a powerpc machine). Every time the top level script tries to mount the encrypted partition (line 99 in /script/local), the user is allowed to try 3 more LUKS passwords. This gives a total of 93 password trials (on x86).
. . . 43local_device_setup() 44{ . . . 76 # If the root device hasn't shown up yet, give it a little while 77 # to allow for asynchronous device discovery (e.g. USB). We 78 # also need to keep invoking the local-block scripts in case 79 # there are devices stacked on top of those. 80 if ! real_dev=$(resolve_device "${dev_id}") || 81 ! get_fstype "${real_dev}" >/dev/null; then 82 log_begin_msg "Waiting for ${name} file system" 83 84 # Timeout is max(30, rootdelay) seconds (approximately) 85 case $DPKG_ARCH in 86 powerpc|ppc64|ppc64el) 87 slumber=180 88 ;; 89 *) 90 slumber=30 91 ;; 92 esac 93 if [ ${ROOTDELAY:-0} -gt $slumber ]; then 94 slumber=$ROOTDELAY 95 fi 96 97 while true; do 98 sleep 1 # local_block() calls to setup_mapping() 30 times, # trying to unlock LUKS root filesystem. 99 local_block "${dev_id}" 100 if real_dev=$(resolve_device "${dev_id}") && 101 get_fstype "${real_dev}" >/dev/null; then 102 wait_for_udev 10 103 log_end_msg 0 104 break 105 fi 106 slumber=$(( ${slumber} - 1 )) 107 if [ ${slumber} -eq 0 ]; then 108 log_end_msg 1 || true 109 break 110 fi 111 done 112 fi 113 114 # We've given up, but we'll let the user fix matters if they can 115 while ! real_dev=$(resolve_device "${dev_id}") || 116 ! get_fstype "${real_dev}" >/dev/null; do 117 echo "Gave up waiting for ${name} device. Common problems:" 118 echo " - Boot args (cat /proc/cmdline)" 119 echo " - Check rootdelay= (did the system wait long enough?)" 120 if [ "${name}" = root ]; then 121 echo " - Check root= (did the system wait for the right device?)" 122 fi 123 echo " - Missing modules (cat /proc/modules; ls /dev)" 124 panic "ALERT! ${dev_id} does not exist. Dropping to a shell!" 125 done 126 127 DEV="${real_dev}" 128} . . .
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.
The issue can be easily fixed by stopping the boot sequence when the number of password guesses has been exhausted. The following patch suspends the execution forever. The only way to exit is by rebooting the computer.
--- a/scripts/local-top/cryptroot 2016-07-29 10:56:12.299794095 +0200 +++ b/scripts/local-top/cryptroot 2016-07-29 11:00:57.287794370 +0200 @@ -273,6 +273,7 @@ # Try to get a satisfactory password $crypttries times count=0 + success=0 while [ $crypttries -le 0 ] || [ $count -lt $crypttries ]; do export CRYPTTAB_TRIED="$count" count=$(( $count + 1 )) @@ -349,12 +350,15 @@ fi message "cryptsetup: $crypttarget set up successfully" + success=1 break done - if [ $crypttries -gt 0 ] && [ $count -gt $crypttries ]; then - message "cryptsetup: maximum number of tries exceeded for $crypttarget" - return 1 + if [ $success -eq 0 ]; then + message "cryptsetup: Maximum number of tries exceeded. Please reboot." + while true; do + /bin/sleep 100 + done fi udev_settle
The panic function, which is the one that launches the shell, can prevent console access if the kernel is booted with the "panic" parameter.
69panic() 70{ 71 if command -v chvt >/dev/null 2>&1; then 72 chvt 1 73 fi 74 75 echo "$@" 76 # Disallow console access 77 if [ -n "${panic}" ]; then 78 echo "Rebooting automatically due to panic= boot argument" 79 sleep ${panic} 80 reboot 81 exit # in case reboot fails, force kernel panic 82 fi 83 modprobe -v i8042 || true 84 modprobe -v atkbd || true 85 modprobe -v ehci-pci || true 86 modprobe -v ehci-orion || true 87 modprobe -v ehci-hcd || true 88 modprobe -v uhci-hcd || true 89 modprobe -v ohci-hcd || true 90 modprobe -v usbhid || true 91 92 run_scripts /scripts/panic 93 94 REASON="$@" PS1='(initramfs) ' /bin/sh -i </dev/console >/dev/console 2>&1 95}
Therefore, adding the "panic" parameter to the kernel entry in the grub configuration will prevent a shell.
# sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="/GRUB_CMDLINE_LINUX_DEFAULT="panic=5 /' /etc/default/grub # grub-install
The direct cause of this vulnerability is the improper checking of the maximum number of passwords, but the bug was (probably) introduced by the addition of new features (in this case security features). It is well known that "Complexity is the worst enemy of security". A system with more features requires more code and has more interactions between sub-systems, which results in harder to test systems and so more bugs.
Security is a non-functional requirement which must be analyzed globally. In this case, the "recovery" actions taken in the case of system errors should be revised and updated to match the security requirements.
There are many "levels" of physical access. Just to mention a few:
These are some of the scenarios that where we can find a Linux system, but the IoT will increase the diversity further.
In order to protect the computer in these scenarios: the BIOS/UEFI has one or two passwords to protect the booting or the configuration menu; the GRUB also has the possibility to use multiple passwords to protect unauthorized operations.
In general, the GNU/Linux ecosystem (kernel, system apps, distros, ...) has been designed by developers for developers. Therefore, in the case of a fault, the recovery action is very "developer friendly", which is very convenient while developing or in controlled environments. But then Linux is used in more hostile environments, this helpful (but naive) recovery services shall not be the default option.
UEFI and GRUB contain two complete and very powerful shell facilities. Initrd system has powerful busybox with complete access to the network.
May be all this "just in case" functionality shall be remove, or seriously reconsidered, for the sake of security.
