bluez / CVE-2020-0556

[Brian May <brian@linuxpenguins.xyz>]

I am a bit puzzled by the following comment from dla-needed.txtfor bluez:

  NOTE: 20200503: Looking at the four patches included in the stretch update it looks like it
  NOTE: 20200503: can be applied as is. What will fail is hog.c but that file do not seem to
  NOTE: 20200503: need an update. (Ola)

As far as i can tell, the first commit fixes the security flaw, and the
only file it touches in hog.c. If true that hog.c does not need an
update, does this means the package is not vulnerable? I suspect not.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1
- fix vulnerability.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=3cccdbab2324086588df4ccf5f892fb3ce1f1787
- make security posture configurable to support newer devices.

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=35d8d895cd0b724e58129374beb0bb4a2edf9519
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=f2778f5877d20696d68a452b26e4accb91bfb19e
- fix potential regressions.

The patch patches the hog_accept function, which is a callback set as
part of the hog_profile:

static struct btd_profile hog_profile = {
        .name           = "input-hog",
        .remote_uuid    = HOG_UUID,
        .device_probe   = hog_probe,
        .device_remove  = hog_remove,
        .accept         = hog_accept,
        .disconnect     = hog_disconnect,
        .auto_connect   = true,
};

Unfortunately the version in Jessie doesn't even have an accept entry:

static struct btd_profile hog_profile = {
        .name           = "input-hog",
        .remote_uuid    = HOG_UUID,
        .device_probe   = hog_probe,
        .device_remove  = hog_remove,
};

Looking at commit
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7d9718cfcc11eaa9d8059e721301cdc00ef8c82e,
it looks like maybe we should be patching the attio_connected_cb()
function instead. But this function doesn't appear to have any way to
return an error indicating it failed, which seems to be required by the
patch. It might be sufficient just to ignore the error and return
without immediately if device is not bonded. Not sure how much I can
trust this however.

My gut feeling to fix this we should backport version 5.43-2+deb9u2 from
stretch to Jessie. Yes, this might break stuff, but I suspect just the
very basic idea of this security fix - rejecting unbonded connections -
could break stuff also.
-- 
Brian May <brian@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/