All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Archie Pusaka <apusaka@google.com>
Cc: linux-bluetooth <linux-bluetooth@vger.kernel.org>,
	Archie Pusaka <apusaka@chromium.org>
Subject: Re: [Bluez PATCH v4 4/4] unit/test-gatt: Fix unknown request with signed bit
Date: Tue, 7 Apr 2020 10:55:56 -0700	[thread overview]
Message-ID: <CABBYNZ++tW29c2DSjuJCp_F2NjLfSVUXkPL228hkEAR0Uxzbtg@mail.gmail.com> (raw)
In-Reply-To: <20200407165521.Bluez.v4.4.I6813a39e5d8499d24471d7b575c7ef6c493a046c@changeid>

Hi Archie,

On Tue, Apr 7, 2020 at 1:56 AM Archie Pusaka <apusaka@google.com> wrote:
>
> From: Archie Pusaka <apusaka@chromium.org>
>
> The BT spec doesn't make it explicit of what should happen when
> receiving a bad signed att request packet.
>
> According to BT core spec Vol 3, Part C, Sec 10.4.2:
> A device receiving signed data shall authenticate it by performing
> the Signing Algorithm. If the MAC computed by the Signing Algorithm
> does not match the received MAC, the verification fails and the Host
> shall ignore the received Data PDU.

In my interpretation 'ignore the received Data PDU' may not supersed
the followin statement:

> According to BT core spec Vol 3, Part F, Sec 3.3
> If a server receives a request that it does not support, then the
> server shall respond with the ATT_ERROR_RSP PDU with the error code
> Request Not Supported.

So what I think we should be doing is to ignore the received data,
meaning it should not even be processed as a signed data since we
don't understand the command, _and_ respond with ATT_ERROR_RSP,
otherwise we risk having the 30 seconds timeout and disconnecting
since the request is no responded.

> This patch does this two things:
> (1) Removing the signed bit to the existing tests so they are not
>     in a conflicting state within the bluetooth spec, while still
>     keeping the original intent of the test.
> (2) Add another test that purposely fall within this grey area
>     with some comments.
> ---
>
> Changes in v4:
> - Fixing test-gatt.c
>
> Changes in v3: None
> Changes in v2: None
>
>  unit/test-gatt.c | 32 +++++++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/unit/test-gatt.c b/unit/test-gatt.c
> index 36dd2847c..139a6fc72 100644
> --- a/unit/test-gatt.c
> +++ b/unit/test-gatt.c
> @@ -4473,16 +4473,38 @@ int main(int argc, char *argv[])
>                         raw_pdu(0x18, 0x01),
>                         raw_pdu(0x01, 0x18, 0x25, 0x00, 0x06));
>
> -       define_test_server("/robustness/unkown-request",
> +       define_test_server("/robustness/unknown-request",
>                         test_server, service_db_1, NULL,
>                         raw_pdu(0x03, 0x00, 0x02),
> -                       raw_pdu(0xbf, 0x00),
> -                       raw_pdu(0x01, 0xbf, 0x00, 0x00, 0x06));
> +                       raw_pdu(0x3f, 0x00),
> +                       raw_pdu(0x01, 0x3f, 0x00, 0x00, 0x06));

Afaik we used 0xbf because that was what PTS was using.

> +       define_test_server("/robustness/unknown-command",
> +                       test_server, service_db_1, NULL,
> +                       raw_pdu(0x03, 0x00, 0x02),
> +                       raw_pdu(0x7f, 0x00),
> +                       raw_pdu());
>
> -       define_test_server("/robustness/unkown-command",
> +       /*
> +        * According to BT core spec Vol 3, Part C, Sec 10.4.2:
> +        * A device receiving signed data shall authenticate it by performing
> +        * the Signing Algorithm. If the MAC computed by the Signing Algorithm
> +        * does not match the received MAC, the verification fails and the Host
> +        * shall ignore the received Data PDU.
> +        *
> +        * However, according to BT core spec Vol 3, Part F, Sec 3.3
> +        * If a server receives a request that it does not support, then the
> +        * server shall respond with the ATT_ERROR_RSP PDU with the error code
> +        * Request Not Supported.
> +        *
> +        * Since there is no explicit instruction on what should be done in
> +        * case the server receives a bad signed unsupported request, here
> +        * we just ignore the received PDU.
> +        */
> +       define_test_server("/robustness/signed-unknown-request",
>                         test_server, service_db_1, NULL,
>                         raw_pdu(0x03, 0x00, 0x02),
> -                       raw_pdu(0xff, 0x00),
> +                       raw_pdu(0xbf, 0x00),
>                         raw_pdu());
>
>         return tester_run();
> --
> 2.26.0.292.g33ef6b2f38-goog
>


-- 
Luiz Augusto von Dentz

  reply	other threads:[~2020-04-07 17:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07  8:56 [Bluez PATCH v4 0/4] Check the signature of att packets Archie Pusaka
2020-04-07  8:56 ` [Bluez PATCH v4 1/4] shared/crypto: Add bt_crypto_verify_att_sign Archie Pusaka
2020-04-07  8:56 ` [Bluez PATCH v4 2/4] unit/test-crypto: test for bt_crypto_verify_att_sign Archie Pusaka
2020-04-07  8:56 ` [Bluez PATCH v4 3/4] shared/att: Check the signature of att packets Archie Pusaka
2020-04-07  8:56 ` [Bluez PATCH v4 4/4] unit/test-gatt: Fix unknown request with signed bit Archie Pusaka
2020-04-07 17:55   ` Luiz Augusto von Dentz [this message]
2020-04-07 20:07 ` [Bluez PATCH v4 0/4] Check the signature of att packets Luiz Augusto von Dentz
2020-04-08  3:41   ` Archie Pusaka

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=CABBYNZ++tW29c2DSjuJCp_F2NjLfSVUXkPL228hkEAR0Uxzbtg@mail.gmail.com \
    --to=luiz.dentz@gmail.com \
    --cc=apusaka@chromium.org \
    --cc=apusaka@google.com \
    --cc=linux-bluetooth@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.