| Message ID | 20200310023516.209146-1-alainm@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | HID and HOGP connections from non-bonded devices. | expand |
Hi Alain, > It was discovered that BlueZ's HID and HOGP profiles implementations > don't specifically require bonding between the device and the host. > > This creates an opportunity for an malicious device to connect to a > target host to either impersonate an existing HID device without > security or to cause an SDP or GATT service discovery to take place > which would allow HID reports to be injected to the input subsystem from > a non-bonded source. > > This patch series addresses the issue by ensuring that only connections > from devices that are bonded are accepted by the HID and HOGP profile > implementation. > > More information about the vulnerability is available here: > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html > > Alain Michaud (2): > HOGP must only accept data from bonded devices. > HID accepts bonded device connections only. > > profiles/input/device.c | 23 ++++++++++++++++++++++- > profiles/input/device.h | 1 + > profiles/input/hog.c | 4 ++++ > profiles/input/input.conf | 8 ++++++++ > profiles/input/manager.c | 13 ++++++++++++- > 5 files changed, 47 insertions(+), 2 deletions(-) both patches have been applied. However I changed BrBondedOnly configuration name into ClassicBondedOnly since that name seemed more obvious to me. The prefix Br has never been used and the Bluetooth SIG started calling it Classic a while back. Regards Marcel
Hi Marcel, On Mon, Mar 9, 2020 at 10:26 PM Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Alain, > > > It was discovered that BlueZ's HID and HOGP profiles implementations > > don't specifically require bonding between the device and the host. > > > > This creates an opportunity for an malicious device to connect to a > > target host to either impersonate an existing HID device without > > security or to cause an SDP or GATT service discovery to take place > > which would allow HID reports to be injected to the input subsystem from > > a non-bonded source. > > > > This patch series addresses the issue by ensuring that only connections > > from devices that are bonded are accepted by the HID and HOGP profile > > implementation. > > > > More information about the vulnerability is available here: > > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html > > > > Alain Michaud (2): > > HOGP must only accept data from bonded devices. > > HID accepts bonded device connections only. > > > > profiles/input/device.c | 23 ++++++++++++++++++++++- > > profiles/input/device.h | 1 + > > profiles/input/hog.c | 4 ++++ > > profiles/input/input.conf | 8 ++++++++ > > profiles/input/manager.c | 13 ++++++++++++- > > 5 files changed, 47 insertions(+), 2 deletions(-) > > both patches have been applied. > > However I changed BrBondedOnly configuration name into ClassicBondedOnly since that name seemed more obvious to me. The prefix Br has never been used and the Bluetooth SIG started calling it Classic a while back. Looks like you were quicker than me, anyway I do fill like we should attempt to bump to security instead of just refuse to connection in case of HoG since we are the central and the peripheral is not mandated to started it either it may be just the client application is attempting to connect to trigger pairing on demand, that would usually kick latter when reading the characteristics but with this changes it doesn't even get to that point if the devices was not bonded already.
Hi Luiz, On Tue, Mar 10, 2020 at 2:27 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Marcel, > > On Mon, Mar 9, 2020 at 10:26 PM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > Hi Alain, > > > > > It was discovered that BlueZ's HID and HOGP profiles implementations > > > don't specifically require bonding between the device and the host. > > > > > > This creates an opportunity for an malicious device to connect to a > > > target host to either impersonate an existing HID device without > > > security or to cause an SDP or GATT service discovery to take place > > > which would allow HID reports to be injected to the input subsystem from > > > a non-bonded source. > > > > > > This patch series addresses the issue by ensuring that only connections > > > from devices that are bonded are accepted by the HID and HOGP profile > > > implementation. > > > > > > More information about the vulnerability is available here: > > > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html > > > > > > Alain Michaud (2): > > > HOGP must only accept data from bonded devices. > > > HID accepts bonded device connections only. > > > > > > profiles/input/device.c | 23 ++++++++++++++++++++++- > > > profiles/input/device.h | 1 + > > > profiles/input/hog.c | 4 ++++ > > > profiles/input/input.conf | 8 ++++++++ > > > profiles/input/manager.c | 13 ++++++++++++- > > > 5 files changed, 47 insertions(+), 2 deletions(-) > > > > both patches have been applied. > > > > However I changed BrBondedOnly configuration name into ClassicBondedOnly since that name seemed more obvious to me. The prefix Br has never been used and the Bluetooth SIG started calling it Classic a while back. > > Looks like you were quicker than me, anyway I do fill like we should > attempt to bump to security instead of just refuse to connection in > case of HoG since we are the central and the peripheral is not > mandated to started it either it may be just the client application is > attempting to connect to trigger pairing on demand, that would usually > kick latter when reading the characteristics but with this changes it > doesn't even get to that point if the devices was not bonded already. The specification for HoG is that the device is bonded. If client or server attempts to access the service before it is bonded, it would violate the specification. For this reason, I believe it is both safer and simpler to just reject any attempts to access the service without first being bonded. > > -- > Luiz Augusto von Dentz
Hi Alain, On Tue, Mar 10, 2020 at 5:30 AM Alain Michaud <alainmichaud@google.com> wrote: > > Hi Luiz, > > On Tue, Mar 10, 2020 at 2:27 AM Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Marcel, > > > > On Mon, Mar 9, 2020 at 10:26 PM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > > > Hi Alain, > > > > > > > It was discovered that BlueZ's HID and HOGP profiles implementations > > > > don't specifically require bonding between the device and the host. > > > > > > > > This creates an opportunity for an malicious device to connect to a > > > > target host to either impersonate an existing HID device without > > > > security or to cause an SDP or GATT service discovery to take place > > > > which would allow HID reports to be injected to the input subsystem from > > > > a non-bonded source. > > > > > > > > This patch series addresses the issue by ensuring that only connections > > > > from devices that are bonded are accepted by the HID and HOGP profile > > > > implementation. > > > > > > > > More information about the vulnerability is available here: > > > > https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00352.html > > > > > > > > Alain Michaud (2): > > > > HOGP must only accept data from bonded devices. > > > > HID accepts bonded device connections only. > > > > > > > > profiles/input/device.c | 23 ++++++++++++++++++++++- > > > > profiles/input/device.h | 1 + > > > > profiles/input/hog.c | 4 ++++ > > > > profiles/input/input.conf | 8 ++++++++ > > > > profiles/input/manager.c | 13 ++++++++++++- > > > > 5 files changed, 47 insertions(+), 2 deletions(-) > > > > > > both patches have been applied. > > > > > > However I changed BrBondedOnly configuration name into ClassicBondedOnly since that name seemed more obvious to me. The prefix Br has never been used and the Bluetooth SIG started calling it Classic a while back. > > > > Looks like you were quicker than me, anyway I do fill like we should > > attempt to bump to security instead of just refuse to connection in > > case of HoG since we are the central and the peripheral is not > > mandated to started it either it may be just the client application is > > attempting to connect to trigger pairing on demand, that would usually > > kick latter when reading the characteristics but with this changes it > > doesn't even get to that point if the devices was not bonded already. > The specification for HoG is that the device is bonded. If client or > server attempts to access the service before it is bonded, it would > violate the specification. For this reason, I believe it is both > safer and simpler to just reject any attempts to access the service > without first being bonded. Ive sent a patch for it, we would not be accessing anything while the security is being bump as the kernel would block that, so in practice this would just initiate the pairing procedure if the device is not bonded .