Researcher says his findings ultimately led to a safer, more stable kernel
UPDATED 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.
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.
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’
“As I was conducting the research, I kept imagining myself as an attacker sitting at a local coffee shop or library and gaining full access to devices of the users around me, and how harmful that could be,” Andy Nguyen told The Daily Swig.
“I am still surprised that the code had not been tested at all, given that simply trying to reach the A2MP would cause a crash (BadKarma). To date the impact of my research has resulted in an entire protocol (which was obsolete) being disabled.
“It is my hope that in the future, distros will use these findings as a datapoint for enabling certain mitigations such as initializing the stack/heap to prevent future information leaks.”
Nguyen 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 the researcher.
In February, Google and the Linux Foundation announced plans to fund two full-time maintainers who will focus on strengthening kernel security and associated initiatives.
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.
This article was updated on April 19 with additional comments from Andy Nguyen of Google.