Blueborne - Linux Kernel Remote Denial of Service in Bluetooth subsystem - CVE-2017-1000251

Public Date: September 8, 2017, 14:10
Updated September 29, 2017, 10:18 - Chinese, Simplified Japanese
Resolved Status
Important Impact
Red Hat Product Security has been made aware of a vulnerability affecting the Linux kernel's implementation of the Bluetooth Host L2CAP protocol. The vulnerability has been assigned CVE-2017-1000251. This issue was publicly disclosed on September 12th, 2017 and is rated as Important.

Background Information

The Logical Link Control and Adaptation Layer Protocol (L2CAP) works at the data link layer in the Bluetooth stack. It provides services such as connection multiplexing, segmentation and reassembly of packets for upper layer protocols such as Bluetooth. It facilitates higher level protocols to transmit and receive L2CAP data packets to and from clients.

A stack buffer overflow issue was found in the way the Linux kernel's Bluetooth subsystem processed the pending configuration packets received from a client. As a result, a client could send arbitrary L2CAP configuration parameters which were stored in a stack buffer object. These parameters could exceed the buffer length, overwriting the adjacent kernel stack contents. This exchange occurs, prior to any authentication, when establishing a Bluetooth connection. An unauthenticated user, who is able to connect to a system via Bluetooth, could use this flaw to crash the system or potentially execute arbitrary code on the system, if the kernel stack protection feature (CONFIG_CC_STACKPROTECTOR=y) is not enabled.

Acknowledgments

Red Hat would like to thank Armis Labs for reporting this issue.

Impacted Products

Red Hat Product Security has rated this update as having a security impact of Important.

The following Red Hat product versions are impacted:
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise MRG 2
It is important to note that Red Hat Enterprise Linux 6 and 7 on the PPC64 architecture are exposed to this issue as a potential remote code execution vulnerability, due to it not being built with stack protection. Kernel stack protection reduces the risk of remote code execution, so with that protection not present, it is possible that an unauthenticated attacker could execute remote code on a Red Hat Enterprise Linux 6 and 7 PPC64 server if the Bluetooth service is running and modules are loaded. Because Red Hat Enterprise Linux 6 and 7 on PPC64 are not provided in the Workstation variant for RHEL, this may be a concern for servers with Bluetooth hardware and which have installed the bluez package. Note that in the default Server install, the bluez package is not installed, so the bluetooth.service unit file (and bluetoothd) are not present.

Products that are not Impacted

For a successful attack, the flaw requires that the vulnerable Bluetooth kernel modules are loaded and the bluetoothd service is running.

The following Red Hat product versions are not impacted:
  • RHEL Atomic Host, while shipping with the vulnerable Bluetooth modules, does not ship with the bluetoothd service, so is not vulnerable.
  • Red Hat Enterprise Linux 6 and 7 on s390x do not build the vulnerable Bluetooth modules, so are not vulnerable.
  • Red Hat Enterprise Linux 5 uses an earlier version of the Bluetooth subsystem within the kernel that does not have the flaw present, so is not vulnerable.
While Red Hat's Linux Containers are not directly impacted by kernel issues such as this flaw in the Bluetooth module, Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of your containers.

Attack Description and Impact

A stack buffer overflow flaw was found in the way the Bluetooth subsystem of the Linux kernel processed pending L2CAP configuration responses from a client. On systems with the stack protection feature enabled in the kernel (CONFIG_CC_STACKPROTECTOR=y, which is enabled on all architectures other than s390x and ppc64[le]), an unauthenticated attacker able to initiate a connection to a system via Bluetooth could use this flaw to crash the system. Due to the nature of the stack protection feature, code execution cannot be fully ruled out, though we believe it is unlikely. On systems without the stack protection feature (ppc64[le]; the Bluetooth modules are not built on s390x), an unauthenticated attacker able to initiate a connection to a system via Bluetooth could use this flaw to remotely execute arbitrary code on the system with ring 0 (kernel) privileges. This class of flaw is commonly referred to as a Buffer Overflow issue. It is generally exploited by writing arbitrary code beyond the allocated buffer area and then executing that code by other means like misleading a function return pointer. An attacker would need to be in proximity to a vulnerable system in order to connect via the Bluetooth protocol.

Diagnose your vulnerability

If Bluetooth hardware is present on your system and the Bluetooth service is enabled and active, it is vulnerable to this flaw. More specifically, the flaw resides within the bluetooth.ko kernel module code, so a system is vulnerable when this module is loaded.

Determine if your system is vulnerable

Use the detection script below to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well. The current version of the script is 1.1.

Download Detection Script

Take Action

