summaryrefslogtreecommitdiffstats
path: root/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
diff options
context:
space:
mode:
Diffstat (limited to 'source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt')
-rw-r--r--source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt226
1 files changed, 0 insertions, 226 deletions
diff --git a/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt b/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
deleted file mode 100644
index 5ccb5098c..000000000
--- a/source/n/wpa_supplicant/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt
+++ /dev/null
@@ -1,226 +0,0 @@
-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