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). 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. > 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. 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). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
