Re: [BlueZ PATCH 0/2] HID and HOGP connections from non-bonded devices.

From: Alain Michaud <alainmichaud@google.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Alain Michaud <alainm@chromium.org>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>
Subject: Re: [BlueZ PATCH 0/2] HID and HOGP connections from non-bonded devices.
Date: Tue, 10 Mar 2020 08:30:12 -0400	[thread overview]
Message-ID: <CALWDO_VNPFJm+je4N1u1bW=+n8WTCoe+xwzrOo=UZi4ymuwdsg@mail.gmail.com> (raw)
In-Reply-To: <CABBYNZKbc71WvOA34cFcKXVRcG-hYedJBT5LeTK9c3+H5Trjwg@mail.gmail.com>

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