Security/B2G/Bluetooth

Overview

FirefoxOS Review Details

• API: WebBluetooth API
• Review Date: November 2013
• Review Lead: Rob Fletcher (:omerta), rfletcher@mozilla.com

Contacts:

• Eric Chou (ericchou) is current bluetooth team lead, echou@mozilla.com
• Thomas Zimmermann (tzimmermann) is working on DBus, tzimmermann@mozilla.com
• Kyle Machulis (qDot) is previous bluetooth team lead, kmachulis@mozilla.com

History:

• Bluetooth V1 was reviewed in April 2012 and can be found here

Context

It's been a while since the first, fairly limited, review of bluetooth on FxOS. The goal of the review was to audit WebBluetooth API and the coder therein. The main source of analysis was manual code review. No fuzzing, static analysis, or physical testing was conducted.

/gaia/apps/bluetooth/ uses mozBluetooth. mozBluetooth is defined, via nsIDOMNavigatorBluetooth.idl, in BluetoothManager.cpp. BluetoothManager.cpp uses WebBluetooth API (nsIDOMBluetoothAdapter, nsIDOMBluetoothManager, nsIDOMBluetoothDevice).

The aim of WebBluetooth is to establish a DOM API, using Dbus, 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. Supported features:

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

Scope

The scope of the review was contained to gecko/dom/bluetooth. Next up, we will examine how the Gaia bluetooth app interacts with the Gecko code.

Components

/gaia/apps/bluetooth/ uses mozBluetooth. mozBluetooth is defined, via nsIDOMNavigatorBluetooth.idl, in BluetoothManager.cpp. BluetoothManager.cpp uses WebBluetooth API (nsIDOMBluetoothAdapter, nsIDOMBluetoothManager, nsIDOMBluetoothDevice).

The aim of WebBluetooth is to establish a DOM API, using Dbus, 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. Supported features:

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

Relevant Source Code

gecko/dom/bluetooth/

• BluetoothHfpManager.[cpp|h]
  • Blueooth Hands Free Profile - using Synchronous Connection Oriented (SCO)
• BluetoothOppManager.[cpp|h]
  • Object Push Profile - A basic profile for sending "objects" such as pictures, virtual business cards, or appointment details.
• BluetoothAdapter.[cpp|h]
  • Does a lot of setup and setting. For example, setting UUIDs, Pairing and unpairing, setting pin code, setting passkey etc.
• BluetoothService.[cpp|h]
  • "DBusThread object needs to be able to distribute messages to all objects that might be waiting for them" - from bugzilla.
  • Messaging system between bluetooth threads
• BluetoothDevice.[cpp|h]
  • Represents a remote Bluetooth device. A BluetoothDevice lets you create a connection with the respective device or query information about it, such as the name, address, class, and bonding state
• BluetoothUnixSocketConnector.[cpp|h]
• BluetoothManager.[cpp|h]
  • "mozBluetooth"
  • High level manager used to obtain an instance of an BluetoothAdapter and to conduct overall Bluetooth Management.
• BluetoothUtils.[cpp|h]
• ObexBase.[cpp|h]
  • OBEX (OBject EXchange) communications protocol that facilitates the exchange of binary objects between devices.
• BluetoothRilListener.[cpp|h]
  • Radio Interface Layer - deals with telephony. "The Android Open Source Project provides a Radio Interface Layer (RIL) between Android telephony services (android.telephony) and the radio hardware. It consists of a stack of two components: a RIL Daemon and a Vendor RIL. The RIL Daemon talks to the telephony services and dispatches "solicited commands" to the Vendor RIL. The Vendor RIL is specific to a particular radio implementation, and dispatches "unsolicited commands" up to the RIL Daemon."
  • Only used by BluetoothHfpManager
• BluetoothSocket.[cpp|h]
  • A connected or connecting Bluetooth socket.
• BluetoothReplyRunnable.[cpp|h]
  • Used for asynchronus communication with DBus: "It was used because we do a LOT of asynchronous stuff with DBus." - qDot
    • Because we want main thread callbacks based to replies from dbus commands, but the dbus commands come in on the IO thread. Used to be "dbus commands came in on like 3 different threads" but thanksfully that's been reduced. - qDot
• BluetoothPropertyContainer.[cpp|h]
  • DOMRequest stuff, used by Blueooth[Adapter|Device|Manager]
• BluetoothPropertyEvent.[cpp|h]
  • used by Bluetooth[Adapter|Device]
• BluetoothUuid.[cpp|h]

gecko/dom/bluetooth/gonk/

• BluetoothGonkService.[cpp|h]:
  • dispatch messages to Bluetooth objects on the main thread, as well as provide platform independent access to BT functionality.

gecko/dom/bluetooth/ipc/

• BluetoothChild.[cpp|h]
• BluetoothParent.[cpp|h]
• BluetoothServiceChildProcess.[cpp|h]
  • methods to handle IPC between child and parent

gecko/dom/bluetooth/linux/

• BluetoothDBusService.[cpp|h]
  • BluetoothDBusService is the implementation of BluetoothService for DBus on linux/android/B2G.
  • Communicates things, like passkey, to Dbus engine to do things with; e.g. authentication.
• BluetoothDBusUtils.cpp
  • utilities for BluetoothDBusService

Permission Model

bluetooth/BluetoothManager.cpp uses nsPermissionManager::TestPermissionFromWindow to verify the 'bluetooth' permission is present.

Review Notes

1. Content/Chrome Segregation

No content/chrome segregation issues found.

2. Process Segregation

gecko/dom/bluetooth defines code inside /ipc that is responsible for managing communication across multiple processes. The situations are detailed in BluetoothService.cpp but essentially, the IPC code manages retrieving and manipulating bluetooth actors in several ways.

3. Data validation & Sanitization

Any user/device supplied data is generally BLOBs and there isn't much of an avenue for data validation/sanitzation errors. Things like format string vulnerabilities were checked.

No data validation/sanitization issues found at this time.

4. Denial of Service

A possible source of DoS is the application not defining an ActorDestroy method, because a child process crashing will cause the device to reboot. bluetooth/ipc defines several instances of ActorDestroy for BluetoothRequestChild, BluetoothChild, BluetoothParent, BluetoothRequestParent.

No DoS avenues apparent via code inspection. Physical testing and fuzzing would be more fruitful than manual code inspection; maybe next time around.

5. Mechanical C/C++

• Integer wrapping/overflow/promotion:
  • checked comparisons(>,<)
  • checked operators(+ - << >> *)
  • checked comparions of unsigned to signed int
• Use after free, double free
  • free is not used, delete is. nothing double deleted or used after delete
• Buffer Overflow
  • Examined stack/heap buffers and dangerous memory functions
• Null dereference
• Format String Vulns
  • No instances of code letting a user define printf modifiers in a string

Security Risks & Mitigating Controls

• In general, we are trying to get away from using XPIDL and instead use WebIDL. WebBluetooth should transition from XPIDL to WebIDL eventually.

Actions & Recommendations

In general, there seems to be a lack of length/error checking. Things like buffer and integer overflows should be considered more carefully.

• 932543 BluetoothOppManager.cpp heap buffer overflow
• 932608 BluetoothOppManager.cpp insufficient error check
• 932902 BluetoothOppManager.cpp unsafe type mixing
• 932968 FxOS Bluetooth Null Dereferences

Conclusions / Action Items

Now that we've spent some time understanding the WebBluetooth API, we will spend some time digging into the Gaia application to see how it interacts with the API.