An issue was discovered in Ubuntu wpasupplicant that resulted in loading of arbitrary shared objects, which allows a local unprivileged attacker to escalate privileges to the user that wpasupplicant runs as (usually root).

Membership in the netdev group or access to the dbus interface of wpasupplicant allow an unprivileged user to specify an arbitrary path to a module to be loaded by the wpasupplicant process; other escalation paths might exist.

The implementations of SAE in hostapd and wpasupplicant are vulnerable to side channel attacks as a result of observable timing differences and cache access patterns. An attacker may be able to gain leaked information from a side channel attack that can be used for full password recovery. Both hostapd with SAE support and wpasupplicant with SAE support prior to and including version 2.7 are affected.

An invalid authentication sequence could result in the hostapd process terminating due to missing state validation steps when processing the SAE confirm message when in hostapd/AP mode. All version of hostapd with SAE support are vulnerable. An attacker may force the hostapd process to terminate, performing a denial of service attack. Both hostapd with SAE support and wpasupplicant with SAE support prior to and including version 2.7 are affected.

The wpasupplicant packages contain an 802.1X Supplicant with support for WEP, WPA, WPA2 (IEEE 802.11i / RSN), and various EAP authentication methods. They implement key negotiation with a WPA Authenticator for client stations and controls the roaming and IEEE 802.11 authentication and association of the WLAN driver.Security Fix(es): wpasupplicant: Unauthenticated EAPOL-Key decryption in wpasupplicant (CVE-2018-14526) For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.Additional Changes:For detailed information on changes in this release, see the Red Hat Enterprise Linux 7.6 Release Notes linked from the References section.

An issue was discovered in rsnsupp/wpa.c in wpasupplicant 2.0 through 2.6. Under certain conditions, the integrity of EAPOL-Key messages is not checked, leading to a decryption oracle. An attacker within range of the Access Point and client can abuse the vulnerability to recover sensitive information.

References:

https://papers.mathyvanhoef.com/woot2018.pdf https://w1.fi/security/2018-1/unauthenticated-eapol-key-decryption.txt

The eappwdprocess function in eappeer/eappwd.c in wpasupplicant 2.x before 2.6 does not validate that the reassembly buffer is large enough for the final fragment when EAP-pwd is enabled in a network configuration profile, which allows remote attackers to cause a denial of service (process termination) via a large final fragment in an EAP-pwd message.

Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Station-To-Station-Link (STSL) Transient Key (STK) during the PeerKey handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames.

Wi-Fi Protected Access (WPA and WPA2) that supports IEEE 802.11w allows reinstallation of the Integrity Group Temporal Key (IGTK) during the group key handshake, allowing an attacker within radio range to spoof frames from access points to clients.

Wi-Fi Protected Access (WPA and WPA2) that supports IEEE 802.11w allows reinstallation of the Integrity Group Temporal Key (IGTK) during the four-way handshake, allowing an attacker within radio range to spoof frames from access points to clients.

Wi-Fi Protected Access (WPA and WPA2) that support 802.11v allows reinstallation of the Integrity Group Temporal Key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame, allowing an attacker within radio range to replay frames from access points to clients.

Wi-Fi Protected Access (WPA and WPA2) that support 802.11v allows reinstallation of the Group Temporal Key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame, allowing an attacker within radio range to replay frames from access points to clients.

Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Tunneled Direct-Link Setup (TDLS) Peer Key (TPK) during the TDLS handshake, allowing an attacker within radio range to replay, decrypt, or spoof frames.

A new exploitation technique called key reinstallation attacks used to break Wi-Fi handshakes that negotiate session keys was discovered. These attacks target the Wi-Fi/WPA2 standard. An adversary can trick a vulnerable Access Point (AP) into reinstalling the pairwise key by retransmitted or replayed FT Reassociation Request. While reinstalling the already in-use key, the associated packet number (sometimes also called nonce) and receive replay counter is reset. This causes nonce reuse, voiding any security the underlying encryption protocol is supposed to provide. For example, it allows decryption or injection of frames, and enables an attacker to replay frames.

A new exploitation technique called key reinstallation attacks used to break Wi-Fi handshakes that negotiate session keys was discovered. These attacks target the Wi-Fi/WPA2 standard. An adversary can trick a client or Access Point (AP) into reinstalling an already-in use group key in 4-way handshake. While reinstalling the already in-use key, the associated packet number (sometimes also called nonce) and receive replay counter is reset. This causes nonce reuse, voiding any security the underlying encryption protocol is supposed to provide. For example, it allows decryption or injection of frames, and enables an attacker to replay frames.

