Security/Reviews/WebBluetooth

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

Web Bluetooth
Target
   
     Full Query    
ID Summary Priority Status
727618 [meta] Bluetooth Implementation on B2G V1 -- RESOLVED
749362 SecReview: WebBluetooth -- RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

The given value "
   
     Full Query    
ID Summary Priority Status
727618 [meta] Bluetooth Implementation on B2G V1 -- RESOLVED
749362 SecReview: WebBluetooth -- RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

Introduce the Feature

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

Threat Brainstorming

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

Other Questions

  • 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
  • Property "SecReview feature goal" (as page type) with input value "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)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview alt solutions" (as page type) with input value "* using low level bluez sockets
    • using low level dbus - Solution we went with
    • using dbus with api" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "===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

    Other Questions

    • 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status In Progress
Release Target `
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