From ${URL} : Published: October 16, 2017 Identifiers: - CERT case ID: VU#228519 - CVE-2017-13077 - CVE-2017-13078 - CVE-2017-13079 - CVE-2017-13080 - CVE-2017-13081 - CVE-2017-13082 - CVE-2017-13084 (not applicable) - CVE-2017-13086 - CVE-2017-13087 - CVE-2017-13088 Latest version available from: https://w1.fi/security/2017-1/ Vulnerability A vulnerability was found in how a number of implementations can be triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by replaying a specific frame that is used to manage the keys. Such reinstallation of the encryption key can result in two different types of vulnerabilities: disabling replay protection and significantly reducing the security of encryption to the point of allowing frames to be decrypted or some parts of the keys to be determined by an attacker depending on which cipher is used. This document focuses on the cases that apply to systems using hostapd (AP) or wpa_supplicant (station), but it should be noted that the generic vulnerability itself is applicable to other implementations and may have different impact in other cases. This vulnerability can in theory apply to any case where a TK (the pairwise/unicast encryption key used with TKIP, CCMP, GCMP), a GTK (group/multicast encryption key), or an IGTK (group management frame integrity protection key) is configured by the Authentication/Supplicant component to the WLAN driver/firmware taking care of the TX/RX path and encryption/decryption of frames. If the same key is configured multiple times, it is likely that the transmit and receive packet numbers (PN, IPN, RSC/TSC, etc.) are cleared to a smaller value (zero in case of pairwise keys, zero or at least a smaller value than the last used value in case of group keys). When this happens with the same key, this breaks replay protection on RX side and can result in reuse of packet numbers on TX side. The former may allow replaying of previously delivered packets (without the attacker being able to decrypt them or modify their contents) while the latter may result in more severe issues on the TX side due to resulting CCM nonce replay and related issues with GCMP and TKIP. The TX side issue may make it significantly easier for the attacker to decrypt frames and determine some parts of the keys (e.g., a Michael MIC key in case of TKIP). Impact on AP/hostapd On the AP side, this generic issue has been determined to be applicable in the case where hostapd is used to operate an RSN/WPA2 network with FT (Fast BSS Transition from IEEE 802.11r) enabled. Replaying of the Reassociation Request frame can be used to get the AP reinstalling the TK which results in the AP accepting previously delivered unicast frames from the station and the AP reusing previously used packet numbers (local TX packet number gets reset to zero). This latter issue on the TX side can result in CCM nonce reuse which invalidates CCMP security properties. In case of TKIP this can result in the attacker being able to determine part of the TK more easily and with GCMP, result in similar issues. It should be noted that the AP side issue with FT would be close to applying to FILS authentication (from IEEE 802.11ai) in hostapd with replaying of (Re)Association Request frames. However, due to a different handling of the repeated association processing with FILS, this would actually result in the station getting immediately disconnected which prevents this attack in practice. In addition, the FILS implementation in the current hostapd version is still experimental and documented as being discouraged in production use cases. Another area of potentially reduced security was identified when looking into these issues. When AP/Authenticator implementation in hostapd is requested to rekey the PTK without performing EAP reauthentication (either through local periodic rekeying or due to a request from an association station), the ANonce value does not get updated. This results in the new 4-way handshake depending on the station/supplicant side generating a new, unique (for the current PMK/PSK) SNonce for the PTK derivation to result in a new key. While a properly working supplicant would do so, if there is a supplicant implementation that does not, this combination could result in deriving the same PTK again. When the TK from that PTK gets configured in the driver, this would result in reinstalling the same key and the same issues as described above for the FT protocol case. Impact on station/wpa_supplicant On the station side, this generic issue has been determined to be applicable in the cases where wpa_supplicant processes a group key (GTK or IGTK) update from the AP. An attacker that is able to limit access to frame delivery may be able to extract two update messages and deliver those to the station with significant time delay between them. When wpa_supplicant processes the second message, it may end up reinstalling the same key to the driver and when doing this, clear the RX packet number to an old value. This would allow the attacker to replay all group-addressed frames that the AP sent between the time the key update message was originally sent and the time when the attacker forwarded the second frame to the station. The attacker would not be able to decrypt or modify the frames based on this vulnerability, though. There is an exception to this with older wpa_supplicant versions as noted below in version specific notes. For the current wpa_supplicant version (v2.6), there is also an additional EAPOL-Key replay sequence where an additional forged EAPOL-Key message can be used to bypass the existing protection for the pairwise key reconfiguration in a manner that ends up configuring a known TK that an attacker could use to decrypt any frame sent by the station and to inject arbitrary unicast frames. Similar issues are reachable in older versions as noted below. PeerKey / TDLS PeerKey As far as the related CVE-2017-13084 (reinstallation of the STK key in the PeerKey handshake) is concerned, it should be noted that PeerKey implementation in wpa_supplicant is not fully functional and the actual installation of the key into the driver does not work. As such, this item is not applicable in practice. Furthermore, the PeerKey handshake for IEEE 802.11e DLS is obsolete and not known to have been deployed. As far as the TDLS PeerKey handshake is concerned (CVE-2017-13086), wpa_supplicant implementation is already rejecting TPK M2 retries, so the reconfiguration issue cannot apply for it. For TPK M3, there is a theoretical impact. However, if that frame is replayed, the current wpa_supplicant implementation ends up tearing down the TDLS link immediately and as such, there is no real window for performing the attack. Furthermore, TPK M3 goes through the AP path and if RSN is used there, that frame has replay protection, so the attacker could not perform the attack. If the AP path were to use WEP, the frame could be replayed, though. That said, if WEP is used on the AP path, it would be fair to assume that there is no security in the network, so a new attack vector would be of small additional value. With older wpa_supplicant versions, it may be possible for an attacker to cause TPK M2 to be retransmitted with delay that would be able to trigger reinstallation of TK on the peer receiving TPK M2 (CVE-2017-13086). This may open a short window for the attack with v2.3, v2.4, and v2.5; and a longer window with older versions. Vulnerable versions/configurations For the AP/Authenticator TK (unicast) reinstallation in FT protocol (CVE-2017-13082): hostapd v0.7.2 and newer with FT enabled (i.e., practically all versions that include full FT implementation). FT needs to be enabled in the runtime configuration to make this applicable. For the AP/Authenticator missing ANonce during PTK rekeying: All hostapd versions. For the station/Supplicant side GTK/IGTK reinstallation and TK configuration: All wpa_supplicant versions. The impact on older versions can be more severe due to earlier changes in this area: v2.3 and older can also reinstall the pairwise key and as such have similar impact as the AP FT case (CVE-2017-13077); v2.4 and v2.5 end up configuring an all-zero TK which breaks the normal data path, but could allow an attacker to decrypt all following frames from the station and to inject arbitrary frames to the station. In addition, a different message sequence involving 4-way handshake can result in configuration of an all-zero TK in v2.6 and the current snapshot of the development repository as of the publication of this advisory. Acknowledgments Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU Leuven for discovering and reporting this issue. Thanks to John A. Van Boxtel for finding additional issues related to this topic. Possible mitigation steps - For AP/hostapd and FT replay issue (CVE-2017-13082), it is possible to prevent the issue temporarily by disabling FT in runtime configuration, if needed before being able to update the implementations. - Merge the following commits to hostapd/wpa_supplicant and rebuild them: hostapd and replayed FT reassociation request frame (CVE-2017-13082): hostapd: Avoid key reinstallation in FT handshake hostapd PTK rekeying and ANonce update: Fix PTK rekeying to generate a new ANonce wpa_supplicant and GTK/IGTK rekeying (CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13087, CVE-2017-13088): Prevent reinstallation of an already in-use group key Extend protection of GTK/IGTK reinstallation of WNM-Sleep Mode cases wpa_supplicant (v2.6 or newer snapshot) and known TK issue: Prevent installation of an all-zero TK Additional protection steps for wpa_supplicant: TDLS: Reject TPK-TK reconfiguration WNM: Ignore WNM-Sleep Mode Response without pending request FT: Do not allow multiple Reassociation Response frames These patches are available from https://w1.fi/security/2017-1/ (both against the snapshot of hostap.git master branch and rebased on top of the v2.6 release) For the TDLS TPK M2 retransmission issue (CVE-2017-13086) with older wpa_supplicant versions, consider updating to the latest version or merge in a commit that is present in v2.6: https://w1.fi/cgit/hostap/commit/?id=dabdef9e048b17b22b1c025ad592922eab30dda8 ('TDLS: Ignore incoming TDLS Setup Response retries') - Update to hostapd/wpa_supplicant v2.7 or newer, once available * it should be noted that there are number of additional changes in the related areas of the implementation to provide extra layer of protection for potential unknown issues; these changes are not included in this advisory as they have not been identified to be critical for preventing any of the identified security vulnerabilities; however, users of hostapd/wpa_supplicant are encouraged to consider merging such changes even if not fully moving to v2.7 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
*** This bug has been marked as a duplicate of bug 634440 ***
