diff options
Diffstat (limited to 'patches/source/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt')
| -rw-r--r-- | patches/source/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt | 226 |
1 files changed, 226 insertions, 0 deletions
diff --git a/patches/source/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt b/patches/source/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt new file mode 100644 index 00000000..5ccb5098 --- /dev/null +++ b/patches/source/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt @@ -0,0 +1,226 @@ +WPA packet number reuse with replayed messages and key reinstallation + +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 |