Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Aug 2018 17:33:00 +0200
From: Jens Timmerman <>
Subject: Re: Unauthenticated EAPOL-Key decryption in wpa_supplicant

I have to ask since this was only published 4 days ago and also describes
an attack on the EAPOL frames
Is this in any way related to atom's new attack on WPA/WPA2 using PMKID,

As far as I can see these are 2 different attacks?

Jens Timmerman

On 8 August 2018 at 16:22, Jouni Malinen <> wrote:

> Published: August 8, 2018
> Identifiers:
> - CVE-2018-14526
> Latest version available from:
> 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
> - Update to wpa_supplicant v2.7 or newer, once available
> --
> Jouni Malinen                                            PGP id EFC895FA

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