The following flaw was found in the EAP-pwd server and peer implementation of wpa_supplicant and hostapd:
The EAP-pwd/Commit and EAP-pwd/Confirm message payload is processed without verifying that the received frame is long enough to include all the fields. This results in buffer read overflow of up to couple of hundred bytes.
The exact result of this buffer overflow depends on the platform and may be either not noticeable (i.e., authentication fails due to invalid data without any additional side effects) or process termination due to the buffer read overflow being detected and stopped. The latter case could potentially result in denial of service when EAP-pwd authentication is used.
Further research into this issue found that the fragment reassembly processing is also missing a check for the Total-Length field and this could result in the payload length becoming negative. This itself would not add more to the vulnerability due to the payload length not being verified anyway. However, it is possible that a related reassembly step would result in hitting an internal security check on buffer use and result in the processing being terminated.
Note that this issue affects instances with CONFIG_EAP_PWD=y and EAP-pwd authentication server enabled in runtime configuration.
Created hostapd tracking bugs for this issue:
Affects: fedora-all [bug 1219453]
Affects: epel-6 [bug 1219454]
Affects: epel-7 [bug 1219455]
Created wpa_supplicant tracking bugs for this issue:
Affects: fedora-all [bug 1219452]
We are not enabling the option with the reported problem.
Affected code does not exist in wpa_supplicant versions in Red Hat Enterprise Linux 6 and earlier. The wpa_supplicant packages in Red Hat Enterprise Linux 7, and the wpa_supplicant and hostapd packages in Fedora and Fedora EPEL are not built with the CONFIG_EAP_PWD configuration option and hence are also unaffected.
Not vulnerable. This issue did not affect the versions of wpa_supplicant as shipped with Red Hat Enterprise Linux 5, 6, and 7.
I fear however that if we get a request to add EAP-PWD in the future, that we'll miss this security fix and just add CONFIG_EAP_PWD to the build config and re-introduce the vulnerability... It's unlikely that we'll rebase the supplicant (and thus pick up the fix) due to the QE impact of doing so.
Four CVEs were assigned to fixes under this upstream advisory. Quoting form:
Use CVE-2015-4143 for the "The length of the received Commit and
Confirm message payloads was not checked before reading them. This
could result in a buffer read overflow when processing an invalid
message." issues in both
Use CVE-2015-4144 for "The remaining number of bytes in the message
could be smaller than the Total-Length field size, so the length needs
to be explicitly checked prior to reading the field and decrementing
the len variable. This could have resulted in the remaining length
becoming negative and interpreted as a huge positive integer." in both
Use CVE-2015-4145 for "check that there is no already started fragment
in progress before allocating a new buffer for reassembling fragments.
This avoid a potential memory leak when processing invalid message."
Use CVE-2015-4146 for