Bug 358753 - unauthorized device autoconnects
Summary: unauthorized device autoconnects
Status: RESOLVED NOT A BUG
Alias: None
Product: Bluedevil
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: 5.4.3
Platform: Other Linux
: NOR critical
Target Milestone: ---
Assignee: David Rosca
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-29 22:37 UTC by arne anka
Modified: 2016-01-30 19:34 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description arne anka 2016-01-29 22:37:23 UTC
in short: an unknown iPhone apparently connected via BT to my computer without my approval.

long:
just now there was first a not fully rendered notification bubble, followed immediatelly by another one asking
"iPhone LB is asking if the PIN is correct: 503545"
since i don't have an iPhone, i replied with "no" and had a look at the list of connected devices -- and despite my refusal, that iPhone was listed as connected device!

i hit disconnect, which only showed a spinner, and after a few seconds pulled the BT dongle.

checking the .xsession-errors, i found _two_ requests with two different PINs, of which i catched  only the second one:

log_kioremote: RemoteDirNotify::FilesAdded
log_kioremote: RemoteDirNotify::toRemoteURL( QUrl("bluetooth:/") )
log_kioremote: result => KUrl()
QXcbConnection: XCB error: 3 (BadWindow), sequence: 11666, resource id: 69206019, major code: 15 (QueryTree), minor code: 0
log_kioremote: RemoteDirNotify::FilesAdded
log_kioremote: RemoteDirNotify::toRemoteURL( QUrl("bluetooth:/") )
log_kioremote: result => KUrl()
bluedevil: AGENT-RequestConfirmation  "iPhone LB" "088305"
Currrent active notifications: QHash()
Guessing partOf as: 0
 New Notification:  "Bluetooth system" "iPhone LB is asking if the PIN is correct: 088305" 0 & Part of: 0
qml:  totalCountChanged 1
qml:  totalCountChanged 1
qml:  totalCountChanged 0
qml:  totalCountChanged 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 13455, resource id: 81788932, major code: 18 (ChangeProperty), minor code: 0
bluedevil: ProcessClosed:  1
bluedevil: Rejecting request
QXcbConnection: XCB error: 3 (BadWindow), sequence: 13496, resource id: 38377497, major code: 3 (GetWindowAttributes), minor code: 0
file:///usr/share/plasma/plasmoids/org.kde.plasma.mediacontroller/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling.
file:///usr/share/plasma/plasmoids/org.kde.plasma.mediacontroller/contents/ui/main.qml: QML Plasmoid: Cannot anchor to an item that isn't a parent or sibling.
bluedevil: AGENT-RequestConfirmation  "iPhone LB" "503545"
Currrent active notifications: QHash()
Guessing partOf as: 0
 New Notification:  "Bluetooth system" "iPhone LB is asking if the PIN is correct: 503545" 0 & Part of: 0

i am a bit scared to see that a strange BT device apparently is able to connect to my computer -- be it despite my refusal or, worse, because the confirmation popup wasn't rendered/seen by me!

the BT adapter was set to "always visible", but that shouldn't lead to unauthorized connections, right?
Comment 1 David Rosca 2016-01-30 10:28:36 UTC
The device is shown as connected when pairing process is in progress, because in fact it is. But it does not mean it is connected to some profile, which would allow it to do anything.

Bluedevil does not automatically accepts pairing requests, so if you didn't accept the PIN (which seems you didn't), there is nothing to worry about.

Also, if you don't catch the notification and it timeouts, the pairing request is automatically cancelled.
Comment 2 David Rosca 2016-01-30 10:29:57 UTC
And one last thing, the only thing you can do is to set your adapter to Hidden. There is no other way to stop other devices initiate pairing with your adapter.
Comment 3 arne anka 2016-01-30 19:08:01 UTC
i see, thanks for the info.
but maybe to show a dedicated name for that pairing phase, different from "connected" would be helpful?
Comment 4 David Rosca 2016-01-30 19:10:04 UTC
(In reply to arne anka from comment #3)
> but maybe to show a dedicated name for that pairing phase, different from
> "connected" would be helpful?

But there is no way to distinguish it, BlueZ just reports connected.
Comment 5 arne anka 2016-01-30 19:33:48 UTC
but according to the log snippet, the pairing request is handled through bluedevil -- wouldn't it be possible to use that as a distinguishing feature?
incoming/pending pairing request of unknown device -> "pairing requested"
denied -> "pairing denied" (if it takes longer to disconnect again/update the listing)
accepted -> as is
Comment 6 David Rosca 2016-01-30 19:34:44 UTC
Sorry but no, it would be only guessing.