Re: Web Bluetooth security model

Hi Jeffrey,

On Fri, Apr 8, 2016 at 11:44 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> 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.

I don't think we need to go as far as emulating one controller per
website, instead I would have each website having a dedicated ATT/GATT
channel. Actually this is already possible with a custom service that
could authenticate per-app and make use of L2CAP Connection oriented
Channels. I guess this would be much simpler to pass and this actually
pushes further the use of L2CAP CoC which is a much better way to
handle things like firmware upload, this could also solve problems
related to the fact that ATT uses a fixed channel with a quite big
timeout of 30 seconds and no way to cancel it except disconnecting the
ACL link and starting over.

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

Received on Monday, 11 April 2016 08:14:44 UTC