REPRODUCIBILITY:
OS VERSION: ALL
HARDWARE: ALL
UI LANGUAGE: ALL
REGRESSION:
DESCRIPTION:
cve-2023-45866
CVE-2020-0556
Sailfish use bluez5 with disabled fix for these two CVE.
Fix:
REPRODUCIBILITY:
OS VERSION: ALL
HARDWARE: ALL
UI LANGUAGE: ALL
REGRESSION:
cve-2023-45866
CVE-2020-0556
Sailfish use bluez5 with disabled fix for these two CVE.
Fix:
It honestly irritates me how this has been around for months yet nobody cared until the December security bulletin came out…
Either case, this will take a long time until it makes its way into SFOS, either by a 5.71 Bluez5 tag or a cherry-pick (with the former being more likely): I invite you to publish a PR with this patch as the latter so the Jolla guys can decide whether to merge this now or wait it out.
exploitation on Linux/BlueZ requires that Bluetooth is discoverable/connectable
The proper way to do a PR for this is to apply the upstream commit.
That way appropriate credit is given, and comments/reason is not lost like with this version.
For those not following on github, looks like it’s in the works from a comment by mal: Update device.c by acfbhytuiltyghrth · Pull Request #10 · sailfishos/bluez5 · GitHub
Do I read input.conf: Change default of ClassicBondedOnly - bluez.git - Bluetooth protocol stack for Linux correctly that the vuln can be mitigated without recompiling/updating by setting the config value ClassicBondedOnly
to true in input.conf?
Yes, you read that correctly. Now, if that actually mitigates the issue, I have no idea. EDIT: as far as I can tell this IS the mitigation so just change the input profile config, maybe just add
ClassicBondedOnly=true
to /etc/bluez5/bluetooth/input.conf
If you’re feeling nervous.
There is now PR to update bluez5 to latest version which includes the fix Update to 5.71 by mlehtima · Pull Request #11 · sailfishos/bluez5 · GitHub