diff options
author | Howard Chung <howardchung@google.com> | 2020-02-14 19:16:41 +0800 |
---|---|---|
committer | Marcel Holtmann <marcel@holtmann.org> | 2020-02-14 16:01:00 +0100 |
commit | cee5f20fece32cd1722230cb05333f39db860698 (patch) | |
tree | eb9a7c8d9c7b6f759aecbcd8b5e7a4e515fab035 /net/bluetooth/smp.c | |
parent | c920a191302e3a4b3a98aeabce37d715fdf5cea5 (diff) |
Bluetooth: secure bluetooth stack from bluedump attack
Attack scenario:
1. A Chromebook (let's call this device A) is paired to a legitimate
Bluetooth classic device (e.g. a speaker) (let's call this device
B).
2. A malicious device (let's call this device C) pretends to be the
Bluetooth speaker by using the same BT address.
3. If device A is not currently connected to device B, device A will
be ready to accept connection from device B in the background
(technically, doing Page Scan).
4. Therefore, device C can initiate connection to device A
(because device A is doing Page Scan) and device A will accept the
connection because device A trusts device C's address which is the
same as device B's address.
5. Device C won't be able to communicate at any high level Bluetooth
profile with device A because device A enforces that device C is
encrypted with their common Link Key, which device C doesn't have.
But device C can initiate pairing with device A with just-works
model without requiring user interaction (there is only pairing
notification). After pairing, device A now trusts device C with a
new different link key, common between device A and C.
6. From now on, device A trusts device C, so device C can at anytime
connect to device A to do any kind of high-level hijacking, e.g.
speaker hijack or mouse/keyboard hijack.
Since we don't know whether the repairing is legitimate or not,
leave the decision to user space if all the conditions below are met.
- the pairing is initialized by peer
- the authorization method is just-work
- host already had the link key to the peer
Signed-off-by: Howard Chung <howardchung@google.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net/bluetooth/smp.c')
-rw-r--r-- | net/bluetooth/smp.c | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c index 83449a88a182..50e0ac692ec4 100644 --- a/net/bluetooth/smp.c +++ b/net/bluetooth/smp.c @@ -2168,6 +2168,25 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb) smp_send_cmd(conn, SMP_CMD_PAIRING_RANDOM, sizeof(smp->prnd), smp->prnd); SMP_ALLOW_CMD(smp, SMP_CMD_DHKEY_CHECK); + + /* Only Just-Works pairing requires extra checks */ + if (smp->method != JUST_WORKS) + goto mackey_and_ltk; + + /* If there already exists long term key in local host, leave + * the decision to user space since the remote device could + * be legitimate or malicious. + */ + if (hci_find_ltk(hcon->hdev, &hcon->dst, hcon->dst_type, + hcon->role)) { + err = mgmt_user_confirm_request(hcon->hdev, &hcon->dst, + hcon->type, + hcon->dst_type, + passkey, 1); + if (err) + return SMP_UNSPECIFIED; + set_bit(SMP_FLAG_WAIT_USER, &smp->flags); + } } mackey_and_ltk: |