Security questions on the Bluetooth serial API. #186

Activity

1. reillyeon

   assigned

   nondebug

   on Jun 13, 2023
2. nondebug commented on Jun 13, 2023

   

   nondebug

   on Jun 13, 2023

   Collaborator

   More actions

   Hi Arthur, thanks for taking a look.

   Are the service UUIDs fixed to this list https://www.bluetooth.com/specifications/specs/ or can you have truly custom ones?

   Service UUIDs aren't fixed. Vendors can create their own 128-bit UUIDs to represent vendor-defined services.

   For this feature, all services with UUIDs reserved by the Bluetooth spec will be blocked except for Serial Port Profile.

   If truly custom ones exist, do you have an idea of the kind of use cases that would involve them?

   Custom UUIDs are used for any functionality not covered by the standard profiles. A device might expose a serial service with a custom UUID as a debugging interface, or as an interface to access advanced features not included in the standard profile.

   Do you know if there exists a list of vulnerable devices or would we need to craft one?

   Rather than blocking per-device, we plan to maintain a list of vulnerable service UUIDs. There's a table defined in the Chromium source code but it contains no UUID entries because we don't know of any custom service UUIDs that should be blocked. The standard Bluetooth UUIDs are blocked by a rule that compares the UUID to the Bluetooth Base UUID; this is less error-prone than maintaining a list of all such services.

   Is there any reason to not standardize the defense mechanisms? Do you expect for example platforms to matter and the browser would have to mitigate depending on a heuristic?

   There's no reason not to publish the UUID blocklist as part of the specification and I expect we will update the spec with a blocklist. This is similar to how we handle vulnerable devices for other device APIs: WebUSB, WebHID, Web Bluetooth.

   Currently there's no serial blocklist because (as described in Security Considerations) a blocklist-based filtering mechanism doesn't work well for RS-232 ports or serial adapters which don't provide any metadata about the connected serial device. That's not the case for Bluetooth, we can identify vulnerable devices by the services they expose.

   I don't expect we would need to change the blocking behavior for different platforms. It will be least confusing for users and developers if device compatibility is consistent across all platforms and implementations.