Rebootless Patches for ‘BleedingTooth’ are on the Way
Google security researchers recently found a flaw in the way the Linux kernel’s Bluetooth implementation handled L2CAP packets with A2MP CID. A remote attacker in range could use this flaw to crash a targeted system causing a denial-of-service or potentially execute arbitrary code on the system by sending a specially crafted L2CAP packet. All Linux distributions are affected, but the exploit is only possible if you have devices connected via Bluetooth to your infrastructure.
Our data center clients could be asking why a Bluetooth vulnerability is a critical issue when the attacker must be in range of the targeted system, but it’s likely that you have surveillance cameras, smart TVs, wireless printers and other endpoints that would be vulnerable to ‘BleedingTooth’. Intel suggests patching servers with vendor updates, but this method requires a reboot of the server. KernelCare is releasing security patches for ‘BleedingTooth’ that will not require server reboots, so critical infrastructure including IoT devices can be patched within a small window of vulnerability without interrupting services and affecting SLAs.
What is ‘BleedingTooth’?
‘BleedingTooth’ is not tracked by just one CVE but several, namely CVE-2020-12351, CVE-2020-12352, and CVE-2020-24490. The most significant of these three rated a severity score of 8.3 is CVE-2020-12351. It’s a recent finding, so little is known about the vulnerability to date and the reserved CVEs have not been detailed, but it’s critical enough that Intel and Linux vendors suggest patching immediately. All Linux distributions are affected, so any device or server running an unpatched version is vulnerable.
Using a maliciously crafted L2CAP packet used in Bluetooth communication, an attacker could cause a denial-of-service (DoS) or execute code on the target system. Intel is warning that the exploit can lead to privilege escalation as well. The attacker must know the bd address (BD_ADDR), which is a 48-bit identifier assigned to each Bluetooth device. A proof-of-concept exploit code can be found on Github.
In CVE-2020-12352, Google researchers indicate that encryption keys and other sensitive data could be obtained by predicting memory layouts to defeat KASLR (Kernel Address Space Layout Randomization). A proof-of-concept was also provided to demonstrate the issue.
Only devices using Bluetooth 5 chips are vulnerable, but attackers can use malicious chips to exploit the vulnerability. BlueZ is the protocol library responsible for the vulnerability, and its developers announced patches for all three CVEs or users can update their Linux kernel versions to 5.9. Any version prior to 5.9 is vulnerable.
Any Mitigation Techniques Available?
Individuals running personal Linux-based devices with Bluetooth can disable it for now, but this isn’t a viable option for enterprise devices. Other than disabling Bluetooth, no other methods are available to mitigate the issue other than applying the necessary security patches immediately. Released vendor patches, however, require a server reboot. Enterprise servers cannot be indiscriminately reboot, which means administrators must perform emergency maintenance or wait for a scheduled change. Waiting to apply security patches then leaves servers vulnerable to exploits, which puts the company at risk. KernelCare’s patches soon to be released will not require a reboot, and all KernelCare customers will receive necessary security updates to remediate ‘BleedingTooth’.
Although this vulnerability might seem unimportant to an enterprise client, it’s even more crucial that they patch Linux due to the numerous shadow endpoints available in a large network environment. Statements made by security researchers indicate that updates to the Linux kernel is the only option, which requires a reboot and interruption of service. KernelCare’s live patching service will be deploying necessary security patches that will not require a reboot. You can sign up for a 7-day trial of KernelCare+ and get the rebootless updates early next week. To find out right away when the patch is available, you can monitor this blog post on our Twitter and Facebook accounts.