Business
BleedingTooth: Google drops full details of zero-click Linux Bluetooth bug chain leading to RCE
A security researcher at Google has disclosed long-awaited details of zero-click vulnerabilities in the Linux Bluetooth subsystem that allow nearby, unauthenticated attackers “to execute arbitrary code with kernel privileges on vulnerable devices”.
Dubbed ‘BleedingTooth’, the trio of security flaws were found in BlueZ, the open source, official Linux Bluetooth protocol stack found on Linux-based laptops and IoT devices.
Google security engineer Andy Nguyen dropped a technical write-up on Twitter on April 6 that exhaustively recounts how he discovered and chained the bugs to achieve remote code execution (RCE) on a Dell laptop running Ubuntu 20.04.1 without ‘victim’ interaction – as demonstrated in the video below:
The achievement vindicates his decision to build on IoT security firm Armis’ uncovering of a raft of zero-day ‘BlueBorne’ vulnerabilities in 2017 that leveraged Bluetooth connections to seize control of even non-‘discoverable’ devices. (Armis later also unearthed the ‘BleedingBit’ Bluetooth chip flaws.)
“Research on the Bluetooth host attack surface” otherwise seemed mostly limited to firmware or specification flaws that enabled eavesdropping or information manipulation, observed the researcher.
BadKarma
The most severe vulnerability was a high severity (CVSS score 8.3) heap-based type confusion issue dubbed ‘BadKarma’ that was, said Nguyen, “quite easy to bypass”.
Providing they know the victim’s Bluetooth device address, a remote attacker positioned a “short distance” from the vulnerable device can “send a malicious l2cap packet and cause denial of service or possibly arbitrary code execution with kernel privileges”, according to a Google advisory published on October 13.
The privilege escalation flaw (CVE-2020-12351), which arises due to improper input validation, was found in the Logical Link Control and Adaptation Protocol (L2CAP), one of a number of Bluetooth modules incorporated into BlueZ.
The medium severity flaws, both assigned a CVSS of 6.5, were also exploitable by a nearby unauthenticated attacker.
The ‘BadChoice’ information disclosure bug (CVE-2020-12352) stemmed from improper access control, while the ‘BadVibes’ DoS flaw (CVE-2020-24490) arose from improper buffer restrictions.
Timeline
Nguyen discovered the flaws and conveyed the technical details to Intel, the maintainers of the Linux Bluetooth subsystem, in July 2020. A BadVibes fix was issued on July 30, and patches for BadChoice and BadKarma arrived on September 25.
However, the patches “weren’t included in any released Kernel versions” when the flaws were publicly disclosed by Google and Intel on October 13, said Nguyen. This prompted the researcher to reflect that “the Linux Kernel Security team should have been notified [at the outset] in order to facilitate coordination”.
The flaws were patched in Linux 5.10 kernel, issued on October 14, the day after public disclosure.
‘Safer and more stable kernel’
“I was happy that, as a result of this work, the decision was made to disable the Bluetooth High Speed feature by default in order to reduce the attack surface, which also meant the removal of the powerful heap primitive,” said Nguyen.
He also applied the findings to the syzkaller kernel fuzzer to enable fuzzing of the /dev/vhci device, which uncovered more than 40 additional bugs.
“Although most of these bugs were unlikely to be exploitable, or even remotely triggerable, they allowed engineers to identify and fix” a raft of “other weaknesses” and “as such contributed to having a safer and more stable kernel”, said Nguyen.
Shortly after the BleedingTooth disclosure, in September, it emerged (PDF) that billions of devices supporting BlueZ, Android’s Fluoride Bluetooth stack, and the iOS BLE stack were vulnerable to Bluetooth low energy spoofing attacks.
The Daily Swig has asked Andy Nguyen and the Linux kernel security team for further comment. We will update the article if and when we receive a response.