| Message ID | 20200918110223.GA10235@laptop-alex (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Bluetooth: Fix the vulnerable issue on enc key size | expand |
Hi Alex, > When someone attacks the service provider, it creates connection, > authenticates. Then it requests key size of one byte and it identifies > the key with brute force methods. > > After l2cap info req/resp exchange is complete. the attacker sends l2cap > connect with specific PSM. > > In above procedure, there is no chance for the service provider to check > the encryption key size before l2cap_connect(). Because the state of > l2cap chan in conn->chan_l is BT_LISTEN, there is no l2cap chan with the > state of BT_CONNECT or BT_CONNECT2. > > So service provider should check the encryption key size in > l2cap_connect() > > Signed-off-by: Alex Lu <alex_lu@realsil.com.cn> > --- > net/bluetooth/l2cap_core.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c > index ade83e224567..63df961d402d 100644 > --- a/net/bluetooth/l2cap_core.c > +++ b/net/bluetooth/l2cap_core.c > @@ -4150,6 +4150,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn, > > if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE) { > if (l2cap_chan_check_security(chan, false)) { > + if (!l2cap_check_enc_key_size(conn->hcon)) { > + l2cap_state_change(chan, BT_DISCONN); > + __set_chan_timer(chan, L2CAP_DISC_TIMEOUT); > + result = L2CAP_CR_SEC_BLOCK; > + status = L2CAP_CS_NO_INFO; > + goto response; > + } > if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) { > l2cap_state_change(chan, BT_CONNECT2); > result = L2CAP_CR_PEND; I am not following what you are trying to fix here. Can you show this with a btmon trace from an attacking device? Regards Marcel
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index ade83e224567..63df961d402d 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -4150,6 +4150,13 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_conn *conn, if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE) { if (l2cap_chan_check_security(chan, false)) { + if (!l2cap_check_enc_key_size(conn->hcon)) { + l2cap_state_change(chan, BT_DISCONN); + __set_chan_timer(chan, L2CAP_DISC_TIMEOUT); + result = L2CAP_CR_SEC_BLOCK; + status = L2CAP_CS_NO_INFO; + goto response; + } if (test_bit(FLAG_DEFER_SETUP, &chan->flags)) { l2cap_state_change(chan, BT_CONNECT2); result = L2CAP_CR_PEND;
When someone attacks the service provider, it creates connection, authenticates. Then it requests key size of one byte and it identifies the key with brute force methods. After l2cap info req/resp exchange is complete. the attacker sends l2cap connect with specific PSM. In above procedure, there is no chance for the service provider to check the encryption key size before l2cap_connect(). Because the state of l2cap chan in conn->chan_l is BT_LISTEN, there is no l2cap chan with the state of BT_CONNECT or BT_CONNECT2. So service provider should check the encryption key size in l2cap_connect() Signed-off-by: Alex Lu <alex_lu@realsil.com.cn> --- net/bluetooth/l2cap_core.c | 7 +++++++ 1 file changed, 7 insertions(+)