Linux 5.9.1 And Older Stable Kernel Updates Fixing "Bleeding Tooth" Bluetooth Vulnerability Are Available
BleedingTooth is a remote code execution vulnerability affecting all Linux kernels going back to Linux 4.8. It allows an attacker within Bluetooth range to execute code on remote systems if Bluetooth is turned on the remote system and it's set to be discoverable thanks to a combination of security issues in the BlueZ library and heap-based type confusion on the Linux kernels L2CAP code.
written by 林慧 (Wai Lin) 2020-10-19 - last edited 2021-02-23. © CC BY
The BleedingTooth Bluetooth vulnerability in action.
BleedingTooth is a really bad and very serious Linux kernel vulnerability. It allows someone within Bluetooth range to potentially execute code on your Linux machine thanks to a combination of improper input validation, improper buffer restrictions and improper access control in the BlueZ libraries and heap-based type confusion in the Linux kernel's L2CAP code.
Linux 5.9.1 as well as updates to the older "stable" kernel series (5.8.16, 5.4.72, 4.19.152, 4.14.202, 4.9.240, and 4.4.240) have been released with a patch by Intel's Luiz Augusto von Dentz addressing the Linux kernel side of the BleedingTooth vulnerability. You should upgrade to one of those if your machine has a Bluetooth adapter (most laptops do). The patch is described as:
"Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel
Only sockets will have the chan->data set to an actual sk, channels like A2MP would have its own data which would likely cause a crash when calling sk_filter, in order to fix this a new callback has been introduced so channels can implement their own filtering if necessary."
The vulnerability in the Linux kernel's L2CAP code has been present since commit dbb50887c8f61 titled "Bluetooth: split sk_filter in l2cap_sock_recv_cb" , written by Daniel Borkmann, was introduced in July 2016. All Linux versions from 4.8 to 5.9, except for the latest minor versions of those kernels that were released this weekend, are affected.
No new version of the BlueZ libraries have been released. The latest BlueZ release, version 5.54 as of today, was released in March 2020.
Before you panic and double-check if your Linux system runs rfkill block bluetooth when you login: An attacker does have to be fairly close to you to exploit this and the device needs to be discoverable.
Google's Francis Perron has published proof of exploit code called "BadKarma". Running that code does absolutely nothing if Bluetooth is enabled on a vulnerable Linux machine unless it is set to be discoverable accept inquiry scans (all you get is "connect: Connection refused"). You can check if Bluetooth on a Linux machine is discoverable by running:
sudo sh -c "hciconfig -a hci0 | grep -i 'PSCAN *ISCAN'"
That command will either output nothing or UP RUNNING PSCAN ISCAN (you can also simply run hciconfig, total output is just a few lines). ISCAN is the important bit.
If you grabbed Francis Perron's fine proof of concept exploit code and you'd like to test it against a remove then you can run:
sudo hciconfig hci0 piscan
on the machine you'd like to p0wn to ensure that a host is vulnerable (it can be disabled with hciconfig hci0 noscan). Type hciconfig to see the machines Bluetooth address and it's Bluetooth status.
Francis Perron's proof of concept code needs to be executed as root. The syntax is, once you compiled it, as simple as ./poc xx:xx:xx:xx:xx:xx.
Nothing particularly bad happens when that particular proof of concept exploit code is executed against a machine with Linux 5.9.0:
Machine running Linux 5.9.0 after being hit with a malicious L2CAP packet.
Linux 5.9.0 responds to a malicious L2CAP by logging a panic in the ring buffer (what you see if you type sudo dmesg). Bluetooth stops working and a refusal to reboot or power-off without hitting the physical off-switch or reset button appears to be all the negative side-effects of that exploit. Nothing interesting happens if the target machine is running Linux 5.9.1.
There is YouTube video demonstrating "Linux Bluetooth Zero-Click Remote Code Execution". There's no code or useful information linked below that video, but it does show that this can be used to execute code on vulnerable machines.
You should upgrade your Linux kernel to 5.9.1, 5.8.16, 5.4.72, 4.19.152, 4.14.202, 4.9.240 or 4.4.240, depending on what kernel branch you are using, if your machine a Bluetooth adapter. Exploiting your machine requires that you have a Bluetooth adapter that is both turned on (rfkill unblock bluetooth) and set to be discoverable (sudo hciconfig hci0 piscan). That is the case if you use GNOME or the blueberry Bluetooth manager. It is configurable in KDE and it is off unless you change that in blueman (blueman-applet). You can run hciconfig (part of the bluez package) and check. You should upgrade your kernel regardless of what Bluetooth manager you are using, there is a slim chance that someone close to you will try to exploit you when you happen to turn Bluetooth on and make it discoverable even if you use one of the Bluetooth managers that disable discovery by default. Broadcasting your Bluetooth device's address is generally a bad idea so you may want to check what your Bluetooth manager does irrespective of this particular exploit.
Enable comment auto-refresher