The Web Bluetooth Security Model

Apr 5, 2016

Web Bluetooth is a developing JavaScript API to allow websites to communicate with Bluetooth devices. Sites ask the browser to show a list of nearby Bluetooth devices matching certain criteria, and the user either picks which to grant access to or cancels the dialog.

As you might expect, there are security risks here. When deciding whether to ship the new API, we should look at several kinds of attackers and defenders:

• An abusive software developer, trying to do embarrassing or privacy-insensitive things that don’t go outside devices’ security models.
• A malicious software developer, trying to exploit users using nearby Bluetooth devices.
• A malicious hardware manufacturer, trying to exploit users or websites who connect to their devices.
• A malicious manufacturer/developer, who can push cooperating hardware and software.
• Weakly-written device firmware, which doesn’t intend to hurt its users, but might be vulnerable to malicious connections.
• Weakly-written kernels, which might be vulnerable to either malicious userland software or malicious connections.

The ultimate decision about whether to ship Web Bluetooth should also take the competitiveness of the web into account, but this article only analyzes the security tradeoffs.

Abusive software developers §

Abusive websites might try to do embarrassing things like configure a Bluetooth speaker to play porn sounds. Web Bluetooth defends against this in several ways:

• The chooser grants a website access to only the specific devices a user selects, which helps the user associate misbehavior with specific sites and prevents those sites from messing with extra devices.
• On desktop platforms we show a tab indicator while a site is connected to a device, which also helps associate the site with the misbehaving device. This isn’t perfect, since the site might configure a device to only misbehave later, long after the site has disconnected to stop showing the tab indicator.
• If users notice misbehavior and revoke a site’s access to a device, we’re looking into ways to aggregate that in a privacy-preserving way and use it to protect other users from that site, either by automatically denying the chooser or by adding an extra warning that the site might be abusive.

Malicious software developers §

In a world with Web Bluetooth, malicious developers will be able to choose between attacking users via native or web apps. We want shipping Web Bluetooth to make their job harder across the combination of both targets.

Getting permission §

Assume the user visits the malicious developer’s website. To grant it permission to attack Bluetooth devices, the user must:

Android M+:

1. Click on app install banner.
2. Click ‘Install’ in Play Store. Wait.
3. Click ‘Open’ in Play Store.
4. Click ‘Accept’ on a location permission prompt.

iOS:

1. Click on app install banner.
2. Click ‘Get’ in App Store.
3. Click ‘Install’ in App Store. Wait.
4. Click ‘Open’ in App Store.

Chrome OS (through a Chrome App):

1. Site calls chrome.webstore.install() inside a user gesture.
2. Click ‘Add’ on a dialog that mentions Bluetooth. Wait.
3. Click the app icon.

Web Bluetooth

1. Site calls navigator.bluetooth.requestDevice() inside a user gesture.
2. Click the vulnerable device inside a dialog that mentions pairing.
3. Click ‘Pair’.

Web Bluetooth provides more warning to users than Android or iOS before giving access to the first device. Web Bluetooth also requires the same permission sequence for each additional device, so the malicious developer can’t attack devices the user wasn’t aware of.

Getting permission illicitly §

A developer can also hijack a trusted site’s permission to use Bluetooth devices.

• Native: XcodeGhost demonstrates that it’s possible to compromise native apps at scale, but to do it you need to compromise development machines.
• Web: Web sites are often compromised to host malware. Even without being compromised, web sites embed ads that shouldn’t be able to access Bluetooth devices. To make sure ads only get access to expected capabilities, Chris Palmer is proposing a permission delegation API, which Web Bluetooth will use.

Web Bluetooth is probably more vulnerable to this type of attack.

Attacking the kernel through Bluetooth APIs §

The kernel or Bluetooth drivers may be vulnerable to attack from the local machine, or from a remote radio as discussed below. The main defense we have here is to keep the API surface small and to run fuzz tests over that API. Web Bluetooth is helped by the GATT API being relatively small.

Attacking through non-Bluetooth channels §

A user who wants to access a Bluetooth device will follow instructions for how to do so. This may allow other attacks:

