Re: Security restrictions on web<->device communication

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
>>
>

Received on Monday, 6 April 2015 18:01:35 UTC