Re: Security restrictions on web<->device communication

Hi Jefferey,

  I had a chat with a few folks, and below is out input (in blue).

Sorry for the delay!

Cheers,
Julien

On Mon, Apr 6, 2015 at 8:00 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:

> Thanks for the reply!
>
> On Mon, Apr 6, 2015 at 10:08 AM, Scott James Remnant <keybuk@google.com>
> wrote:
> >> Can the Bluetooth experts here think of other devices for which general
> >> web
> >> access would be a security problem? Can you put us in touch with any
> other
> >> Bluetooth security experts who would have good input?
> >
> > Keyboards.
>
> Yep.
>

As keybuk states, indeed (mice and) keyboards are risky to be exposed to
the web. So HID over GATT profile is a serious candidate for security
concerns.

At the time of writing chrome.hid API with reillyg we've blocked at
chromium level a few dangerous HID usages (see here
<https://chromium.googlesource.com/chromium/src.git/+/master/device/hid/hid_usage_and_page.cc>),
cause all OSes didn't block sniffing or writing to those ones (thinking of
Mac OS for instance).

At Logitech, we historically communicate (over USB and Bluetooth Classic)
with many of our devices (thinking particularly of mice and keyboards)
using HID vendor collections. We participated to HID over GATT (HOGP)
service some time ago, and hence unleashed implementation by OS makers of
HID class drivers over Bluetooth Smart.

I recall however that HOGP is black-listed by Windows RT APIs (see here
<https://msdn.microsoft.com/en-us/library/windows/apps/bg182882.aspx#four>).
On windows, we still use setup API to communicate with system's HID class
driver (which in turn is a HOGP implementor). I don't recall on MacOS.

Thus, at Logitech we're better off using HID vendor if possible, but we do
also have a proprietary service to achieve same functionality for OSes that
have no HID API support (like iOS).



> >> If browsers were to require devices to expose a particular service
> before
> >> letting websites talk to the device, what proportion of existing devices
> >> would be able to accept a firmware update to expose that service?
> >
> > None. LE is too low bandwidth for things like firmware updates, and if
> there
> > were such a thing, the "Firmware Update" GATT service would be a prime
> > example of the answer to your question above ;-)
>
> FitBits appear to update their firmware over an LE connection. It
> takes ~10 minutes. It's straightforward to sign firmware updates, and
> check the signature before applying the update, which would make it
> safe to allow arbitrary access to that service, but I don't know if
> actual manufacturers have bothered to incorporate that security
> feature.
>

Our BLE devices do perform DFU over GATT. Depending on the embedded
application it takes more or less time. BLE evolutions will make usage of
longer packets possible, leading to quicker DFU. In any case, DFU can be
performed in background, allowing parallel usage of the device, then
switching to the new application when DFU is over.

We do more and more use devices capable of updating their firmware, like
FitBit does, and it is crucial to keep this feature.


> >> If browsers were to require a device's PnP_ID to appear on a whitelist
> >> before we'd grant access, do any of you have a feeling for how difficult
> >> that whitelist would be to maintain? I see about 500 vendors granted IDs
> >> through the Bluetooth SIG, and we'd probably want each of them to
> provide
> >> a
> >> URL we could fetch to get their piece of the whitelist.
> >
> > Since the Device ID specification is just a GATT service, it's easy for
> any
> > other device to forge; I'm not sure of the value of this white list?
>
> The value of the whitelist is that we wouldn't expose devices to
> hostile websites unless their maker opts into that access. If a device
> manufacturer goes to the trouble of using someone else's device ID in
> order to let websites access their device, they've asserted that we
> don't need to protect their device against web access. The main
> problem with colliding device IDs is that we can't _remove_ access to
> one, if it's vulnerable, without removing access to all of its clones.
>

We have trouble thinking of the value of such list as well.
We'd need to standardize access to a white-list inside vendor's website.
That sounds complicated.