A new exploitation technique called key reinstallation attacks used to break Wi-Fi handshakes that negotiate session keys was discovered. These attacks target the Wi-Fi/WPA2 standard. An adversary can trick a client or Access Point (AP) into reinstalling an already-in use group key in the group key handshake. While reinstalling the already in-use key, the associated packet number (sometimes also called nonce) and receive replay counter is reset. This causes nonce reuse, voiding any security the underlying encryption protocol is supposed to provide. For example, it allows decryption or injection of frames, and enables an attacker to replay frames.

hostapd 0.6.7 through 2.5 and wpasupplicant 0.6.7 through 2.5 do not reject \n and \r characters in passphrase parameters, which allows remote attackers to cause a denial of service (daemon outage) via a crafted WPS operation.

The eappwdperformconfirmexchange function in eappeer/eappwd.c in wpasupplicant 2.x before 2.6, when EAP-pwd is enabled in a network configuration profile, allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via an EAP-pwd Confirm message followed by the Identity exchange.

The eappwdprocess function in eapserver/eapserverpwd.c in hostapd 2.x before 2.6 does not validate that the reassembly buffer is large enough for the final fragment when used with (1) an internal EAP server or (2) a RADIUS server and EAP-pwd is enabled in a runtime configuration, which allows remote attackers to cause a denial of service (process termination) via a large final fragment in an EAP-pwd message.

Multiple integer overflows in the NDEF record parser in hostapd before 2.5 and wpasupplicant before 2.5 allow remote attackers to cause a denial of service (process crash or infinite loop) via a large payload length field value in an (1) WPS or (2) P2P NFC NDEF record, which triggers an out-of-bounds read.

The EAP-pwd peer implementation in hostapd and wpasupplicant 1.0 through 2.4 does not clear the L (Length) and M (More) flags before determining if a response should be fragmented, which allows remote attackers to cause a denial of service (crash) via a crafted message.

The EAP-pwd server and peer implementation in hostapd and wpasupplicant 1.0 through 2.4 does not validate that a message is long enough to contain the Total-Length field, which allows remote attackers to cause a denial of service (crash) via a crafted message.

The EAP-pwd server and peer implementation in hostapd and wpasupplicant 1.0 through 2.4 does not validate a fragment is already being processed, which allows remote attackers to cause a denial of service (memory leak) via a crafted message.

Integer underflow in the WMM Action frame parser in hostapd 0.5.5 through 2.4 and wpasupplicant 0.7.0 through 2.4, when used for AP mode MLME/SME functionality, allows remote attackers to cause a denial of service (crash) via a crafted frame, which triggers an out-of-bounds read.

The WPS UPnP function in hostapd, when using WPS AP, and wpasupplicant, when using WPS external registrar (ER), 0.7.0 through 2.4 allows remote attackers to cause a denial of service (crash) via a negative chunk length, which triggers an out-of-bounds read or heap-based buffer overflow.

The EAP-pwd server and peer implementation in hostapd and wpasupplicant 1.0 through 2.4 allows remote attackers to cause a denial of service (out-of-bounds read and crash) via a crafted (1) Commit or (2) Confirm message payload.

It was reported [1] that wpasupplicant does not properly check certificate subject name, which might lead to "man in the middle" attack. Relevant part of the original report: ...

wpasupplicant, linked against openssl performs this check:

if (depth == 0 && match && osstrstr(buf, match) == NULL) { wpaprintf(MSGWARNING, "TLS: Subject '%s' did not " "match with '%s'", buf, match); preverifyok = 0; openssltlsfailevent(conn, errcert, err, depth, buf, "Subject mismatch", TLSFAILSUBJECTMISMATCH); }

strstr() is vulnerable to extension attack, for instance, one would like to match on /CN=wireless.nikhef.nl, but explicitly not match on wireless.nikhef.nl.honestachmed.tr. There is no way to implement a secure EAP-TTLS/PEAP configuration using public certificates this way.

When linked against GnuTLS, the problem is even worse:

if (i == 0) { / TODO: validate subjectmatch and altsubjectmatch / }

Now, it is current best practice to run EAP-TTLS/PEAP with public certificates, because on Windows, this automatically pins the CN and CA from the certificate. ...

[1]: https://bugzilla.redhat.com/showbug.cgi?id=1178263

Jouni Malinen discovered that a string supplied from a remote device could be supplied to a system() call in wpacli or hostapdcli when running an action script (with the "-a" option), resulting in arbitrary command execution. This issue could also be triggered by an attacker within radio range.

Patches are available from the following:

http://w1.fi/security/2014-1/

Based on the information about affected configurations in the upstream advisory, Red Hat Enterprise Linux 5 is likely to be not vulnerable, but Red Hat Enterprise Linux 6 and 7 are likely to be vulnerable.

Acknowledgements:

Red Hat would like to thank Jouni Malinen for reporting this issue.

References:

http://w1.fi/security/2014-1/ http://www.openwall.com/lists/oss-security/2014/10/09/28