From: Howard Chung <howardchung@google.com>
To: linux-bluetooth@vger.kernel.org, marcel@holtmann.org
Cc: chromeos-bluetooth-upstreaming@chromium.org,
Howard Chung <howardchung@google.com>,
"David S. Miller" <davem@davemloft.net>,
Johan Hedberg <johan.hedberg@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Jakub Kicinski <kuba@kernel.org>
Subject: [Bluez PATCH v2] bluetooth: secure bluetooth stack from bluedump attack
Date: Fri, 7 Feb 2020 18:04:00 +0800 [thread overview]
Message-ID: <20200207180348.Bluez.v2.1.Ia71869d2f3e19a76a6a352c61088a085a1d41ba6@changeid> (raw)
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>
---
Changes in v2:
- Remove the HCI_PERMIT_JUST_WORK_REPAIR debugfs option
- Fix the added code in classic
- Add a similar fix for LE
net/bluetooth/hci_event.c | 10 ++++++++++
net/bluetooth/smp.c | 18 ++++++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 6ddc4a74a5e4..334d7ccd8d6e 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4557,6 +4557,16 @@ static void hci_user_confirm_request_evt(struct hci_dev *hdev,
goto confirm;
}
+ /* If there already exists link key in local host, leave the
+ * decision to user space since the remote device could be
+ * legitimate or malicious.
+ */
+ if (hci_find_link_key(hdev, &ev->bdaddr)) {
+ bt_dev_warn(hdev, "Local host already has link key");
+ confirm_hint = 2;
+ goto confirm;
+ }
+
BT_DBG("Auto-accept of user confirmation with %ums delay",
hdev->auto_accept_delay);
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 83449a88a182..f58426dea4de 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2118,6 +2118,7 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
u8 *pkax, *pkbx, *na, *nb;
u32 passkey;
int err;
+ struct smp_ltk *key;
BT_DBG("conn %p", conn);
@@ -2168,6 +2169,23 @@ 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);
+
+ key = hci_find_ltk(hcon->hdev, &hcon->dst, hcon->dst_type,
+ hcon->role);
+
+ /* If there already exists link key in local host, leave the
+ * decision to user space since the remote device could be
+ * legitimate or malicious.
+ */
+ if (smp->method == JUST_WORKS && key) {
+ err = mgmt_user_confirm_request(hcon->hdev, &hcon->dst,
+ hcon->type,
+ hcon->dst_type, passkey,
+ 2);
+ if (err)
+ return SMP_UNSPECIFIED;
+ set_bit(SMP_FLAG_WAIT_USER, &smp->flags);
+ }
}
mackey_and_ltk:
--
2.25.0.341.g760bfbb309-goog
next reply other threads:[~2020-02-07 10:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 10:04 Howard Chung [this message]
2020-02-08 8:21 ` [Bluez PATCH v2] bluetooth: secure bluetooth stack from bluedump attack Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200207180348.Bluez.v2.1.Ia71869d2f3e19a76a6a352c61088a085a1d41ba6@changeid \
--to=howardchung@google.com \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=davem@davemloft.net \
--cc=johan.hedberg@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.