The local configuration update through the control interface SET_NETWORK command could allow privilege escalation for the local user to run code from a locally stored library file under the same privileges as the wpa_supplicant process has. The assumption here is that a not fully trusted user/application might have access through a connection manager to set network profile parameters like psk, but would not have access to set other configuration file parameters. If the connection manager in such a case does not filter out control characters from the psk value, it could have been possible to practically update the global parameters by embedding a newline character within the psk value. In addition, the untrusted user/application would need to be able to install a library file somewhere on the device from where the wpa_supplicant process has privileges to load the library. References: http://seclists.org/oss-sec/2016/q2/187
Created wpa_supplicant tracking bugs for this issue: Affects: fedora-all [bug 1332426]
External references: http://w1.fi/security/2016-1/
From the upstream report linked in comment 2: > For the local control interface attack vector (CVE-2016-4477): > > wpa_supplicant v0.4.0-v2.5 with control interface enabled > > update_config=1 must have been enabled in the configuration file. wpa_supplicant versions shipped in RHEL 5-7 are within the affected versions; however, default configuration does not include the `update_config=1` flag. Normally, network connections are managed by NetworkManager which gives credentials to wpa_supplicant over DBus. It is possible to send invalid byte sequences as part of the key, but this flaw only comes into effect if wpa_supplicant itself writes these sequences into its config file and then attempts to re-read the file. Turning `update_config=1` on is not recommended since it allows users who can use the control interface to overwrite the entire wpa_supplicant configuration.