BLE stack unresponsive after receiving ConnectionRequest with connection timeout field set to 0

[kpreiss]

Hi,

We are using nrf Connect SDK 2.4.0 and have been looking through the NIST vulnerabilities databases.  One of the vulnerabilities reported with the nrf5340 is a denial of service which occurs when sending  a ConnectionRequest with the connection timeout set to zero.  Apparently, the BLE stack locks up and the application is not notified.  From the database, it was not clear what version of the SDK was used in the testing.  Does this issue occur in v2.4.0 of the SDK or has it been fixed in a later SDK?

Thank you.

[Einar Thorsrud]

Hi,

Are you referring to CVE-2022-40480? nRF Connect SDK 2.2.0 included a fix that exploitation of this vulnerability. This is described in the SoftDevice Controller changelog for 2.2.0:

Fixed an issue where the controller accepts CONNECT_IND, AUX_CONNECT_REQ and CONNECTION_UPDATE_REQ packets with the connSupervisionTimeout value set to 0 (DRGN-17776).

[kpreiss]

Hi Einar,  

Yes, this is the CVE-2022-404 which I'm referring to.  Do you know if the other issues (E7, I1) were also resolved?

Thank you!

[Einar Thorsrud]

Hi,

I am not sure what this refers to. Can you share the full CVE name or similar?

[kpreiss]

Hi Einar,

I am referring to the issues referenced on the website, https://blediff.github.io/.

The website references issues E6, E7, and I1 as impacting the NRF5340-DK.  Issue E6 referred to sending a connectionrequest with connection timeout set to zero.  Issue I1 refers to reject messages not being sent or out of order and E7 refers to accepting a PauseEncREQPlanText before pairing is complete.  The website goes into details on each issue.

Thanks.

[Einar Thorsrud]

Hi,

I see. The E7 issue in that list is also fixed in SDK 2.2.0. From the changelog:

Fixed an issue where the controller accepts an LL_PAUSE_ENC_REQ packet received on an unencrypted link (DRGN-17777).

The issue refered to as I1 in that list we deem invalid and it will not be "fixed". Backround: The spec. allows different behavior and conformant device must allow all of them, so there should be no IOP issues with conformant devices. Furthermore, if ECDH math is implemented in the controller, the HCI_LE_Generate_DHKey command is the first place where controller has a chance to check for validness of peer’s Public Key. See BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part B page 2834 4.6.26 Remote Public Key Validation. A Controller that supports Remote Public Key Validation shall validate the remote public key (see [Vol 3] Part H, Section 2.3.5.6.1) sent by the Host in the HCI_LE_Generate_DHKey command (see [Vol 4] Part E, Section 7.8.37).

[kpreiss]

Thank you very much Einar!  That answers all my questions.

Best,

Kurt