BleedingTooth: Intel Discloses Early, Angering Linux Lovers

A researcher discovered a high-severity vulnerability in the Linux Bluetooth stack. He reported it privately to the stack’s maintainer, Intel, dubbing it BleedingTooth (not to be confused with the fungus of the same name).

However, despite Intel promising coordinated disclosure—to publicly disclose security vulnerabilities only after mitigations are available—the company released the news before fixes were available in the released kernel. Intel further confused everyone by initially saying the fixes were already in Linux 5.9—which they’re not.

The key bug is CVE-2020-12351, with a CVSS score of 8.3, introduced in Linux 4.8 and up. There are a couple of related medium-severity flaws, too.

Of course, you can’t be hacked if you’re not within Bluetooth range. In today’s SB Blogwatch, we can see another reason for social distancing.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Debunking viral BS.


Intel Disclosure FAIL

What’s the craic? Liam Tung reports—“Google warns of severe ‘BleedingTooth’ Bluetooth flaw”:

 Linux 5.9 was just released two days ago and Intel is recommending in its advisory for the high-severity Bluetooth flaw, CVE-2020-12351, to update the Linux kernel [again]. … Google has also published proof-of-concept exploit code for the BleedingTooth vulnerability.

[Intel’s] BlueZ is found on Linux-based IoT devices and is the official Linux Bluetooth stack. [It] contains several Bluetooth modules including the Bluetooth kernel subsystem core, and L2CAP and SCO audio kernel layers.

Is it serious? Dan Goodin says yes—“Yes, it’s serious, but high severity doesn’t necessarily mean high risk”:

 Besides Linux laptops, [BlueZ] is used in many consumer or industrial Internet-of-things devices. It works with Linux versions 2.4.6 and later.

The lack of details aside, there’s not much reason for people to worry about [it]. … BleedingTooth requires proximity to a vulnerable device. It also requires highly specialized knowledge and works on only a tiny fraction of the world’s Bluetooth devices.

The lack of real-world risk is a good thing. Many IoT devices receive few if any security updates, making it likely that many devices used in both homes and businesses will remain vulnerable to BleedingTooth for the rest of the time they’re used. Many of these devices were likely already vulnerable to BlueBorne and several other security bugs that have bitten Bluetooth in the past.

Who found it? Andy Nguyen—@theflow0:

 BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution. … Research was inspired by @BenSeri87’s BlueBorne.

BleedingTooth is a set of zero-click vulnerabilities in the Linux Bluetooth subsystem that can allow an unauthenticated remote attacker in short distance to execute arbitrary code with kernel privileges on vulnerable devices.

What’s Intel doing about it? Here’s a po-faced advisory—“BlueZ Advisory”:

 Potential security vulnerabilities in BlueZ may allow escalation of privilege or information disclosure. BlueZ is releasing Linux kernel fixes to address these potential vulnerabilities.

CVE-2020-12351: … Improper input validation in BlueZ may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access.
CVSS Base Score: 8.3 High.
CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H.

Affected Products: All Linux kernel versions that support BlueZ. … Intel, and nearly the entire technology industry, follows a disclosure practice called Coordinated Disclosure, under which a cybersecurity vulnerability is generally publicly disclosed only after mitigations are available.

But that doesn’t really seem to be true. The latest released kernel doesn’t include the fix, so how can Intel claim mitigations are available or that the disclosure was coordinated? Seriously, a few code diff fragments do not a mitigation make. Matthew Garrett—@mjg59—is proper pissed:

 Intel just disclosed a bunch of Linux Bluetooth vulnerabilities … but:
1) Despite claiming the fixes are in 5.9, they aren’t,
2) Distributions weren’t notified, so didn’t have backported patches ready to release.

Almost exactly the same thing happened earlier this year: [CVE-2020-0556] was disclosed [by Intel] before fixes … and distributions weren’t notified.

What the ****?

Okay, but I don’t use Linux. bill_mcgonigle teaches lessons we should all learn:

 This is a recurring and very dangerous problem. Bluetooth and Wi-Fi are done in secret by an industry consortium and they’re always broken (Wi-Fi 6 is insecure out of the gate). … The IETF and RFC process is done in the open and the results are much, much better.

We’re on, what, Bluetooth 5 and it’s still a ****show trying to get things reliably paired? We need a strategy for forcing these standards into the open or replacing them with something else that’s open.

Or perhaps I do: Android is based on Linux, so should I panic? No, says afidel:

 Google had some issues with [BlueZ] and so they implemented Bluedroid in 4.2 and then switched the name to Fluoride. For Android 11 there was a new experimental stack called Gabeldorsche but I don’t think it made it through to final build, but it will likely be switched for 12.

Just get rid of Bluetooth, suggests ThromaLek:

 I have two audio devices that don’t exhibit the gamut of annoying and stupid behaviour that’s made the very word Bluetooth a source of vicious mirth. … Every other Bluetooth device I’ve seen used or had used … has been an unreliable source of frustration and anger.

It didn’t take many iterations of this … to lead to all Bluetooth stacks being disabled on every device we have in the house. … We’re happier pretending it doesn’t exist, and the sense of calm that pervades from we who have discarded it seems to be infecting other family members.

And charliebird agrees:

 I’m guessing the opportunity to exploit this is low, since almost no one can ever get Bluetooth to actually work in Linux.

Meanwhile, willy_me makes me a sandwich:

 sudo systemctl disable bluetooth … finally, a use for systemd.

And Finally:

Hilariously bad content-farm fakery

Previously in And Finally


You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: Bleeding Tooth fungus Hydnellum peckii by Bernypisa (cc:by-sa)

Richi Jennings

Richi Jennings is a foolish independent industry analyst, editor, and content strategist. A former developer and marketer, he’s also written or edited for Computerworld, Microsoft, Cisco, Micro Focus, HashiCorp, Ferris Research, Osterman Research, Orthogonal Thinking, Native Trust, Elgan Media, Petri, Cyren, Agari, Webroot, HP, HPE, NetApp on Forbes and CIO.com. Bizarrely, his ridiculous work has even won awards from the American Society of Business Publication Editors, ABM/Jesse H. Neal, and B2B Magazine.

richi has 596 posts and counting.See all posts by richi