>> If browsers were to require a service's UUID to appear on a whitelist
> >> before
> >> we'd grant access, can you think of any safe way to include UUIDs that
> >> aren't standardized? In particular I'm worried about attackers
> >> whitelisting
> >> their victims' UUIDs. Is it safe enough to let any registered vendor
> >> whitelist any UUID?
> >
> > We should assume that standardized UUIDs will be already blacklisted by
> the
> > host subsystem, and that only non-standard service UUIDs will be
> accessible
> > by the web browser.
>
> That's not quite true: heart rate monitors are standardized, but not
> blacklisted by the host subsystem. I think you're right about
> keyboards.


See above remarks for HOGP profile. I think other standardized profiles
should be treated with the same level of consciousness as OS maker do.
Heart-rate monitoring is not something sensitive IMO.

Sensitive operations (DFU etc) will happen through vendor-specific
services, but we have to balance security vs the fact that any non-standard
UUID white/black-listing should be kept easily maintainable. IMO if we have
to put such mechanisms, the procedure should be 'dynamic' (user consent).


> >> If browsers allow access by default, and a device is found to be
> >> vulnerable
> >> to an attack, what's the best way to blacklist it? I hear that the
> Device
> >> Information service may not distinguish different devices using the same
> >> controller.
> >
> > Device ID should be different per-device.
>
> 'k, that's good. Do we know that device makers actually follow that
> "should"? What should we do for devices that omit the device ID
> entirely?
>

DIS <https://www.bluetooth.org/en-us/specification/adopted-specifications>,
except for HID devices, is optional. So we can't rely on its presence.

As a side remark (thinking of HOGP service), communication (R/W) with
keyboards requires an authenticated link, whereas reading mouse reports
does not.

We shall also take into account this level of security.


On Mon, Apr 6, 2015 at 8:00 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:

