Bug 1395134 (CVE-2016-4484) - CVE-2016-4484 dracut: Brute force attack on LUKS password decryption via initramfs
Summary: CVE-2016-4484 dracut: Brute force attack on LUKS password decryption via init...
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2016-4484
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1395135 1395949 1395950 1395951 1395952
Blocks: 1393478
TreeView+ depends on / blocked
 
Reported: 2016-11-15 09:13 UTC by Adam Mariš
Modified: 2021-02-17 03:02 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A password-check vulnerability was found in the way initramfs, generated by dracut, handles the decryption of LUKS-encrypted data partitions. An attacker having physical access to the machine or access to the boot console may be able to brute-force the LUKS password using the dracut shell, and may be able to copy off the encrypted partition for an offline brute-force attack or, in certain conditions, install malicious boot images in the /boot partition.
Clone Of:
Environment:
Last Closed: 2016-12-08 08:40:36 UTC
Embargoed:


Attachments (Terms of Use)

Description Adam Mariš 2016-11-15 09:13:35 UTC
A vulnerability in Cryptsetup, concretely in the scripts that unlock the system partition when the partition is ciphered using LUKS (Linux Unified Key Setup) was found. The fault is caused by an incorrect handling of the password check in the script file /scripts/local-top/cryptroot. This vulnerability allows to obtain a root initramfs shell on affected systems. Attackers can copy, modify or destroy the hard disc as well as set up the network to exflitrate data.

Public via:

http://seclists.org/oss-sec/2016/q4/427

External References:

https://access.redhat.com/articles/2786581
http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html

Comment 1 Adam Mariš 2016-11-15 09:14:15 UTC
Created cryptsetup tracking bugs for this issue:

Affects: fedora-all [bug 1395135]

Comment 2 Huzaifa S. Sidhpurwala 2016-11-15 10:12:51 UTC
Statement:

In Red Hat Enterprise Linux and Fedora, the scripts used during boot time to ask for user password and decrypt the drive are part of the dracut package. They used to generate the Initial ramdisk (initramfs) and are a part of the initramfs image file.

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.

Red Hat Product Security encourages users of Red Hat Enterprise Linux 6 and 7 to use the mitigation described in the link below. No updated packages are currently available.

For more information please refer to: https://access.redhat.com/articles/2786581

Comment 5 Huzaifa S. Sidhpurwala 2016-11-18 09:37:04 UTC
Mitigation:

Versions of dracut package shipped with Red Hat Enterprise Linux 6 and 7 support kernel command line options which allow a shell to be presented when it is not able to mount the root device. (As in case of a failed root partition decryption attempt by cryptsetup, when wrong password is entered multiple times).

In Red Hat Enterprise Linux 6, this is enabled by "rdshell" option on the kernel command line. However default installs do not enable this option. Hence when several attempts to decrypt the root partition fails, it will cause a kernel panic.

In Red Hat Enterprise Linux 7, this is enabled by the "rd.shell" option. Default behavior here is to drop to a shell when root device mount fails, which can be disabled by adding "rd.shell=0" to the kernel command line. 

In either of the cases, a user having access to the grub console, can edit the kernel command line and re-enable his access. Red Hat Product Security Team strongly advocates enabling grub passwords as well BIOS passwords to protect against this.


Note You need to log in before you can comment on or make changes to this bug.