linux-kernel - Re: [PATCH] Bluetooth: Avoid redundant authentication

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] [day] [month] [year] [list]

Date:   Wed, 6 Sep 2023 12:45:19 -0700
From:   Luiz Augusto von Dentz <luiz.dentz@...il.com>
To:     Ying Hsu <yinghsu@...omium.org>
Cc:     linux-bluetooth@...r.kernel.org, marcel@...tmann.org,
        chromeos-bluetooth-upstreaming@...omium.org,
        Johan Hedberg <johan.hedberg@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: Avoid redundant authentication

Hi Ying,

On Tue, Sep 5, 2023 at 8:48 PM Ying Hsu <yinghsu@...omium.org> wrote:
>
> While executing the Android 13 CTS Verifier Secure Server test on a
> ChromeOS device, it was observed that the Bluetooth host initiates
> authentication for an RFCOMM connection after SSP completes.
> When this happens, some Intel Bluetooth controllers, like AC9560, would
> disconnect with "Connection Rejected due to Security Reasons (0x0e)".
>
> Historically, BlueZ did not mandate this authentication while an
> authenticated combination key was already in use for the connection.
> This behavior was changed since commit 7b5a9241b780
> ("Bluetooth: Introduce requirements for security level 4").
> So, this patch addresses the aforementioned disconnection issue by
> restoring the previous behavior.
>
> Signed-off-by: Ying Hsu <yinghsu@...omium.org>
> ---
> Tested CTS Verifier 13 Secure Server test on a chromebook with AC9560.
>
>  net/bluetooth/hci_conn.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 9d5057cef30a..27c0a3080631 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -2420,10 +2420,11 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
>                 goto encrypt;
>
>         /* An authenticated combination key has sufficient security for
> -          security level 3. */
> +        * security level 3 or lower.
> +        */
>         if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 ||
>              conn->key_type == HCI_LK_AUTH_COMBINATION_P256) &&
> -           sec_level == BT_SECURITY_HIGH)
> +           sec_level <= BT_SECURITY_HIGH)
>                 goto encrypt;
>
>         /* An unauthenticated combination key has sufficient security for
> --
> 2.42.0.283.g2d96d420d3-goog

How about we do something like:

https://gist.github.com/Vudentz/be49a40789ec713f9441face9bd642cc

That way we cover similar situations for other security levels.

-- 
Luiz Augusto von Dentz