Blueborne - Linux Kernel Remote Denial of Service in Bluetooth subsystem - CVE-2017-1000251
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
Impacted Products
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise MRG 2
Products that 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.
Attack Description and Impact
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.
Take Action
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?
Product | Package | Advisory |
---|---|---|
Red Hat Enterprise Linux 7 | kernel | RHSA-2017:2679 |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2017:2704 |
Red Hat Enterprise Linux 7.3 Extended Update Support* | kernel | RHSA-2017:2680 |
Red Hat Enterprise Linux 7.2 Extended Update Support* | kernel | RHSA-2017:2706 |
Red Hat Enterprise Linux 6 | kernel | RHSA-2017:2681 |
Red Hat Enterprise Linux 6.7 Extended Update Support* | kernel | RHSA-2017:2682 |
Red Hat Enterprise Linux 6.6 Advanced Update Support** | kernel | RHSA-2017:2731 |
Red Hat Enterprise Linux 6.5 Advanced Update Support** | kernel | RHSA-2017:2707 |
Red Hat Enterprise Linux 6.4 Advanced Update Support** | kernel | RHSA-2017:2683 |
Red Hat Enterprise Linux 6.2 Advanced Update Support** | kernel | RHSA-2017:2732 |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2017:2705 |
**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.
# 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
On RHEL 6 execute the following commands as root:
# rmmod bnep
# rmmod bluetooth
# rmmod btusb
Ansible Playbook
5 Comments
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full access
Log InNew to Red Hat?
Learn more about Red Hat subscriptions
I ran the check script and it complains about the kernel being vulnerable. I do not have the bluetooth package installed. Here is the output Detected kernel package is '2.6.32-696.3.2.el6.x86_64'. This kernel version is vulnerable. Vulnerable kernel modules are not loaded and vulnerability is not currently exploitable. However, loading of vulnerable kernel modules is not disabled and the system can become vulnerable at any moment. Either update kernel package or apply mitigation (disable loading of vulnerable kernel modules) and restart the system.
I did a service bluetooth status sudo service bluetooth status bluetooth: unrecognized service
If the package is not installed and I don't update the kernel at this point why do i need to apply mitigation (disable loading of vulnerable kernel modules).
A couple of more checks in the script wouldn't have hurt to tell me if bluetooth package was installed or not. Then at that time you can decide whether or not to apply the mitigation steps.
Get feedback, thanks Larry! I'll pass that over to our DevOps team that build and manage those scripts and get them to add some additional checks/notices.
Just let the script check the system and auto apply the fix accordingly
Hi Larry, sorry for the delay in our response. As the vulnerability is in kernel modules and not Bluetooth service/package, I believe that the script reports the risk correctly. There are different ways how the kernel module can be loaded, e.g.: 1) modprobe command 2) Bluetooth modules are automatically loaded when collecting tcpdump (https://access.redhat.com/solutions/1131343)
Are we talking about servers or mobile devices? How likely is it, that - in regard to servers - a bluetooth module is built in? Or do I get something completely wrong here?