Bug 32911 - wpa_supplicant new security issue CVE-2023-52160
Summary: wpa_supplicant new security issue CVE-2023-52160
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA9-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2024-02-29 16:12 CET by Nicolas Salguero
Modified: 2024-03-06 17:54 CET (History)
4 users (show)

See Also:
Source RPM: wpa_supplicant-2.10-3.mga9.src.rpm
CVE: CVE-2023-52160
Status comment:


Attachments

Nicolas Salguero 2024-02-29 16:13:45 CET

CVE: (none) => CVE-2023-52160
Whiteboard: (none) => MGA9TOO
Source RPM: (none) => wpa_supplicant-2.10-4.mga10.src.rpm
Status comment: (none) => Patch available from upstream

Comment 1 Nicolas Salguero 2024-03-01 11:10:26 CET
Suggested advisory:
========================

The updated packages fix a security vulnerability:

The implementation of PEAP in wpa_supplicant through 2.10 allows authentication bypass. For a successful attack, wpa_supplicant must be configured to not verify the network's TLS certificate during Phase 1 authentication, and an eap_peap_decrypt vulnerability can then be abused to skip Phase 2 authentication. The attack vector is sending an EAP-TLV Success packet instead of starting Phase 2. This allows an adversary to impersonate Enterprise Wi-Fi networks. (CVE-2023-52160)

References:
https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N46C4DTVUWK336OYDA4LGALSC5VVPTCC/
https://lists.debian.org/debian-lts-announce/2024/02/msg00013.html
http://www.slackware.com/security/viewer.php?l=slackware-security&y=2024&m=slackware-security.383534
========================

Updated packages in core/updates_testing:
========================
wpa_supplicant-2.10-3.1.mga9
wpa_supplicant-gui-2.10-3.1.mga9

from SRPM:
wpa_supplicant-2.10-3.1.mga9.src.rpm

Status comment: Patch available from upstream => (none)
Status: NEW => ASSIGNED
Assignee: bugsquad => qa-bugs
Source RPM: wpa_supplicant-2.10-4.mga10.src.rpm => wpa_supplicant-2.10-3.mga9.src.rpm
Whiteboard: MGA9TOO => (none)
Version: Cauldron => 9

PC LX 2024-03-01 11:21:47 CET

CC: (none) => mageia

Comment 2 PC LX 2024-03-01 15:48:12 CET
Installed and tested without issues.

Tested with two USB wireless adapter devices:
Bus 001 Device 010: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter
Bus 001 Device 008: ID 0bda:818b Realtek Semiconductor Corp. RTL8192EU 802.11b/g/n WLAN Adapter

Tested wpa_gui by connecting to various WiFI access points.



System: Mageia 9, x86-64, Plasma DE, AMD Ryzen 5 5600G with Radeon Graphics using amgdpu driver.
This system is using systemd-networkd and systemd-resolved to manage the network devices and DNS resolution.



$ uname -a
Linux jupiter 6.6.14-desktop-2.mga9 #1 SMP PREEMPT_DYNAMIC Tue Jan 30 15:48:16 UTC 2024 x86_64 GNU/Linux
$ rpm -qa | grep wpa_supplicant
wpa_supplicant-gui-2.10-3.1.mga9
wpa_supplicant-2.10-3.1.mga9
$ systemctl status wpa_supplicant.service systemd-networkd.service systemd-resolved.service 
● wpa_supplicant.service - WPA Supplicant daemon
     Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled; preset: disabled)
     Active: active (running) since Fri 2024-03-01 14:34:40 WET; 12min ago
   Main PID: 48380 (wpa_supplicant)
      Tasks: 1 (limit: 37614)
     Memory: 1.4M
        CPU: 66ms
     CGroup: /system.slice/wpa_supplicant.service
             └─48380 /usr/sbin/wpa_supplicant -u -P /run/wpa_supplicant.pid -iwlan1 -Dwext -s -c /etc/wpa_supplicant.conf

● systemd-networkd.service - Network Configuration
     Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; preset: disabled)
     Active: active (running) since Fri 2024-03-01 08:12:59 WET; 6h ago
TriggeredBy: ● systemd-networkd.socket
       Docs: man:systemd-networkd.service(8)
             man:org.freedesktop.network1(5)
   Main PID: 1852 (systemd-network)
     Status: "Processing requests..."
      Tasks: 1 (limit: 37614)
     Memory: 3.1M
        CPU: 179ms
     CGroup: /system.slice/systemd-networkd.service
             └─1852 /usr/lib/systemd/systemd-networkd

Warning: some journal files were not opened due to insufficient permissions.

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: disabled)
     Active: active (running) since Fri 2024-03-01 08:13:01 WET; 6h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 2105 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 37614)
     Memory: 4.0M
        CPU: 2.038s
     CGroup: /system.slice/systemd-resolved.service
             └─2105 /usr/lib/systemd/systemd-resolved

Warning: some journal files were not opened due to insufficient permissions.
Comment 3 Herman Viaene 2024-03-01 17:44:32 CET
MGA9-64 Plasma on HP-Pavillion.
No installation issues.
Rebooted this wifi only notebook and wifi connection is OK.
Tried to see  what could be done with wpa-gui, but this comes up blank and no way I can add my wifi connection to it. Not sure this is really important.

CC: (none) => herman.viaene

katnatek 2024-03-01 18:56:18 CET

Keywords: (none) => advisory

