Impact
When the Bluetooth plug is running (in discoverable mode), Bluetooth service requests and pairing requests are automatically accepted, allowing physically proximate attackers to pair with a device running an affected version of switchboard-plug-bluetooth without the active consent of the user.
By default, elementary OS doesn't expose any services via Bluetooth that allow information to be extracted by paired Bluetooth devices. However, if such services (i.e. contact list sharing software) have been installed, it's possible that attackers have been able to extract data from such services without authorization.
If no such services have been installed, attackers are only able to pair with a device running an affected version without authorization and then play audio out of the device or possibly present a HID device (keyboard, mouse, etc...) to control the device.
As such, users should check the list of trusted/paired devices and remove any that are not 100% confirmed to be genuine.
Patches
https://github.com/elementary/switchboard-plug-bluetooth-ghsa-5p3g-j69g-w2mq/pull/1
Workarounds
To reduce the likelihood of this vulnerability on an unpatched version, only open the Bluetooth plug for short intervals when absolutely necessary and preferably not in crowded public areas. To mitigate the risk entirely with unpatched versions, do not open the Bluetooth plug within switchboard at all, and use a different method for pairing devices if necessary (e.g. bluetoothctl CLI).
Further information
This is caused by the methods that the Bluez agent exposes requiring an explicit error to be throwing if pairing is to be rejected, if they return with no error before then, pairing is accepted. See the below code snippet for an example:
|
public void request_confirmation (ObjectPath device, uint32 passkey) throws Error, BluezError { |
|
var pair_dialog = new PairDialog.request_confirmation (device, passkey, main_window); |
|
pair_dialog.present (); |
|
} |
The dialog is presented and the method returns immediately (which implies pairing acceptance to bluez). The response of the dialog is therefore irrelevant and ignored. In fact, the dialog is destroyed once the pairing succeeds. So if a remote device is fast enough, it can initiate pairing and have it authorized with only a small flicker of the dialog on screen.
davidmhewitt Analyst
Impact
When the Bluetooth plug is running (in discoverable mode), Bluetooth service requests and pairing requests are automatically accepted, allowing physically proximate attackers to pair with a device running an affected version of switchboard-plug-bluetooth without the active consent of the user.
By default, elementary OS doesn't expose any services via Bluetooth that allow information to be extracted by paired Bluetooth devices. However, if such services (i.e. contact list sharing software) have been installed, it's possible that attackers have been able to extract data from such services without authorization.
If no such services have been installed, attackers are only able to pair with a device running an affected version without authorization and then play audio out of the device or possibly present a HID device (keyboard, mouse, etc...) to control the device.
As such, users should check the list of trusted/paired devices and remove any that are not 100% confirmed to be genuine.
Patches
https://github.com/elementary/switchboard-plug-bluetooth-ghsa-5p3g-j69g-w2mq/pull/1
Workarounds
To reduce the likelihood of this vulnerability on an unpatched version, only open the Bluetooth plug for short intervals when absolutely necessary and preferably not in crowded public areas. To mitigate the risk entirely with unpatched versions, do not open the Bluetooth plug within switchboard at all, and use a different method for pairing devices if necessary (e.g.
bluetoothctlCLI).Further information
This is caused by the methods that the Bluez agent exposes requiring an explicit error to be throwing if pairing is to be rejected, if they return with no error before then, pairing is accepted. See the below code snippet for an example:
switchboard-plug-bluetooth/src/Services/Agent.vala
Lines 81 to 84 in 21f6236
The dialog is presented and the method returns immediately (which implies pairing acceptance to bluez). The response of the dialog is therefore irrelevant and ignored. In fact, the dialog is destroyed once the pairing succeeds. So if a remote device is fast enough, it can initiate pairing and have it authorized with only a small flicker of the dialog on screen.