Impact
I have discovered what I think is a potential vulnerability in Zephyr's SMP
implementation.
There is an error in the condition of the last if-statement in the function smp_check_keys,
i.e. the one that looks to be checking that the keys requirements of level 4 and higher are met.
As written, it appears to reject the current keys if ALL requirements are
unmet, but my understanding is that it should reject the keys if ANY of the requirements are unmet.
Here is a diff showing exactly what I think is wrong and how it could be
fixed:
diff --git a/subsys/bluetooth/host/smp.c b/subsys/bluetooth/host/smp.c
index 5132ad7495..3581b77bd6 100644
--- a/subsys/bluetooth/host/smp.c
+++ b/subsys/bluetooth/host/smp.c
@@ -363,9 +363,9 @@ static bool smp_keys_check(struct bt_conn *conn)
}
if (conn->required_sec_level > BT_SECURITY_L3 &&
- !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED) &&
- !(conn->le.keys->keys & BT_KEYS_LTK_P256) &&
- !(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE)) {
+ (!(conn->le.keys->flags & BT_KEYS_AUTHENTICATED) ||
+ !(conn->le.keys->keys & BT_KEYS_LTK_P256) ||
+ !(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE))) {
return false;
}
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2022-11-03
Impact
I have discovered what I think is a potential vulnerability in Zephyr's SMP
implementation.
There is an error in the condition of the last if-statement in the function
smp_check_keys,i.e. the one that looks to be checking that the keys requirements of level 4 and higher are met.
As written, it appears to reject the current keys if ALL requirements are
unmet, but my understanding is that it should reject the keys if ANY of the requirements are unmet.
Here is a diff showing exactly what I think is wrong and how it could be
fixed:
Patches
For more information
If you have any questions or comments about this advisory:
embargo: 2022-11-03