Hi Jouni, Thank you for your quick response and for the clarifying comments. I have one followup question, though, please see my comments and question inline below: Jouni Malinen schrieb am 20.10.2017 12:34: > On Fri, Oct 20, 2017 at 12:03:50PM +0200, Timo Sigurdsson wrote: >> commit 6f234c1e (Optional AP side workaround for key reinstallation attacks) >> introduced the new option wpa_disable_eapol_key_retries to help mitigate the >> key installation attacks from the access point side in case some clients >> cannot be patched. >> >> This option has also been quickly adopted by some distributions such as LEDE. >> In their release announcement for the 17.01.4 release, the LEDE team notes[1]: >> As some client devices might never receive an update, an optional AP-side >> workaround was introduced in hostapd to complicate these attacks, slowing >> them down. Please note that this does not fully protect you from them, >> especially when running older versions of wpa_supplicant vulnerable to >> CVE-2017-13086, which the workaround does not address. >> >> Now, I understand that an attack against the PeerKey handshake >> (CVE-2017-13086) >> cannot be addressed with this new hostapt workaround. Yet, as the researchers >> who found those vulnerabilities also noted in their paper, the impact of this >> specific attack is rather low since not many devices seem to support this >> particular feature in the first place[2]. > > Please note that CVE-2017-13086 is related to TDLS, not PeerKey (which > is covered in CVE-2017-13084 and not known to be deployed in any > device). Sorry for the mixup and thanks for the clarification. > As far as TDLS is concerned, I'm not sure anyone has yet shown that it > can be attacked in practice with the currently deployed devices, but it > is at least theoretically possible that such attacks could be performed. > If one wants to complicate that possibility at the AP side, the > tdls_prohibit=1 configuration parameter makes hostapd advertise to the > stations that use of TDLS is not allowed in the BSS. That said, this > advertisement is not fully protected, so if an attacker can attract both > STAs using TDLS into a fake AP and the STAs do not see Beacon/Probe > Response frames from the real AP, it would be possible to bypass this > protection. Thanks for the hint. > >> This leaves me wondering, what other limitations the hostapd workaround >> wpa_disable_eapol_key_retries might have with regards to mitigating the key >> reinstallation attacks. Are there any other known limitations aside from the >> PeerKey attack and the fact that the workaround might cause interoperability >> issues with clients? Can anybody elaborate what "slowing them down" (LEDE >> release notes) as opposed to "work around key reinstallation attacks" >> (original >> commit message[3]) might mean? > > I'm not familiar with the reason behind that "slowing them down" > language, so I cannot comment on that part. As far as the hostapd > wpa_disable_eapol_key_retries=1 configuration option is concerned, it > should prevent an attacker from being able to obtain more than a single > valid EAPOL-Key frame (msg 3/4 or group msg 1/2) and with that, prevent > the particular attacks that used delayed EAPOL-Key frame delivery to the > station. That said, it should be noted that so far there has not been > sufficient review to be able to fully claim that this prevents all these > attacks and that there is no way for an attacker to make hostapd > retransmit a suitable frame in this configuration with the current > implementation. Fair enough! > Changes in EAPOL-Key functionality do not have impact on WNM Sleep Mode > behavior, so if there are station devices that use this capability (I'm > not sure whether any such device has been deployed), this AP-only > workaround with wpa_disable_eapol_key_retries=1 would not prevent > potential attacks there. Another hostapd-only change could be done to > those, though, to prevent use of WNM Sleep Mode or to not allow the > GTK/IGTK to be included in the WNM Sleep Mode Response. I'm open to > adding such a change if someone can confirm that there are actually > deployed station devices that use WNM Sleep Mode behavior and are > vulnerable to CVE-2017-13087 (and/or -13088). Would the existing option wnm_sleep_mode that is mentioned in the example hostapd configuration[1] cover this scenario (if set to 0) or is that unrelated? Regards, Timo [1] https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
