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.
Created wpa_supplicant tracking bugs for this issue:
Affects: fedora-all [bug 1332426]
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.