> Thanks for the reply!
>
> On Mon, Apr 6, 2015 at 10:08 AM, Scott James Remnant <keybuk@google.com>
> wrote:
> >> Can the Bluetooth experts here think of other devices for which general
> >> web
> >> access would be a security problem? Can you put us in touch with any
> other
> >> Bluetooth security experts who would have good input?
> >
> > Keyboards.
>
> Yep.
>
> >> If browsers were to require devices to expose a particular service
> before
> >> letting websites talk to the device, what proportion of existing devices
> >> would be able to accept a firmware update to expose that service?
> >
> > None. LE is too low bandwidth for things like firmware updates, and if
> there
> > were such a thing, the "Firmware Update" GATT service would be a prime
> > example of the answer to your question above ;-)
>
> FitBits appear to update their firmware over an LE connection. It
> takes ~10 minutes. It's straightforward to sign firmware updates, and
> check the signature before applying the update, which would make it
> safe to allow arbitrary access to that service, but I don't know if
> actual manufacturers have bothered to incorporate that security
> feature.
>
> >> If browsers were to require a device's PnP_ID to appear on a whitelist
> >> before we'd grant access, do any of you have a feeling for how difficult
> >> that whitelist would be to maintain? I see about 500 vendors granted IDs
> >> through the Bluetooth SIG, and we'd probably want each of them to
> provide
> >> a
> >> URL we could fetch to get their piece of the whitelist.
> >
> > Since the Device ID specification is just a GATT service, it's easy for
> any
> > other device to forge; I'm not sure of the value of this white list?
>
> The value of the whitelist is that we wouldn't expose devices to
> hostile websites unless their maker opts into that access. If a device
> manufacturer goes to the trouble of using someone else's device ID in
> order to let websites access their device, they've asserted that we
> don't need to protect their device against web access. The main
> problem with colliding device IDs is that we can't _remove_ access to
> one, if it's vulnerable, without removing access to all of its clones.
>
> >> If browsers were to require a service's UUID to appear on a whitelist
> >> before
> >> we'd grant access, can you think of any safe way to include UUIDs that
> >> aren't standardized? In particular I'm worried about attackers
> >> whitelisting
> >> their victims' UUIDs. Is it safe enough to let any registered vendor
> >> whitelist any UUID?
> >
> > We should assume that standardized UUIDs will be already blacklisted by
> the
> > host subsystem, and that only non-standard service UUIDs will be
> accessible
> > by the web browser.
>
> That's not quite true: heart rate monitors are standardized, but not
> blacklisted by the host subsystem. I think you're right about
> keyboards.
>
> >> If browsers allow access by default, and a device is found to be
> >> vulnerable
> >> to an attack, what's the best way to blacklist it? I hear that the
> Device
> >> Information service may not distinguish different devices using the same
> >> controller.
> >
> > Device ID should be different per-device.
>
> 'k, that's good. Do we know that device makers actually follow that
> "should"? What should we do for devices that omit the device ID
> entirely?
>
> Thanks,
> Jeffrey
>
> > On Mon, Apr 6, 2015 at 8:37 AM Jeffrey Yasskin <jyasskin@google.com>
> wrote:
> >>
> >> Hi all,
> >>
> >> Does anyone here have thoughts on the questions below? We really need
> >> wider input in order to balance security against usability.
> >>
> >> Thanks,
> >> Jeffrey
> >>
> >> On Wed, Mar 18, 2015 at 9:59 AM, Jeffrey Yasskin <jyasskin@google.com>
> >> wrote:
> >> > Hi Web Bluetooth folks,
> >> >
> >> > Some Google folks have been talking about the security risks of
> exposing
> >> > devices to the Web when those devices weren't designed to be secure in
> >> > the
> >> > face of that access. We'd like your input in figuring out how best to
> >> > mitigate those risks, especially by answering the questions at the
> >> > bottom of
> >> > this email.
> >> >
> >> > An example vulnerable device comes from the FIDO specifications:
> >> > https://fidoalliance.org/specifications. In particular, a web
> >> > application
> >> > that gets paired with a FIDO device can sign a challenge presented by
> a
> >> > different origin, breaking the FIDO security model. The UI needed to
> >> > phish a
> >> > user in this way appears to be simple.
> >> >
> >> > To mitigate this risk, I've put together a draft GATT service at
> >> >
> >> >
> https://docs.google.com/document/d/1T6hLoLvOzNrcMrbtUxAO8yF8zskHiqKfEIPxJNYvfvg/edit
> >> > to let devices control their interactions with websites, in a way that
> >> > resembles both CORS and postMessage's origin attribution. Feel free to
> >> > comment on that document.
> >> >
> >> > Once that service is standardized, if a device implements it, we're
> home
> >> > clear. The open question is what to do about devices that don't define
> >> > the
> >> > new service.
> >> >
> >> > We'd like to get some feedback from this list before deciding what to
> >> > do.
> >> >
> >> > Can the Bluetooth experts here think of other devices for which
> general
> >> > web
> >> > access would be a security problem? Can you put us in touch with any
> >> > other
> >> > Bluetooth security experts who would have good input?
> >> > If browsers were to require devices to expose a particular service
> >> > before
> >> > letting websites talk to the device, what proportion of existing
> devices
> >> > would be able to accept a firmware update to expose that service?
> >> > If browsers were to require a device's PnP_ID to appear on a whitelist
> >> > before we'd grant access, do any of you have a feeling for how
> difficult
> >> > that whitelist would be to maintain? I see about 500 vendors granted
> IDs
> >> > through the Bluetooth SIG, and we'd probably want each of them to
> >> > provide a
> >> > URL we could fetch to get their piece of the whitelist.
> >> > If browsers were to require a service's UUID to appear on a whitelist
> >> > before
> >> > we'd grant access, can you think of any safe way to include UUIDs that
> >> > aren't standardized? In particular I'm worried about attackers
> >> > whitelisting
> >> > their victims' UUIDs. Is it safe enough to let any registered vendor
> >> > whitelist any UUID?
> >> > If browsers allow access by default, and a device is found to be
> >> > vulnerable
> >> > to an attack, what's the best way to blacklist it? I hear that the
> >> > Device
> >> > Information service may not distinguish different devices using the
> same
> >> > controller.
> >> >
> >> >
> >> > Thanks for any help,
> >> > Jeffrey
> >>
> >
>
>