wpa_supplicant: fix CVE-2018-14526
Unauthenticated EAPOL-Key decryption in wpa_supplicant
Published: August 8, 2018
Identifiers:
- CVE-2018-14526
Latest version available from: https://w1.fi/security/2018-1/
Vulnerability
A vulnerability was found in how wpa_supplicant processes EAPOL-Key
frames. It is possible for an attacker to modify the frame in a way that
makes wpa_supplicant decrypt the Key Data field without requiring a
valid MIC value in the frame, i.e., without the frame being
authenticated. This has a potential issue in the case where WPA2/RSN
style of EAPOL-Key construction is used with TKIP negotiated as the
pairwise cipher. It should be noted that WPA2 is not supposed to be used
with TKIP as the pairwise cipher. Instead, CCMP is expected to be used
and with that pairwise cipher, this vulnerability is not applicable in
practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data
field is encrypted using RC4. This vulnerability allows unauthenticated
EAPOL-Key frames to be processed and due to the RC4 design, this makes
it possible for an attacker to modify the plaintext version of the Key
Data field with bitwise XOR operations without knowing the contents.
This can be used to cause a denial of service attack by modifying
GTK/IGTK on the station (without the attacker learning any of the keys)
which would prevent the station from accepting received group-addressed
frames. Furthermore, this might be abused by making wpa_supplicant act
as a decryption oracle to try to recover some of the Key Data payload
(GTK/IGTK) to get knowledge of the group encryption keys.
Full recovery of the group encryption keys requires multiple attempts
(128 connection attempts per octet) and each attempt results in
disconnection due to a failure to complete the 4-way handshake. These
failures can result in the AP/network getting disabled temporarily or
even permanently (requiring user action to re-enable) which may make it
impractical to perform the attack to recover the keys before the AP has
already changes the group keys. By default, wpa_supplicant is enforcing
at minimum a ten second wait time between each failed connection
attempt, i.e., over 20 minutes waiting to recover each octet while
hostapd AP implementation uses 10 minute default for GTK rekeying when
using TKIP. With such timing behavior, practical attack would need large
number of impacted stations to be trying to connect to the same AP to be
able to recover sufficient information from the GTK to be able to
determine the key before it gets changed.
Vulnerable versions/configurations
All wpa_supplicant versions.
Acknowledgments
Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU
Leuven for discovering and reporting this issue.
Possible mitigation steps
- Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This
can be done also on the AP side.
- Merge the following commits to wpa_supplicant and rebuild:
WPA: Ignore unauthenticated encrypted EAPOL-Key data
This patch is available from https://w1.fi/security/2018-1/
- Update to wpa_supplicant v2.7 or newer, once available
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit 1961948585e008ad0095d7074784893229b00d06)
2018-08-10 13:48:21 +00:00
|
|
|
From 3e34cfdff6b192fe337c6fb3f487f73e96582961 Mon Sep 17 00:00:00 2001
|
|
|
|
|
From: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
|
|
|
|
|
Date: Sun, 15 Jul 2018 01:25:53 +0200
|
|
|
|
|
Subject: [PATCH] WPA: Ignore unauthenticated encrypted EAPOL-Key data
|
|
|
|
|
|
|
|
|
|
Ignore unauthenticated encrypted EAPOL-Key data in supplicant
|
|
|
|
|
processing. When using WPA2, these are frames that have the Encrypted
|
|
|
|
|
flag set, but not the MIC flag.
|
|
|
|
|
|
|
|
|
|
When using WPA2, EAPOL-Key frames that had the Encrypted flag set but
|
|
|
|
|
not the MIC flag, had their data field decrypted without first verifying
|
|
|
|
|
the MIC. In case the data field was encrypted using RC4 (i.e., when
|
|
|
|
|
negotiating TKIP as the pairwise cipher), this meant that
|
|
|
|
|
unauthenticated but decrypted data would then be processed. An adversary
|
|
|
|
|
could abuse this as a decryption oracle to recover sensitive information
|
|
|
|
|
in the data field of EAPOL-Key messages (e.g., the group key).
|
|
|
|
|
(CVE-2018-14526)
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
|
|
|
|
|
---
|
|
|
|
|
src/rsn_supp/wpa.c | 11 +++++++++++
|
|
|
|
|
1 file changed, 11 insertions(+)
|
|
|
|
|
|
|
|
|
|
--- a/src/rsn_supp/wpa.c
|
|
|
|
|
+++ b/src/rsn_supp/wpa.c
|
2018-04-28 19:12:19 +00:00
|
|
|
@@ -2208,6 +2208,17 @@ int wpa_sm_rx_eapol(struct wpa_sm *sm, c
|
wpa_supplicant: fix CVE-2018-14526
Unauthenticated EAPOL-Key decryption in wpa_supplicant
Published: August 8, 2018
Identifiers:
- CVE-2018-14526
Latest version available from: https://w1.fi/security/2018-1/
Vulnerability
A vulnerability was found in how wpa_supplicant processes EAPOL-Key
frames. It is possible for an attacker to modify the frame in a way that
makes wpa_supplicant decrypt the Key Data field without requiring a
valid MIC value in the frame, i.e., without the frame being
authenticated. This has a potential issue in the case where WPA2/RSN
style of EAPOL-Key construction is used with TKIP negotiated as the
pairwise cipher. It should be noted that WPA2 is not supposed to be used
with TKIP as the pairwise cipher. Instead, CCMP is expected to be used
and with that pairwise cipher, this vulnerability is not applicable in
practice.
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data
field is encrypted using RC4. This vulnerability allows unauthenticated
EAPOL-Key frames to be processed and due to the RC4 design, this makes
it possible for an attacker to modify the plaintext version of the Key
Data field with bitwise XOR operations without knowing the contents.
This can be used to cause a denial of service attack by modifying
GTK/IGTK on the station (without the attacker learning any of the keys)
which would prevent the station from accepting received group-addressed
frames. Furthermore, this might be abused by making wpa_supplicant act
as a decryption oracle to try to recover some of the Key Data payload
(GTK/IGTK) to get knowledge of the group encryption keys.
Full recovery of the group encryption keys requires multiple attempts
(128 connection attempts per octet) and each attempt results in
disconnection due to a failure to complete the 4-way handshake. These
failures can result in the AP/network getting disabled temporarily or
even permanently (requiring user action to re-enable) which may make it
impractical to perform the attack to recover the keys before the AP has
already changes the group keys. By default, wpa_supplicant is enforcing
at minimum a ten second wait time between each failed connection
attempt, i.e., over 20 minutes waiting to recover each octet while
hostapd AP implementation uses 10 minute default for GTK rekeying when
using TKIP. With such timing behavior, practical attack would need large
number of impacted stations to be trying to connect to the same AP to be
able to recover sufficient information from the GTK to be able to
determine the key before it gets changed.
Vulnerable versions/configurations
All wpa_supplicant versions.
Acknowledgments
Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU
Leuven for discovering and reporting this issue.
Possible mitigation steps
- Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This
can be done also on the AP side.
- Merge the following commits to wpa_supplicant and rebuild:
WPA: Ignore unauthenticated encrypted EAPOL-Key data
This patch is available from https://w1.fi/security/2018-1/
- Update to wpa_supplicant v2.7 or newer, once available
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit 1961948585e008ad0095d7074784893229b00d06)
2018-08-10 13:48:21 +00:00
|
|
|
|
|
|
|
|
if ((sm->proto == WPA_PROTO_RSN || sm->proto == WPA_PROTO_OSEN) &&
|
|
|
|
|
(key_info & WPA_KEY_INFO_ENCR_KEY_DATA) && mic_len) {
|
|
|
|
|
+ /*
|
|
|
|
|
+ * Only decrypt the Key Data field if the frame's authenticity
|
|
|
|
|
+ * was verified. When using AES-SIV (FILS), the MIC flag is not
|
|
|
|
|
+ * set, so this check should only be performed if mic_len != 0
|
|
|
|
|
+ * which is the case in this code branch.
|
|
|
|
|
+ */
|
|
|
|
|
+ if (!(key_info & WPA_KEY_INFO_MIC)) {
|
|
|
|
|
+ wpa_msg(sm->ctx->msg_ctx, MSG_WARNING,
|
|
|
|
|
+ "WPA: Ignore EAPOL-Key with encrypted but unauthenticated data");
|
|
|
|
|
+ goto out;
|
|
|
|
|
+ }
|
|
|
|
|
if (wpa_supplicant_decrypt_key_data(sm, key, mic_len,
|
|
|
|
|
ver, key_data,
|
|
|
|
|
&key_data_len))
|
