linux-kernel - Re: [PATCH v2] Bluetooth: hci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2023 10:22:26 -0700
From:   Luiz Augusto von Dentz <luiz.dentz@...il.com>
To:     "Lee, Chun-Yi" <joeyli.kernel@...il.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org,
        Markus Elfring <Markus.Elfring@....de>,
        Dan Carpenter <dan.carpenter@...aro.org>,
        linux-bluetooth@...r.kernel.org, "Lee, Chun-Yi" <jlee@...e.com>
Subject: Re: [PATCH v2] Bluetooth: hci_event: Ignore NULL link key

Hi Chun-Yi,

On Mon, Jul 17, 2023 at 8:43 PM Lee, Chun-Yi <joeyli.kernel@...il.com> wrote:
>
> This change is used to relieve CVE-2020-26555. The description of the
> CVE:
>
> Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification
> 1.0B through 5.2 may permit an unauthenticated nearby device to spoof
> the BD_ADDR of the peer device to complete pairing without knowledge
> of the PIN. [1]

Btw, it is probably worth mentioning that in BR/EDR the key generation
is actually handled in the controller, below HCI.

> The detail of this attack is in IEEE paper:
> BlueMirror: Reflections on Bluetooth Pairing and Provisioning Protocols
> [2]
>
> It's a reflection attack. Base on the paper, attacker can induce the
> attacked target to generate null link key (zero key) without PIN code.
>
> We can ignore null link key in the handler of "Link Key Notification
> event" to relieve the attack. A similar implementation also shows in
> btstack project. [3]

Perhaps we could clarify this statement by stating that if we ignore
the link key it means the stack will not consider the device is bonded
and will not persist the link key, that said the controller will still
consider it as paired, so I perhaps we should go one step forward and
disconnect if we detect such a key is being used.

> v2:
> - Used Link: tag instead of Closes:
> - Used bt_dev_dbg instead of BT_DBG
> - Added Fixes: tag
>
> Fixes: 55ed8ca10f35 ("Bluetooth: Implement link key handling for the management interface")
> Link: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26555 [1]
> Link: https://ieeexplore.ieee.org/abstract/document/9474325/authors#authors [2]
> Link: https://github.com/bluekitchen/btstack/blob/master/src/hci.c#L3722 [3]
> Signed-off-by: "Lee, Chun-Yi" <jlee@...e.com>
> ---
>  net/bluetooth/hci_event.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 95816a938cea..ff0c331f53d6 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -4684,6 +4684,12 @@ static void hci_link_key_notify_evt(struct hci_dev *hdev, void *data,
>         bool persistent;
>         u8 pin_len = 0;
>
> +       /* Ignore NULL link key against CVE-2020-26555 */
> +       if (!memcmp(ev->link_key, ZERO_KEY, HCI_LINK_KEY_SIZE)) {
> +               bt_dev_dbg(hdev, "Ignore NULL link key (ZERO KEY) for %pMR", &ev->bdaddr);
> +               return;
> +       }
> +
>         bt_dev_dbg(hdev, "");
>
>         hci_dev_lock(hdev);
> --
> 2.35.3
>


-- 
Luiz Augusto von Dentz