In the Linux kernel, the following vulnerability has been resolved:

rtl818x: Prevent using not initialized queues

Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:

https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html

He also confirmed that this patch fixes the issue. In summary this happened:

After updating wpasupplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211ACVO for the priority, which wpasupplicants starts to use in 2.10.

Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211ACBE (2) by mac80211 for rtl8180/rtl8185 cards.

rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skbqueuelen(&ring->queue)) % ring->entries

"ring->entries" is zero for rtl8180/rtl8185 cards, txring[2] never got initialized.

In wpasupplicant, a flaw was discovered in the implementation of PEAP, which allows an attacker to skip the second phase of authentication when the target device has not been properly configured to verify the authentication server. Note that PEAP is the most common authentication method for Enterprise networks. By skipping Phase-2 authentication, it’s much easier for an attacker to create a rogue clone of a trusted WiFi network and trick the victim into connecting, all without knowing their password.

Typical Attack Prerequisites: - The attacker needs to know the SSID of the target Enterprise WPA2/3 network - The attacker must be within range of their victim, who can be located anywhere, i.e. they don’t need to be in range of the network being impersonated during the attack - wpasupplicant must be configured to not verify the authentication server’s TLS certificate

It is trivial to harvest SSIDs from around office buildings or to advertise popular Enterprise network names such as eduroam, Vodafone Homespot, TelenetWiFree or Unitymedia WifiSpot for example, and simply wait for an unsuspecting victim to connect. The misconfiguration of wpasupplicant is unfortunately a known issue on many systems. Proper configuration is a manual process, whose confusing and tedious nature prompts many users to skip it.

References: https://www.top10vpn.com/research/wifi-vulnerabilities/ https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baff

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 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.<br>Security Fix(es):<br><li> A new exploitation technique called key reinstallation attacks (KRACK) affecting WPA2 has been discovered. A remote attacker within Wi-Fi range could exploit these attacks to decrypt Wi-Fi traffic or possibly inject forged Wi-Fi packets by manipulating cryptographic handshakes used by the WPA2 protocol. (CVE-2017-13077, CVE-2017-13078, CVE-2017-13080, CVE-2017-13087)</li> Red Hat would like to thank CERT for reporting these issues. Upstream acknowledges Mathy Vanhoef (University of Leuven) as the original reporter of these issues.

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

Enable the port when disabling countermeasures, and disable it on enabling countermeasures. This bug causes the response of the system to certain attacks to be ineffective. It also prevents wpasupplicant from getting scan results, as wpasupplicant disables countermeasures on startup - preventing the hardware from scanning. wpasupplicant works with apmode=2 despite this bug because the commit handler re-enables the port. The log tends to look like: State: DISCONNECTED -> SCANNING Starting AP scan for wildcard SSID Scan requested (ret=0) - scan timeout 5 seconds EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized Scan timeout - try to get results Failed to get scan results Failed to get scan results - try scanning again Setting scan request: 1 sec 0 usec Starting AP scan for wildcard SSID Scan requested (ret=-1) - scan timeout 5 seconds Failed to initiate AP scan.

Upstream commit: http://git.kernel.org/linus/0a54917c3fc295cb61f3fb52373c173fd3b69f48