- 1 Introduce Feature
- 2 Threat Brainstorming
- 3 Conclusions / Action Items
Bluetooth API Security Review
- Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=727618
- SecReview Bug https://bugzilla.mozilla.org/show_bug.cgi?id=749362
- Wiki: https://wiki.mozilla.org/WebAPI/WebBluetooth
Invitees: Kyle M
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
The aim of WebBluetooth is to establish a DOM API to set up and communicate with Bluetooth devices. This includes setting properties on adapters and devices, scanning for devices, bonding, and socket initialization for audio and communication. For basecamp, we will support:
- HSP (Headset profile, transfers call audio)
- HFP (Hands free profile, encompasses HSP along with the ability to use buttons on a headset to start/end calls, adjust volume, etc...)
- FTP (File transfer PROFILE (not protocol), used as a "share" interface for music/gallery apps to transfer files between other devices)
What solutions/approaches were considered other than the proposed solution?
- using low level bluez sockets
- using low level dbus - Solution we went with
- using dbus with api
Why was this solution chosen?
Android also uses low level dbus calls, and we couldn't find a decent dbus API that wasn't glib based or didn't do silly things with c++.
Any security threats already considered in the design and why?
- Access limiting to certain apps so that users cannot create arbitrary ports
Attacks from the web
- Malicious app abusing bluetooth (attacking other devices, DoS the API, consume power?)
** Only certified apps will have access to the bluetooth api
- Certified app being interefered with or coerced into providing data
** App process seperation ** Security review of certified apps which use this API
Attacks from Bluetooth
- BlueSnarfing - attack which used a vulnerability to collect data from a device without pairing. L2CAP -> RFCOMM -> Channel 3 (OBEX Push Profile) -> OBEX -> IrMC -> Contacts
- BluePrinting - determine Bluetooth device properties via SDP to uniquely identify a device. (pre pairing)
- BlueSmack - attack which sends large payloads with L2CAP Echo requests
- BlueStab - control characters in UTF-8 encoded BT device name
- BlueBump - forced key exchange
- BlueChop - disrupts established Bluetooth piconets
- BlueSpoof - clone a trusted device (device address, service records, emulate protocols and profiles), disable encryption, force re-pairing.
- BlueDump - cracking the PIN http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/index.html
- Which protocols are going to be supported and need fuzz testing? (http://en.wikipedia.org/wiki/Bluetooth_protocols) Please provide exact specification and version number.
- what apps will have bluetooth access? is there going to be a bluetooth app? or is this the settings app and maybe system app that has access?
- Settings for start/stop and pairing, Music/gallery for file sharing (via a "share button" interface)
- What levels of access are there? (all or nothing only, or per device type etc)
- All or nothing
Conclusions / Action Items
- Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)
dchan - gonk update strategy for bluetooth, camera, etc dchan - looking into dbus testing tools that ChromeOS uses