Fedora has issued an advisory on February 26: https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N46C4DTVUWK336OYDA4LGALSC5VVPTCC/ Debian has issued an advisory on February 27: https://lists.debian.org/debian-lts-announce/2024/02/msg00013.html Slackware has issued an advisory on February 28: http://www.slackware.com/security/viewer.php?l=slackware-security&y=2024&m=slackware-security.383534 The fix is in the following commit: https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baffdea9e55255a81270b768439c Mageia 9 is also affected.
CVE: (none) => CVE-2023-52160Whiteboard: (none) => MGA9TOOSource RPM: (none) => wpa_supplicant-2.10-4.mga10.src.rpmStatus comment: (none) => Patch available from upstream
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 => ASSIGNEDAssignee: bugsquad => qa-bugsSource RPM: wpa_supplicant-2.10-4.mga10.src.rpm => wpa_supplicant-2.10-3.mga9.src.rpmWhiteboard: MGA9TOO => (none)Version: Cauldron => 9
CC: (none) => mageia
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.
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
Keywords: (none) => advisory
(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.
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. """
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.
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.
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
(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
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
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.
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-bugsWhiteboard: (none) => MGA9-64-OKKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0053.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED