Setting tentative impact-stable / severity-medium under the assumption that we might allow short term pairings, but exploitation requires another bug.

Looks like all of this auto-accept logic would be in Chrome and would be one of the various implementations of device::BluetoothDevice::PairingDelegate::AuthorizePairing. It doesn't look like we do much auto-accepting here, and it seems like we don't take the IO caps into effect at all at this point, so we're almost certainly not going to have the same issues as Android or Windows are shown to have in the paper.

BluetoothHostPairingController and BluetoothControllerPairingController auto-reject all pairing requests. The BluetoothNotificationController asks the user to accept or reject pairings. HIDDetectionScreen auto-accepts but has a comment saying this should never be reached; perhaps to be safe we should NOTREACHED() here, or at least log an error. BluetoothApiPairingDelegate sends out an event, but that can only be seen by users of the private API, so that should be fine.

+rkc@ to keep me honest here. :P

Yes, Chrome specifically does not accept any auto-pairing due to security reasons. A pairing delegate can be provided by the private API but AFAIK it isn't being used to auto-pair by any app "anymore".

It used to be used by GVC to auto-pair with the remote app during their restricted fishfood but this does not seem to be the behavior anymore.

Cool, I think we avoided this particular issue then. Thanks Rahul!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot