|
|
Subscribe / Log in / New account

BleedingTooth: critical kernel Bluetooth vulnerability

[Posted October 14, 2020 by jake]

Several flaws in the BlueZ kernel Bluetooth stack prior to Linux 5.9 are being reported by Intel and by Google (GHSA-h637-c88j-47wq, GHSA-7mh3-gq28-gfrq, and GHSA-ccx2-w2r4-x649). They are collectively being called "BleedingTooth", and more information will be forthcoming, though there is already a YouTube video demonstrating remote code execution using BleedingTooth.
to post comments

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 17:55 UTC (Wed) by Liskni_si (guest, #91943) [Link] (6 responses)

None of these patches are in 5.8.15 or any other recent stable kernel and I can't find them mentioned anywhere in stable@vger.k.o. Who do we need to ping to make them go to stable?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 18:36 UTC (Wed) by compudj (subscriber, #43335) [Link] (5 responses)

I just informed Greg KH privately about it. He was not made aware of these issues prior to now. What's up with Intel and Google's security disclosure process ?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 20:31 UTC (Wed) by compudj (subscriber, #43335) [Link] (4 responses)

Actually, looking at Linus' master branch (and v5.9), only

commit a2ec905d1e16 ("Bluetooth: fix kernel oops in store_pending_adv_report") appears to have reached upstream.

All fixes from Intel don't even appear in master, even less in v5.9:

https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...
https://lore.kernel.org/linux-bluetooth/20200806181714.32...

It appears that Intel's security advisory is wrong when saying "Intel recommends updating the Linux kernel to version 5.9 or later."

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 6:32 UTC (Thu) by mkubecek (guest, #130791) [Link]

It's not really surprising that the fixes are not in 5.9 final as they have been applied to bluetooth-next tree, then merged into net-next on September 29th and have been quietly waiting there for the merge window since. As fixes - and even more so as important security ones - they should have been handled via bluetooth and net trees.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 14:30 UTC (Sun) by gotti79 (guest, #142593) [Link] (2 responses)

Thanks for the patches I looked into them and found a issue with one:

https://lore.kernel.org/linux-bluetooth/20200806181714.32...

Here the part
@@ -376,6 +383,8 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct sk_buff *skb,
struct a2mp_amp_assoc_rsp rsp;
rsp.id = req->id;

+ memset(&rsp, 0, sizeof(rsp));
+
if (tmp) {
rsp.status = A2MP_STATUS_COLLISION_OCCURED;
amp_mgr_put(tmp);

Seems to be wrong as they set rsp.id only to memset it to zero afterwards.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 15:29 UTC (Sun) by Liskni_si (guest, #91943) [Link] (1 responses)

A fix for this was posted 2 days ago: https://lore.kernel.org/linux-bluetooth/20201016180956.70..., together with something that appears to possibly be another important fix.
I see you posted a patch yourself: https://lore.kernel.org/linux-bluetooth/1603008332-8402-1..., perhaps the recipients of that should be directed towards Luiz's thread instead?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 18, 2020 18:29 UTC (Sun) by gotti79 (guest, #142593) [Link]

Seems that I was not the only one who found this somehow wrong. I only reacted as the former patch did go 1:1 into the current stable kernels 4.19.x, 5.4.x.... Which I feel not so good about.

I do some kernel stuff and the stable kernels are not as stable as they were before so instead of complaining and fixing the issues I tried sending a patch to mainline the better idea.

Thanks for the link to the other patch which I will also look into as I need to fix this issue for 5.4.x and 5.9.x at work anyways. I added the information to the kernel mailinglist so other know also of this.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 20:21 UTC (Wed) by nix (subscriber, #2304) [Link] (10 responses)

So... more or less every Android phone is vulnerable to one or more of these whenever bluetooth is powered, and these days it's usually on all the time because of covid-19 proximity detection. And most of them will no doubt not see security fixes for many months, if ever.

Wonderful.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 14, 2020 23:23 UTC (Wed) by seth.arnold (subscriber, #88398) [Link] (9 responses)

It is my understanding that Android's Bluetooth stack is unrelated to the Linux Bluetooth stack: https://9to5google.com/2020/02/19/android-11-dp1-gabeldor...

This is part of how Android phones have higher-quality codecs and protocols than Linux desktops.

Thanks

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 0:22 UTC (Thu) by khim (subscriber, #9252) [Link] (5 responses)

Well, the original motivation was to make sure there wouldn't be a “GPL contamination” in the Android userspace.

When it was first introduced it was, actually, inferior to BlueZ.

But of course with lots of testing and billions of phones …Android's implementation eventually become better.

Not even sure what's the morale of that story…

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 2:42 UTC (Thu) by pabs (subscriber, #43278) [Link] (3 responses)

Maybe "free software licenses don't matter because the economic power of the free software community is lower than corporate tech monsters"?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 8:29 UTC (Thu) by fatherlinux (subscriber, #93873) [Link] (2 responses)

I think that's right. When you are printing money from selling ads based on people's very well understood preferences, it's easy to spend money until something succeeds.

Also, the Fountain of Youth can extend your life indefinitely....

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 16, 2020 9:04 UTC (Fri) by cpitrat (subscriber, #116459) [Link] (1 responses)

> it's easy to spend money until something succeeds

And yet quite often Google gives up. Well, sometimes it gives up after it succeeds ...

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 16, 2020 13:27 UTC (Fri) by clump (subscriber, #27801) [Link]

Exactly. Google has its own interests in mind. Corporate backing can provide healthy support for projects. That said, just because a corporation is involved doesn't mean it cares about the ecosystem or the interests of its users.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 7:39 UTC (Thu) by bluss (guest, #47454) [Link]

Upstreaming implementations that have millions of users, would be a good idea, for this reason.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 10:42 UTC (Thu) by rvolgers (guest, #63218) [Link] (2 responses)

As others mentioned, it has a different bluetooth stack.

I am worried about all the little semi-embedded boards such as Raspberry Pi's that are easily overlooked... not sure if they are vulnerable by default though, or if bluetooth has to be enabled.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 12:47 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

I was under impression that BlueZ is _userspace_ part of the bluetooth stack. And the bugs found are in _kernel_ part, which is supposedly shared by all userspaces (BlueZ, Bluedroid, Fluoride, Gabeldorsche, etc…).
Am I wrong?

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 19, 2020 14:46 UTC (Mon) by WolfWings (subscriber, #56790) [Link]

There's quite a few bluetooth stacks that bypass the Linux kernel entirely, often using raw USB mode to directly grab the bluetooth dongle and have to have the relevant Linux kernel module blocked. BTstack is the most common "entirely userspace" one I've run across poking at car PC and other semi-embedded realms.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 15:52 UTC (Thu) by chder (subscriber, #96621) [Link] (9 responses)

Anyone know if there's a mitigation that's not just completely turning off bluetooth for Linux desktops (I specifically care about Fedora as a user with a bluetooth speaker).

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 15:56 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (2 responses)

Yeah, upgrade to kernel 5.9. For Fedora, you can get the one from Rawhide at the moment.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 21:19 UTC (Thu) by bojan (subscriber, #14302) [Link]

Also, new kernel builds for F31/32/33 are available.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 15, 2020 22:58 UTC (Thu) by chder (subscriber, #96621) [Link]

Other comments were suggesting 5.9 doesn't actually have most of the fixes and Intel even removed the kernel version to upgrade recommendation from their advisory since this morning.

Did Fedora get them backported? I guess I could go dig through Koji to see what got built.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 16, 2020 8:33 UTC (Fri) by maage (subscriber, #142306) [Link]

I got this now on Fedora 32:

Changelogs for kernel-5.8.15-201.fc32.x86_64, kernel-core-5.8.15-201.fc32.x86_64, kernel-devel-5.8.15-201.fc32.x86_64, kernel-modules-5.8.15-201.fc32.x86_64, kernel-modules-extra-5.8.15-201.fc32.x86_64
* to loka 15 00.00.00 2020 Justin M. Forbes <...> - 5.8.15-201
- Fix BleedingTooth CVE-2020-12351 CVE-2020-12352 (rhbz 1886521 1888439 1886529 1888440)

* ke loka 14 00.00.00 2020 Justin M. Forbes <...> - 5.8.15-200
- Linux v5.8.15
- Fix CVE-2020-16119 (rhbz 1886374 1888083)

* ke loka 07 00.00.00 2020 Justin M. Forbes <...> - 5.8.14-200
- Linux v5.8.14

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 17, 2020 12:15 UTC (Sat) by h2g2bob (subscriber, #130451) [Link] (4 responses)

No fix yet on Debian

https://security-tracker.debian.org/tracker/CVE-2020-12351

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 19, 2020 15:37 UTC (Mon) by bluss (guest, #47454) [Link] (3 responses)

There today https://lists.debian.org/debian-security-announce/2020/ms...

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 19, 2020 21:11 UTC (Mon) by wx (guest, #103979) [Link] (2 responses)

Am I correct in thinking that this only updates to 4.19.152 without further patches? If that is the case then this does not include the fix for the fix (https://lore.kernel.org/linux-bluetooth/20201016180956.70...) discussed above.

Neither another fix (https://lore.kernel.org/linux-bluetooth/20201016180956.70...) also referred to above.

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 20, 2020 8:44 UTC (Tue) by bluss (guest, #47454) [Link] (1 responses)

That the debian changelog link here doesn't work for non-standard updates (like security and NMU) is really quite strange and unhelpful. https://packages.debian.org/source/buster/linux

I looked at the diff and from what I can see, yes, the rsp.id = req->id being overwritten, is still an issue in 4.19.152-1

BleedingTooth: critical kernel Bluetooth vulnerability

Posted Oct 20, 2020 15:39 UTC (Tue) by pabs (subscriber, #43278) [Link]

The bug about security changelogs is here, seems unlikely to get fixed any time soon:

https://bugs.debian.org/490848


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds