asked 2020-02-07 15:17:18 +0200
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?
answered 2020-02-07 16:23:52 +0200
@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
bluez-4.101+git77-1.3.1.jolla.armv7hl
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.
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 +0200 )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 +0200 )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 +0200 )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 +0200 )editanswered 2020-02-13 23:43:54 +0200
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 :)
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 +0200 )editAsked: 2020-02-07 15:17:18 +0200
Seen: 1,112 times
Last updated: Feb 13 '20
@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 +0200 )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 +0200 )edit