We have moved to a new Sailfish OS Forum. Please start new discussions there.

Critical Bluetooth Vulnerability in Android (CVE-2020-0022) Effect on SFOS?

asked 2020-02-07 15:17:18 +0300

Fuzzillogic gravatar image

There is a new vulnerability in Android's bluetooth implementetion. While SFOS uses Bluez as bluetooth stack, on libhyrbris-devices it does use the underlying Android bluetooth stack via a proxy, correct? Does this vulnerability affect SFOS as well?

edit retag flag offensive close delete



@Fuzzillogic Did you accept my answer? I still don't see clear evidence for us all being safe from this regardless of the actual device we use. I would be more confident if someone could review the sources of the daemon mentioned in this answer looking for code similar to this. Thank you. @Fuzzillogic, for bringing this topic here.

Maus ( 2020-02-15 20:24:34 +0300 )edit

@Maus no I didn't.. And I agree, I'm still not sure if the problem really doesn't exist on any SFOS device. I can only hope that whoever did mark the question as answered is really sure about it.

Fuzzillogic ( 2020-02-15 23:43:26 +0300 )edit

2 Answers

Sort by » oldest newest most voted

answered 2020-02-07 16:23:52 +0300

Maus gravatar image

updated 2020-02-09 21:56:08 +0300

@Fuzzillogic in comment 2 under the link you posted, remote user "jruge" writes:

Linux systems usually use Bluez, what is a different project than the Android Bluetooth stack. We have applied the same fuzzing technique against an Ubuntu system and could not observe any crashes.

Sailfish uses bluez5 or even bluez4 (if you happen to have older hardware). On my JP1301 phone, I have only the following daemon running:

# rpm -q --whatprovides /usr/sbin/bluetoothd

I also have a pand running, which talks to the bluetoothd service using sockets.

Thus, as the vulnerability affects the Android bluetooth daemon, Sailfish is not affected.

edit flag offensive delete publish link more



Yes, I'm aware SFOS uses BlueZ, as mentioned. But SFOS on most devices still runs on the underlying Android bits. On those devices, for bluetooth, bluebinder is used as a (HCI) proxy between those Android bits and BlueZ. Thus, the question is whether the flaw is in the Android-bits which are still used on SFOS for bluetooth, or that it exists in the upper layers of the Adroid bluetooth stack, which are not used in SFOS.

Fuzzillogic ( 2020-02-07 17:34:14 +0300 )edit

Now this is valuable information! I was aware of libhybris hardware abstraction on a driver (kernel module) level, but I wasn't aware of Android userland surviving a re-flash. If I had a newer phone, I'd check that.

Maus ( 2020-02-07 19:48:22 +0300 )edit

@Fuzzillogic I doubt that SFOS uses bluez on top of the Android daemon. Bluez should make use of the driver's interface directly. I am unable to present any proof, though.

Maus ( 2020-02-09 01:16:47 +0300 )edit

@Maus: as per comment: the Bluetooth daemon is a process on the Android system that runs in the background (daemon) that is responsible for managing the Bluetooth controller and handling of various Bluetooth related protocols, such as HCI, L2CAP and GATT.

Given that for exploitation only the MAC address is needed, it seems to me the vulnerability is at a very low level in the stack. Let's hope Jolla can shed some light on this comming week.

Fuzzillogic ( 2020-02-09 13:27:51 +0300 )edit

@Maus: you've marked the question as answered, but are you really sure about that? JP1301 uses a different BT implementation than later devices (e.g. XA2). Jolla phone doesn't use bluebinder.

Fuzzillogic ( 2020-02-10 15:27:32 +0300 )edit

answered 2020-02-13 23:43:54 +0300

misc11 gravatar image

in his latest techview podcast episode 504 (in german) @leszek said the bug is in the bluetooth daemon - not in the driver.

so sailfish should be fine and not affected :)

edit flag offensive delete publish link more



The root cause, as is referenced there as well, is a bug in hci/src/packet_fragmenter.cc. The actual exploit on Android apparently is in the daemon. Even if that daemon is not present in SFOS, the underlying bug (or at least the fix) might. Given the need for a proxy to get BlueZ talking to the underlying hardware (and thus not using the normal driver?) on many devices, I still am wondering whether this bug is on SFOS, and if so, whether it can be exploited in some other way.

Fuzzillogic ( 2020-02-14 17:25:40 +0300 )edit
Login/Signup to Answer

Question tools



Asked: 2020-02-07 15:17:18 +0300

Seen: 980 times

Last updated: Feb 13 '20