Re: Web Bluetooth security model

On Wed, Apr 6, 2016 at 9:40 PM, Paul Theriault <ptheriault@mozilla.com>
wrote:

> Hi Jeffrey,
>
> Thanks for writing this up.  Back at the start of this process, we talked
> about a CORS-like opt-in for devices. I note that seems to have been ruled
> out - I remember seeing some discussion about this, but can you summarise
> was this approach not taken?  Were there technical reasons why devices
> couldn’t signal that they were Web Bluetooth safe/ authorise origins?
> Would it be something possible to consider in the future, or is it
> infeasible?
>

There are about 3 options for CORS-like control overall:

1) Devices have no knowledge of or control over which origins communicate
with them. This is the situation with the current Web Bluetooth proposal.
We think this is relatively safe because it matches the situation devices
are already in with native apps, so the security-conscious ones have been
designing for it. (e.g. Fitbit has a key exchange process with its
particular app, not just the BLE exchange with the peer device.) Lots of
devices aren't security-conscious, but many of these are also low-value. I
wish I could quantify this more than I can.

2) Devices have to opt into particular origins communicating with them.
This is how CORS works and is the safest option, but excludes all existing
devices, like your cheap pedometer, from being used with the web. Part of
the way we're starting to get manufacturers' interest is by writing demo
apps that use their products, like
https://webbluetoothcg.github.io/demos/bluetooth-toy-bb8/, and that
wouldn't be possible with an opt-in rule.

3) Devices can opt out of particular origins communicating with them. This
is where I'd like to end up. I sent an NWP for this (
https://www.dropbox.com/sh/8uyuts52hvx5tdy/AAAgI_CMVXYz-jR0IJWGv8ata/Handling%20Semi-trusted%20Applications%20NWP.docx?dl=0)
to the Bluetooth SIG last year, but I don't have time to personally drive
it through their process, so it didn't go anywhere. If someone else has
time, I'd love for them to take over. Marcel Holtmann thinks the right way
to do this is to have the UA's Bluetooth Controller pretend to be multiple
different radios, one for each website, so that normal Bluetooth bonding
would distinguish between origins, but I'm not sure that's the way to go,
since it doesn't actually communicate the origin.

Regarding the conclusion:
>
> "Some users’ devices probably will be exploited by malicious websites
> using Web Bluetooth. We believe the other security benefits will outweigh
> this.”
>
> If I understand your article - your justification of this statement is
> something like: currently you have to install native apps to use bluetooth
> devices. Native apps which have poor security in terms of least privilege.
> So by allowing websites to access bluetooth devices, you gain the ability
> to access devices without the necessity of installing potentially
> insecure/malicious native code (at the risk that you might accidentally
> break your device if you connect it to a malicious website)? Is that what
> you meant?
>

Yes, poor security at least in terms of least privilege, but likely also in
terms of the ability to attack the native OS.

Even with that benefit do you think your UI effectively conveys this risk
> to users? Well, yes you do, as you state, but one-click away from device
> compromise seems hard to accept? I can’t think of any other APIs on the web
> which fall into the same risk profile. (i.e. one wrong user decision
> results in permanent device compromise). Currently the UI seems to be very
> similar to existing permission prompts for microphone - any thoughts on how
> to convey the elevated risk to the user here?
>

I wanted to use wording like "foo.com would like to take control of" a
device, but our UI folks preferred "pair with" on the theory that users
already know that when you pair a thing with a Bluetooth device, you give
the thing complete control of the Bluetooth device. I'm definitely happy to
hear arguments or alternate UIs that might improve this, and non-Chrome UAs
should also feel free to try other UIs.

The other web feature that lets 2–3 wrong clicks take control of a device
is probably the ability to download files.


> Had you considered discriminating between well-known services and unknown
> services? IE if the website is requesting a well known service like
> ‘running_speed_and_cadence’, then the user agent could enforce a whitelist
> of allowed characteristics as defined by the related service specification
> e.g. [1]. As opposed to enforcing a blacklist of block services I mean. I’m
> not sure how closely devices actually adhere to these definitions however.
> I bought a cheap pedometer to test this idea, but it doesn’t actually use
> the standard characteristic IDs, making this approach not useful for this
> particular device.
>

Yep, that's the problem with special-casing standardized service UUIDs:
they're not actually all that common. The "allowed services list" is
designed to let us provide less-scary messages for known UUIDs in the
future, but we have to expect that most users will see a lot of
non-standard UUIDs.

We also considered letting manufacturers register their UUIDs to grant
access to them. This runs into the difficulty that we have to validate the
manufacturer's actual ownership of the UUIDs they're giving us. How do we
do that in a way that allows small groups or individuals to build devices
but that also prevents malicious folks from registering someone else's
vulnerable UUID?

Thanks for the thoughts,
Jeffrey


> Still, in general, perhaps the user agent could potentially have a
> fallback ‘scary’ UI for unknown services, and limit the permission request
> style approach only for devices which properly implement well known
> bluetooth services. The ability to connect to unknown services might even
> be a something behind a configuration toggle, to be enabled by users who
> understand the risk.
>
> Just some thoughts, let me know what you think.
>
> Regards,
> Paul Theriault
>
>
>
> [1]
> https://developer.bluetooth.org/gatt/services/Pages/ServiceViewer.aspx?u=org.bluetooth.service.running_speed_and_cadence.xml
>
> On 7 Apr 2016, at 1:34 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
>
> Hi all,
>
> I wrote an article about the security concerns in Web Bluetooth and how
> we're dealing with them, at
> https://medium.com/@jyasskin/the-web-bluetooth-security-model-666b4e7eed2.
> Let me know what you think, if I should improve anything, etc.
>
> Thanks,
> Jeffrey
>
>
>