• Native apps find it easier to escape the system sandbox than web apps, at least because web apps have to escape a browser sandbox before even attempting to attack the system.
• Native apps have more abilities by default than web apps. For example, native apps have raw network access, can execute in the background, and can track users through a persistent advertising ID.
• Android M+ requires the user grant access to their location in order for an app to communicate over Bluetooth.

If we ship Web Bluetooth, users can get used to simple uses working on the web, which will help restrict the more dangerous native apps to the cases they’re actually needed.

Avoiding blockage §

Before a site or app is discovered to be malicious:

• Native: App stores have full access to an app’s code and can test it for malicious behavior on hardware they pick. However, because each kind of remote Bluetooth device may speak a different protocol and have different vulnerabilities, the stores basically can’t test for malice and have to allow any messages they don’t know to be harmful.
• Web: We can’t do an offline scan of a website, but app stores aren’t benefitting from offline scans in this case anyway. We can block the known-harmful messages using an updatable registry of blacklisted services.

After a site or app is discovered to be malicious:

• Native: Stores can take down all apps uploaded under a single credit card.
• Web: Safe Browsing can block access to the single malicious website.

Web Bluetooth should be just as good at preventing attacks ahead of time, but doesn’t have as strong a response after we discover an attack.

Attacking the device §

• Native: The app has access to both GATT and Bluetooth Classic profiles. Classic profiles are byte-stream-based, which makes them harder to parse and more likely to be exploitable. As mentioned above, native apps can also attack all devices in radio range, the entire time they’re installed, without going back through a user prompt.
• Web: Sites can only communicate over the relatively simple GATT protocol, which maps keys to bounded-length values. Sites can also only attack devices the user explicitly granted access to.

Web Bluetooth does not take the extra CORS-like step of asking devices to opt into the origins that are allowed to communicate with them, but is still less likely to give access to exploitable device code.

Some Bluetooth devices intentionally allow firmware updates over a GATT channel. For example, Nordic Semiconductor has defined a Device Firmware Update service with a default implementation in their SDK. Unfortunately this implementation doesn’t check the update’s signature, which could enable an attack along the lines of the iSeeYou attack on USB. As a result, Web Bluetooth will probably add this service to the blacklist, and restrict unsigned updates to native apps. Firmware update services that do check signatures would not need to be blacklisted.

Malicious hardware manufacturers §

Websites that don’t know about Web Bluetooth aren’t affected by its existence, because they have to make an explicit function call to opt into it.

Because users get to choose the device they connect to a website, websites have to design around being given an incorrect device. They may still make incorrect and exploitable assumptions about how the device will respond to their messages. That said, this only affects the single exploited website: browser sandboxing prevents the damage from leaking to other sites.

Malicious hardware may also be able to work alone to attack a user’s computer, as described in the next section.

Malicious hardware manufacturers who also write websites §

Remote devices can also attempt to exploit a user’s computer. The most well-known example of this is innocent-looking USB devices that behave as keyboards or mice when plugged in. I’m told that neither apps nor browsers can pair with Bluetooth devices in a way that makes the devices into trusted keyboards, but I haven’t seen a reliable published source saying this.

Devices may also be able to attack a user’s kernel, possibly through their Bluetooth drivers. We haven’t yet fuzz-tested this attack surface, but we plan to before shipping the API.

The Physical Web makes it easier for malicious hardware to get users onto their website, than it would be to get them to install a native app. Web Bluetooth needs to validate that remote hardware can’t attack users’ systems through this route.

Conclusion §

• Web Bluetooth’s ability to pair an application with a single remote device is a big advance toward the principle of least privilege.
• Reducing the number of native apps users need to install is another big advance given the general power of native apps.
• Some users’ devices probably will be exploited by malicious websites using Web Bluetooth. We believe the other security benefits will outweigh this.
• We need to run several more security tests before shipping the API, including fuzzing several operating systems and testing that they don’t automatically grant access for devices to act as keyboards.

Acknowledgements §

Thanks to Adrienne Porter Felt, Chris Palmer, Xifumi, Giovanni Ortuño, Vincent Scheib, Alex Russell, and François Beaufort for reviewing this. Any remaining mistakes are still mine.

This was originally published on Medium.