| Message ID | 20200519202519.219335-2-luiz.dentz@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Marcel Holtmann |
| Headers | show |
| Series | [1/4] Bluetooth: Disconnect if E0 is used for Level 4 | expand |
Hi Luiz, > EIR flags should just hint if SSP may be supported but we shall verify > this with use of the actual features as the SSP bits may be disabled in > the lower layers which would result in legacy authentication to be > used. > > Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > --- > net/bluetooth/hci_conn.c | 2 -- > 1 file changed, 2 deletions(-) patch has been applied to bluetooth-next tree. Regards Marcel
Hi Marcel and Luiz, Starting with the 2.1 specification, it is my interpretation that it is not valid to support EIR but not SSP. I understand that SSP may be disabled from BlueZ's point of view, but this doesn't seem to be a legitimate/qualifiable configuration. Should we instead fail the legacy pairing if EIR was received as an invalid condition? Thanks, Alain On Wed, May 20, 2020 at 10:35 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Luiz, > > > EIR flags should just hint if SSP may be supported but we shall verify > > this with use of the actual features as the SSP bits may be disabled in > > the lower layers which would result in legacy authentication to be > > used. > > > > Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> > > --- > > net/bluetooth/hci_conn.c | 2 -- > > 1 file changed, 2 deletions(-) > > patch has been applied to bluetooth-next tree. > > Regards > > Marcel >
Hi Alain, > Starting with the 2.1 specification, it is my interpretation that it > is not valid to support EIR but not SSP. I understand that SSP may be > disabled from BlueZ's point of view, but this doesn't seem to be a > legitimate/qualifiable configuration. Should we instead fail the > legacy pairing if EIR was received as an invalid condition? I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. Regards Marcel
Hi Luiz, On Tue, May 26, 2020 at 10:17 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Alain, > > > Starting with the 2.1 specification, it is my interpretation that it > > is not valid to support EIR but not SSP. I understand that SSP may be > > disabled from BlueZ's point of view, but this doesn't seem to be a > > legitimate/qualifiable configuration. Should we instead fail the > > legacy pairing if EIR was received as an invalid condition? > > I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. > > You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. > > If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. You are correct, the EIR response is not a guaranteed thing. For this reason, the host should try to resolve the name of the device before initiating bonding where a Remote Host Supported Feature Notification Event is generated to signal the remote side's support of SSP. As you allude to, a remote spoofing a legitimate SSP device may always just jam and downgrade to not SSP, but if you have any signals that SSP is supported by the device, it may be a good defensive posture. Receiving an EIR response or a Remote Host Supported Feature Event with the SSP bit set is a good indication that the device supports SSP and you should expect SSP to take place. Again, it is not a valid configuration to have EIR enabled but not SSP per my interpretation of the 2.1 specification. > > Regards > > Marcel >
Hi Alain, >>> Starting with the 2.1 specification, it is my interpretation that it >>> is not valid to support EIR but not SSP. I understand that SSP may be >>> disabled from BlueZ's point of view, but this doesn't seem to be a >>> legitimate/qualifiable configuration. Should we instead fail the >>> legacy pairing if EIR was received as an invalid condition? >> >> I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. >> >> You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. >> >> If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. > > You are correct, the EIR response is not a guaranteed thing. For this > reason, the host should try to resolve the name of the device before > initiating bonding where a Remote Host Supported Feature Notification > Event is generated to signal the remote side's support of SSP. As you > allude to, a remote spoofing a legitimate SSP device may always just > jam and downgrade to not SSP, but if you have any signals that SSP is > supported by the device, it may be a good defensive posture. trying to resolve the name before connected is a waste of time. Resolving the name after connecting will not give you that event. You should just read the remote features. > Receiving an EIR response or a Remote Host Supported Feature Event > with the SSP bit set is a good indication that the device supports SSP > and you should expect SSP to take place. Again, it is not a valid > configuration to have EIR enabled but not SSP per my interpretation of > the 2.1 specification. If you have an idea on how to tighten this and fail, please send a patch. It is just that our inquiry cache was never designed for that. It was just to speed up the connection process. Regards Marcel
On Thu, May 28, 2020 at 4:22 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > Hi Alain, > > >>> Starting with the 2.1 specification, it is my interpretation that it > >>> is not valid to support EIR but not SSP. I understand that SSP may be > >>> disabled from BlueZ's point of view, but this doesn't seem to be a > >>> legitimate/qualifiable configuration. Should we instead fail the > >>> legacy pairing if EIR was received as an invalid condition? > >> > >> I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. > >> > >> You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. > >> > >> If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. > > > > You are correct, the EIR response is not a guaranteed thing. For this > > reason, the host should try to resolve the name of the device before > > initiating bonding where a Remote Host Supported Feature Notification > > Event is generated to signal the remote side's support of SSP. As you > > allude to, a remote spoofing a legitimate SSP device may always just > > jam and downgrade to not SSP, but if you have any signals that SSP is > > supported by the device, it may be a good defensive posture. > > trying to resolve the name before connected is a waste of time. Resolving the name after connecting will not give you that event. You should just read the remote features. I have a vague memory that there was an interoperability issue around this that required the initiator to know ahead of time if SSP was supported by the remote host before connecting which was the reason why this was added in the first place. However, I agree that this can also be read after you are connected rather than just waiting for a RNR page to complete just to page again. The point here however is about the signals that SSP should be supported and the conditions where we let legacy pairing go through. My assertion is that EIR implies SSP, so legacy pairing shouldn't be allowed in that case. It's not a definitive security measure, but IMO, every signals that we can get will help close a door to downgrade attacks. > > > Receiving an EIR response or a Remote Host Supported Feature Event > > with the SSP bit set is a good indication that the device supports SSP > > and you should expect SSP to take place. Again, it is not a valid > > configuration to have EIR enabled but not SSP per my interpretation of > > the 2.1 specification. > > If you have an idea on how to tighten this and fail, please send a patch. It is just that our inquiry cache was never designed for that. It was just to speed up the connection process. Ack. This definitely looks like an opportunity. We can add it to the backlog. > > Regards > > Marcel >
Hi Alain, On Thu, May 28, 2020 at 6:18 AM Alain Michaud <alainmichaud@google.com> wrote: > > On Thu, May 28, 2020 at 4:22 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > Hi Alain, > > > > >>> Starting with the 2.1 specification, it is my interpretation that it > > >>> is not valid to support EIR but not SSP. I understand that SSP may be > > >>> disabled from BlueZ's point of view, but this doesn't seem to be a > > >>> legitimate/qualifiable configuration. Should we instead fail the > > >>> legacy pairing if EIR was received as an invalid condition? > > >> > > >> I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. > > >> > > >> You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. > > >> > > >> If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. > > > > > > You are correct, the EIR response is not a guaranteed thing. For this > > > reason, the host should try to resolve the name of the device before > > > initiating bonding where a Remote Host Supported Feature Notification > > > Event is generated to signal the remote side's support of SSP. As you > > > allude to, a remote spoofing a legitimate SSP device may always just > > > jam and downgrade to not SSP, but if you have any signals that SSP is > > > supported by the device, it may be a good defensive posture. > > > > trying to resolve the name before connected is a waste of time. Resolving the name after connecting will not give you that event. You should just read the remote features. > > I have a vague memory that there was an interoperability issue around > this that required the initiator to know ahead of time if SSP was > supported by the remote host before connecting which was the reason > why this was added in the first place. However, I agree that this can > also be read after you are connected rather than just waiting for a > RNR page to complete just to page again. The point here however is > about the signals that SSP should be supported and the conditions > where we let legacy pairing go through. My assertion is that EIR > implies SSP, so legacy pairing shouldn't be allowed in that case. > It's not a definitive security measure, but IMO, every signals that we > can get will help close a door to downgrade attacks. Legacy pairing is still indicated with MGMT_DEV_FOUND_LEGACY_PAIRING so for what is worth this didn't change any logic regarding how legacy pairing is detected, in fact hci_conn_ssp_enabled is used to determine if encryption is required or not for low security it was never used to detect if the paring method used was really SSP or legacy. > > > > > Receiving an EIR response or a Remote Host Supported Feature Event > > > with the SSP bit set is a good indication that the device supports SSP > > > and you should expect SSP to take place. Again, it is not a valid > > > configuration to have EIR enabled but not SSP per my interpretation of > > > the 2.1 specification. > > > > If you have an idea on how to tighten this and fail, please send a patch. It is just that our inquiry cache was never designed for that. It was just to speed up the connection process. > Ack. This definitely looks like an opportunity. We can add it to the backlog. If you guys agree I can prepare a patch requiring SSP to be used, but first we will need to agree on what action we would take under such situation, shall we disconnect if we figure out the SSP bit is disabled? Btw, if the remote device has dropped SSP for some reason (I suppose the spec allows doing it) and we have a EIR on the cache (which we keep for 30 seconds) that doesn't necessarily mean the device is broken since the use of EIR may have been dropped in the meantime. > > > > Regards > > > > Marcel > >
Hi Luiz, On Thu, May 28, 2020 at 12:54 PM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Alain, > > On Thu, May 28, 2020 at 6:18 AM Alain Michaud <alainmichaud@google.com> wrote: > > > > On Thu, May 28, 2020 at 4:22 AM Marcel Holtmann <marcel@holtmann.org> wrote: > > > > > > Hi Alain, > > > > > > >>> Starting with the 2.1 specification, it is my interpretation that it > > > >>> is not valid to support EIR but not SSP. I understand that SSP may be > > > >>> disabled from BlueZ's point of view, but this doesn't seem to be a > > > >>> legitimate/qualifiable configuration. Should we instead fail the > > > >>> legacy pairing if EIR was received as an invalid condition? > > > >> > > > >> I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. > > > >> > > > >> You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. > > > >> > > > >> If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. > > > > > > > > You are correct, the EIR response is not a guaranteed thing. For this > > > > reason, the host should try to resolve the name of the device before > > > > initiating bonding where a Remote Host Supported Feature Notification > > > > Event is generated to signal the remote side's support of SSP. As you > > > > allude to, a remote spoofing a legitimate SSP device may always just > > > > jam and downgrade to not SSP, but if you have any signals that SSP is > > > > supported by the device, it may be a good defensive posture. > > > > > > trying to resolve the name before connected is a waste of time. Resolving the name after connecting will not give you that event. You should just read the remote features. > > > > I have a vague memory that there was an interoperability issue around > > this that required the initiator to know ahead of time if SSP was > > supported by the remote host before connecting which was the reason > > why this was added in the first place. However, I agree that this can > > also be read after you are connected rather than just waiting for a > > RNR page to complete just to page again. The point here however is > > about the signals that SSP should be supported and the conditions > > where we let legacy pairing go through. My assertion is that EIR > > implies SSP, so legacy pairing shouldn't be allowed in that case. > > It's not a definitive security measure, but IMO, every signals that we > > can get will help close a door to downgrade attacks. > > Legacy pairing is still indicated with MGMT_DEV_FOUND_LEGACY_PAIRING > so for what is worth this didn't change any logic regarding how legacy > pairing is detected, in fact hci_conn_ssp_enabled is used to determine > if encryption is required or not for low security it was never used to > detect if the paring method used was really SSP or legacy. The general idea is to both "try" to protect against a downgrade attack but also to encrypt all channels (other than SDP) if SSP is supported by the remote. If the later is already handled, we just need to make sure we use all available signals that the remote side supports SSP. Receiving an EIR is a valid signal, the absence of EIR doesn't imply the remote doesn't support SSP. > > > > > > > > Receiving an EIR response or a Remote Host Supported Feature Event > > > > with the SSP bit set is a good indication that the device supports SSP > > > > and you should expect SSP to take place. Again, it is not a valid > > > > configuration to have EIR enabled but not SSP per my interpretation of > > > > the 2.1 specification. > > > > > > If you have an idea on how to tighten this and fail, please send a patch. It is just that our inquiry cache was never designed for that. It was just to speed up the connection process. > > Ack. This definitely looks like an opportunity. We can add it to the backlog. > > If you guys agree I can prepare a patch requiring SSP to be used, but > first we will need to agree on what action we would take under such > situation, shall we disconnect if we figure out the SSP bit is > disabled? Btw, if the remote device has dropped SSP for some reason (I > suppose the spec allows doing it) and we have a EIR on the cache > (which we keep for 30 seconds) that doesn't necessarily mean the > device is broken since the use of EIR may have been dropped in the > meantime. Right, but if we do have the EIR signal, then we should expect SSP to be used. It is legitimate, in my interpretation, to fail anything less than SSP in that case. > > > > > > > Regards > > > > > > Marcel > > > > > > > -- > Luiz Augusto von Dentz
Hi Alain, >>>>>>> Starting with the 2.1 specification, it is my interpretation that it >>>>>>> is not valid to support EIR but not SSP. I understand that SSP may be >>>>>>> disabled from BlueZ's point of view, but this doesn't seem to be a >>>>>>> legitimate/qualifiable configuration. Should we instead fail the >>>>>>> legacy pairing if EIR was received as an invalid condition? >>>>>> >>>>>> I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. >>>>>> >>>>>> You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. >>>>>> >>>>>> If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. >>>>> >>>>> You are correct, the EIR response is not a guaranteed thing. For this >>>>> reason, the host should try to resolve the name of the device before >>>>> initiating bonding where a Remote Host Supported Feature Notification >>>>> Event is generated to signal the remote side's support of SSP. As you >>>>> allude to, a remote spoofing a legitimate SSP device may always just >>>>> jam and downgrade to not SSP, but if you have any signals that SSP is >>>>> supported by the device, it may be a good defensive posture. >>>> >>>> trying to resolve the name before connected is a waste of time. Resolving the name after connecting will not give you that event. You should just read the remote features. >>> >>> I have a vague memory that there was an interoperability issue around >>> this that required the initiator to know ahead of time if SSP was >>> supported by the remote host before connecting which was the reason >>> why this was added in the first place. However, I agree that this can >>> also be read after you are connected rather than just waiting for a >>> RNR page to complete just to page again. The point here however is >>> about the signals that SSP should be supported and the conditions >>> where we let legacy pairing go through. My assertion is that EIR >>> implies SSP, so legacy pairing shouldn't be allowed in that case. >>> It's not a definitive security measure, but IMO, every signals that we >>> can get will help close a door to downgrade attacks. >> >> Legacy pairing is still indicated with MGMT_DEV_FOUND_LEGACY_PAIRING >> so for what is worth this didn't change any logic regarding how legacy >> pairing is detected, in fact hci_conn_ssp_enabled is used to determine >> if encryption is required or not for low security it was never used to >> detect if the paring method used was really SSP or legacy. > The general idea is to both "try" to protect against a downgrade > attack but also to encrypt all channels (other than SDP) if SSP is > supported by the remote. If the later is already handled, we just > need to make sure we use all available signals that the remote side > supports SSP. Receiving an EIR is a valid signal, the absence of EIR > doesn't imply the remote doesn't support SSP. >> >>>> >>>>> Receiving an EIR response or a Remote Host Supported Feature Event >>>>> with the SSP bit set is a good indication that the device supports SSP >>>>> and you should expect SSP to take place. Again, it is not a valid >>>>> configuration to have EIR enabled but not SSP per my interpretation of >>>>> the 2.1 specification. >>>> >>>> If you have an idea on how to tighten this and fail, please send a patch. It is just that our inquiry cache was never designed for that. It was just to speed up the connection process. >>> Ack. This definitely looks like an opportunity. We can add it to the backlog. >> >> If you guys agree I can prepare a patch requiring SSP to be used, but >> first we will need to agree on what action we would take under such >> situation, shall we disconnect if we figure out the SSP bit is >> disabled? Btw, if the remote device has dropped SSP for some reason (I >> suppose the spec allows doing it) and we have a EIR on the cache >> (which we keep for 30 seconds) that doesn't necessarily mean the >> device is broken since the use of EIR may have been dropped in the >> meantime. > Right, but if we do have the EIR signal, then we should expect SSP to > be used. It is legitimate, in my interpretation, to fail anything > less than SSP in that case. lets try this then. Worst case we have to revert such a patch if it turns out it cause interop issues. Regards Marcel
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index 0c1cae83c8dc..6b2288d97ab7 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -225,8 +225,6 @@ static void hci_acl_create_connection(struct hci_conn *conn) } memcpy(conn->dev_class, ie->data.dev_class, 3); - if (ie->data.ssp_mode > 0) - set_bit(HCI_CONN_SSP_ENABLED, &conn->flags); } cp.pkt_type = cpu_to_le16(conn->pkt_type);