All Red Hat customers running affected versions of the kernel are strongly recommended to update the kernel as soon as patches are available. Details about impacted packages as well as recommended mitigation are noted below. A system reboot is required in order for the kernel update to be applied.

Updates for Affected Products

A kpatch for customers running Red Hat Enterprise Linux 7.2 or greater will be available. Please open a support case to gain access to the kpatch.

For more details about what a kpatch is: Is live kernel patching (kpatch) supported in RHEL 7?

ProductPackageAdvisory
Red Hat Enterprise Linux 7kernelRHSA-2017:2679
Red Hat Enterprise Linux 7kernel-rtRHSA-2017:2704
Red Hat Enterprise Linux 7.3 Extended Update Support*kernelRHSA-2017:2680
Red Hat Enterprise Linux 7.2 Extended Update Support*kernelRHSA-2017:2706
Red Hat Enterprise Linux 6kernelRHSA-2017:2681
Red Hat Enterprise Linux 6.7 Extended Update Support*kernelRHSA-2017:2682
Red Hat Enterprise Linux 6.6 Advanced Update Support**kernelRHSA-2017:2731
Red Hat Enterprise Linux 6.5 Advanced Update Support**kernelRHSA-2017:2707
Red Hat Enterprise Linux 6.4 Advanced Update Support**kernelRHSA-2017:2683
Red Hat Enterprise Linux 6.2 Advanced Update Support**kernelRHSA-2017:2732
Red Hat Enterprise MRG 2kernel-rtRHSA-2017:2705
*An active EUS subscription is required for access to this patch.

Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.

**An active AUS subscription is required for access to this patch in RHEL AUS.

Mitigation

Generally kernel stack memory corruption could be easily leveraged to execute arbitrary code with kernel ring 0 (ie. root) privileges on a system. RHEL kernels are hardened with gcc compile time options which protect against such memory corruption. The gcc -fstack-protector option adds a canary value at the beginning of a function and before the function return address. The -fstack-protector-strong extends the canary protection around local stack variables including arrays of any type and length. While copying data to these stack variables, the kernel validates the canary value to detect any memory corruption and thwarts the impending attack by a kernel panic.

The Bluetooth kernel modules (bluetooth, btusb, bnep) are automatically loaded when the system boots and the Bluetooth service is enabled. The kernel modules can be prevented from being loaded by using system-wide modprobe rules. Run the following commands to blacklist the Bluetooth modules, thus preventing them from loading if Bluetooth hardware is present:
# echo "install bnep /bin/true">> /etc/modprobe.d/disable-bluetooth.conf
# echo "install bluetooth /bin/true">> /etc/modprobe.d/disable-bluetooth.conf
​# echo "install btusb /bin/true">> /etc/modprobe.d/disable-bluetooth.conf

Additionally, once the kernel modules are disabled, if you have the bluez (Bluetooth utilities) package installed you will want to have the Bluetooth service disabled at startup. On RHEL 7 execute the following commands as root:

# systemctl disable bluetooth.service
# systemctl mask bluetooth.service
# systemctl stop bluetooth.service

On RHEL 6 execute the following commands as root:

# service bluetooth stop
# chkconfig bluetooth off

NOTE: If the above kernel modules are already loaded, you can manually unload them with the rmmod command. Depending on what Bluetooth hardware is discovered on the system, there is expected to be slight variations on which Bluetooth modules are loaded. The rmmod command will display information about additional Bluetooth modules loaded when attempting to use it. You will want to rmmod any additional Bluetooth modules it notifies you are also loaded. Execute the following as root to unload these modules from the running kernel:

# rmmod bnep
# rmmod bluetooth
# rmmod btusb
    If further assistance is needed, see this Solution or contact Red Hat Global Support Services.

    Ansible Playbook

    An Ansible playbook is available. To verify the legitimacy of the script, you can download the detached GPG signature as well.

    This will mitigate the vulnerability by performing a "fake install" to prevent the vulnerable modules from loading by creating a blacklist file at /etc/modprobe.d/disable-bluetooth.conf. It will also disable the Bluetooth service if it is present. If any Bluetooth modules are already loaded into the running kernel and cannot be removed, it will reboot the system. With the blacklist file in place, this will ensure the modules are not loaded. After a fixed package is available and installed, you can remove the file at /etc/modprobe.d/disable-bluetooth.conf if desired.

    The playbook runs against a variable named HOSTS, and can be invoked as follows (assuming 'hostname' is defined in your inventory file):
    # ansible-playbook -e HOSTS=hostname cve-2017-1000251-mitigation.yml
     This playbook requires root privileges and specifies 'become: true', so you will need to use an account with appropriate permissions.

    Comments