Comment 4 PC LX 2024-03-01 19:07:16 CET
(In reply to Herman Viaene from comment #3)
> Tried to see  what could be done with wpa-gui, but this comes up blank and
> no way I can add my wifi connection to it. Not sure this is really important.

I had to run wpa_gui as root for it to work. If I run it as a non-root user it show a "Could not get status from wpa_supplicant" message.
Comment 5 PC LX 2024-03-01 19:16:39 CET
It seems possible to make wpa_cli and wpa_gui work with non-root users.
Maybe this is something desirable.

From the config file /etc/wpa_supplicant.conf
"""
# Access control for the control interface can be configured by setting the
# directory to allow only members of a group to use sockets. This way, it is
# possible to run wpa_supplicant as root (since it needs to change network
# configuration and open raw sockets) and still allow GUI/CLI components to be
# run as non-root users. However, since the control interface can be used to
# change the network configuration, this access needs to be protected in many
# cases. By default, wpa_supplicant is configured to use gid 0 (root). If you
# want to allow non-root users to use the control interface, add a new group
# and change this value to match with that group. Add users that should have
# control interface access to this group. If this variable is commented out or
# not included in the configuration file, group will not be changed from the
# value it got by default when the directory or socket was created.
#
# When configuring both the directory and group, use following format:
# DIR=/var/run/wpa_supplicant GROUP=wheel
# DIR=/var/run/wpa_supplicant GROUP=0
# (group can be either group name or gid)
"""

From the man page for wpa_cli:
"""
The control interface of wpa_supplicant can be configured to allow non-root user access (ctrl_interface GROUP= parameter in the configuration file). This makes it possible to run wpa_cli with a normal user account.
"""
Comment 6 PC LX 2024-03-01 19:29:30 CET
Can confirm that if the permissions are changed to allow the user access to /var/run/wpa_supplicant/* then the wpa_gui will work.

The following commands will give access to all user.
"""
chmod a+rx /var/run/wpa_supplicant
chmod a+rwx /var/run/wpa_supplicant/*
"""

Maybe creating a specific group (e.g. "wpa_supplicant") and informing the user, maybe in a README file, that it needs to be added to that group will be a better solution. Another possibility would be to make a wrapper shell script for wpa_gui and wpa_cli that checks for permissions and explicitly informs the user (e.g. using notify-send) what to do if no permissions are available. I can make these shell scripts if such a solution is choosen.
Comment 7 Herman Viaene 2024-03-02 11:41:38 CET
Using wpa_gui as root works OK.
But I alo did the following:
Added the wheel group to the normal user, uncommented the line DIR=/var/run/wpa_supplicant GROUP=wheel  in /etc/wpa_supplicant.conf and rebooted. Result was that no way in MCC I could get the wifi connection operational. This notebook has an internal wifi Intel Dual Band Wireless-AC 3168NGW [Stone Peak], which never worked satisfactorily (not with Mageia nor with Win 10 which wqs its initial installation) and a USB dongle NETGEAR WNA3100M.
Commenting that line out in /etc/wpa_supplicant.conf and rebooting got my wifi at the NETGEAR immediately operational.
Comment 8 katnatek 2024-03-03 05:08:43 CET
Real Hardware Mageia 9 i586

In the update process I select use rpmnew file as main file
After reboot I can't see wireless networks
I use MCC -> Network and Internet -> Set up network interface to reconfigure the network , select Wireless , Select the interface , Select Unlisted - edit manually , Select my wireless network , continue with the configuration, I recover the internet but the network applet not change the icon by the one that reflect the connection is active
Comment 9 katnatek 2024-03-03 05:14:57 CET
(In reply to katnatek from comment #8)
> I recover the internet but the network applet not change the
> icon by the one that reflect the connection is active

The expected icon comeback after close session and start session again
Comment 10 Thomas Andrews 2024-03-04 00:26:16 CET
Losing previous wifi information is to be expected if rpmnew is selected for this update, as the wpa_supplicant.conf file would be re-written, the reason the user is given the choice. 

The failure of the network icon to change under certain conditions is an old issue - see bug 27795.

@Herman: It reads like the issue with your internal wifi hardware is not a new regression, and needn't hold back the update. Is that correct?

CC: (none) => andrewsfarm

Comment 11 Thomas Andrews 2024-03-05 00:25:25 CET
MGA9-64 Plasma on an HP Probook 6550b, i3 350M, Intel graphics, BCM43224 wifi.

No installation issues. I chose to accept rpmnew as the main file.

I'm using Network Manager on this machine, as I find it much easier to set up and control an Openvpn VPN. urpmq --whatrequires wpa_supplicant indicates that networkmanager-wifi requires it, so testing as is with this system is valid.

After a reboot, wifi was still connected automatically to my network's 2.4 GHz band, and the 5GHz band was available. However, the "System" connection, originally set up by Mageia's Network Center before I switched to Network Manager, was gone. The VPN connection was still there, and I was able to start and stop it at will.

I ran Firefox for a while, watched a 20-minute Youtube video, and the connection remained solid.
Comment 12 Thomas Andrews 2024-03-06 13:42:28 CET
One last test: MGA9-64 Plasma, HP Pavilion 15, A8 4555 APU, RTL8188EE wifi. This install is using our Network Center.

No installation issues. The "rpmnew" notice advises users that are unsure about what to do should choose to remove rpmnew, so that's what I did this time.

No issues to report after the reboot. My connection to my network came up normally, and has been stable even though I'm in a part of the house where the signal is attenuated by structure and a large metal appliance. 

It looks good here, so I'm giving this an OK, and validating.

CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA9-64-OK
Keywords: (none) => validated_update

Comment 13 Mageia Robot 2024-03-06 17:54:35 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2024-0053.html

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.