Impact
Vulnerability in the Zephyr Bluetooth host related to the encryption procedure. The vulnerability can be triggered by a custom-made remote controller which does not obey the rules for rejecting encryption procedure by using a status code indicating that the procedure was successful despite the rejection
Summary
Excerpt from the Bluetooth Core specification Version 5.X | Vol 6, Part D:
Bluetooth Central starts to encrypt the ACL
A malicious Bluetooth Peripheral imitates a Negative Reply with a REJECT_IND or REJECT_EXT_IND with
either:
reject_ind.error_code = 0 (SUCCESS)
or
reject_ext_ind.reject_opcode = LL_ENC_REQ
reject_ext_ind.error_code = 0 (SUCCESS)
This will lead to a encryption_change event (Core 5.X | Vol 4, Part E, 7.7.8 Encryption Change event) handled inside hci_encrypt_change
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/hci_core.c#L2089
Issue:
The host code trusts and uses evt->error_code rather than evt->encrypt in many cases, which leads to a broad assumption throughout the host that the ACL is encrypted despite that the encryption was rejected by the peripheral.
The issue exposes a security vulnerability at several protocol layers:
- l2cap
- att
- smp
- application
- Several cases, for instance isochronous channels where an audio stream may be established on a supposedly encrypted link.
Workarounds
Translate the status field of the encryption change event to "UNSPECIFIED" if the procedure was rejected and the link is not encrypted.
This workaround can be implemented either in the controller or in the host.
Proposed fix
Similar to the workaround in the controller, but inside the host's handler of the encrypt change event.
Patches
main: #73945
v3.6: #74124
v3.5: #74123
v2.7: #74122
For more information
If you have any questions or comments about this advisory:
embargo: 2024-09-04
Credits
"Stridkvist, Johan" [email protected]
Impact
Vulnerability in the Zephyr Bluetooth host related to the encryption procedure. The vulnerability can be triggered by a custom-made remote controller which does not obey the rules for rejecting encryption procedure by using a status code indicating that the procedure was successful despite the rejection
Summary
Excerpt from the Bluetooth Core specification Version 5.X | Vol 6, Part D:
Bluetooth Central starts to encrypt the ACL
A malicious Bluetooth Peripheral imitates a Negative Reply with a
REJECT_INDorREJECT_EXT_INDwitheither:
reject_ind.error_code = 0 (SUCCESS)
or
reject_ext_ind.reject_opcode = LL_ENC_REQ
reject_ext_ind.error_code = 0 (SUCCESS)
This will lead to a encryption_change event (Core 5.X | Vol 4, Part E, 7.7.8 Encryption Change event) handled inside hci_encrypt_change
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/host/hci_core.c#L2089
Issue:
The host code trusts and uses
evt->error_coderather thanevt->encryptin many cases, which leads to a broad assumption throughout the host that the ACL is encrypted despite that the encryption was rejected by the peripheral.The issue exposes a security vulnerability at several protocol layers:
Workarounds
Translate the status field of the encryption change event to
"UNSPECIFIED"if the procedure was rejected and the link is not encrypted.This workaround can be implemented either in the controller or in the host.
Proposed fix
Similar to the workaround in the controller, but inside the host's handler of the encrypt change event.
Patches
main: #73945
v3.6: #74124
v3.5: #74123
v2.7: #74122
For more information
If you have any questions or comments about this advisory:
embargo: 2024-09-04
Credits
"Stridkvist, Johan" [email protected]