android_external_wpa_supplicant_8/src, branch cm-13.0 Unnamed repository; edit this file 'description' to name the repository. Use BoringSSL to get random bytes 2019-03-23T15:00:10+00:00 Rich Cannings richc@google.com 2018-10-09T20:56:37+00:00 c5b69375ea662f78f53db751c90657370f55b3cf Bug: 117508900 Change-Id: I4889513c0671ff2b689f1beca8084d6f149d473d Test: Existing tests pass (cherry picked from commit 29d54b87f121c79d5df87b0b2bcd7a1eb6090c1f) 
Bug: 117508900
Change-Id: I4889513c0671ff2b689f1beca8084d6f149d473d
Test: Existing tests pass
(cherry picked from commit 29d54b87f121c79d5df87b0b2bcd7a1eb6090c1f)
WNM: Fix WNM-Sleep Mode Request bounds checking 2019-02-02T21:05:01+00:00 Jouni Malinen jouni@codeaurora.org 2018-10-29T18:48:07+00:00 396b9dc5f2673bddbbf554f34df52fd9654a309a ieee802_11_rx_wnmsleep_req() might be called for a short frame that has no more payload after the Public Action field, i.e., with len == 0. The bounds checking for the payload length was done only for the information elements while the one octet Dialog Token field was read unconditionally. This could result in reading one octet beyond the end of the received frame data. Depending on driver interface specific mechanism used for fetching the frame, this could result in reading one octet beyond the end of a stack/hash buffer or reading an uninitialized octet from within a buffer. The actual value that was read as the Dialog Token field is not used since the function returns immediately after having read this value when there is no information elements following the field. This issue was initially added in commit d32d94dbf47a ("WNM: Add WNM-Sleep Mode implementation for AP") (with CONFIG_IEEE80211V=y build option) and it remained in place during number of cleanup and fix changes in this area and renaming of the build parameter to CONFIG_WNM=y. The impacted function was not included in any default build without one of the these optional build options being explicitly enabled. CONFIG_WNM=y is still documented as "experimental and not complete implementation" in hostapd/defconfig. In addition, commit 114f2830d2c2 ("WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0 case") made this function exit before the impact read if WNM-Sleep Mode support was not explicitly enabled in runtime configuration (wnm_sleep_mode=1 in hostapd.conf). Fix this by explicitly checking the frame has enough payload before reading the Dialog Token field. Bug: 111893132 Change-Id: I4b61e22c39d1a5683923eff34e43bb0c509913d4 Merged-In: I4b61e22c39d1a5683923eff34e43bb0c509913d4 Signed-off-by: Jouni Malinen <jouni@codeaurora.org> (cherry picked from commit 7a543744db8ece2376b019040b5668ede68ebd8b) CVE-2018-9589 
ieee802_11_rx_wnmsleep_req() might be called for a short frame that has
no more payload after the Public Action field, i.e., with len == 0. The
bounds checking for the payload length was done only for the information
elements while the one octet Dialog Token field was read
unconditionally. This could result in reading one octet beyond the end
of the received frame data.

Depending on driver interface specific mechanism used for fetching the
frame, this could result in reading one octet beyond the end of a
stack/hash buffer or reading an uninitialized octet from within a
buffer. The actual value that was read as the Dialog Token field is not
used since the function returns immediately after having read this value
when there is no information elements following the field.

This issue was initially added in commit d32d94dbf47a ("WNM: Add
WNM-Sleep Mode implementation for AP") (with CONFIG_IEEE80211V=y build
option) and it remained in place during number of cleanup and fix
changes in this area and renaming of the build parameter to
CONFIG_WNM=y. The impacted function was not included in any default
build without one of the these optional build options being explicitly
enabled. CONFIG_WNM=y is still documented as "experimental and not
complete implementation" in hostapd/defconfig. In addition, commit
114f2830d2c2 ("WNM: Ignore WNM-Sleep Mode Request in wnm_sleep_mode=0
case") made this function exit before the impact read if WNM-Sleep Mode
support was not explicitly enabled in runtime configuration
(wnm_sleep_mode=1 in hostapd.conf).

Fix this by explicitly checking the frame has enough payload before
reading the Dialog Token field.

Bug: 111893132
Change-Id: I4b61e22c39d1a5683923eff34e43bb0c509913d4
Merged-In: I4b61e22c39d1a5683923eff34e43bb0c509913d4
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
(cherry picked from commit 7a543744db8ece2376b019040b5668ede68ebd8b)
CVE-2018-9589
TDLS: Ignore incoming TDLS Setup Response retries 2017-10-19T19:44:49+00:00 Arik Nemtsov arik@wizery.com 2015-12-10T10:56:07+00:00 b7de80fb6ac0bf5324f3d69bdb641dc050136799 The Setup Response timer is relatively fast (500 ms) and there are instances where it fires on the responder side after the initiator has already sent out the TDLS Setup Confirm frame. Prevent the processing of this stale TDLS Setup Response frame on the initiator side. Change-Id: I595f41dc803d6707ee8d0ea220f594cce750139a Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> 
The Setup Response timer is relatively fast (500 ms) and there are
instances where it fires on the responder side after the initiator has
already sent out the TDLS Setup Confirm frame. Prevent the processing of
this stale TDLS Setup Response frame on the initiator side.

Change-Id: I595f41dc803d6707ee8d0ea220f594cce750139a
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Clear PMK length and check for this when deriving PTK 2017-10-19T18:53:12+00:00 Jouni Malinen j@w1.fi 2017-10-08T10:18:02+00:00 12b919a0cccf4e00302b5e65d9b272dc2e9bbcd6 Instead of setting the default PMK length for the cleared PMK, set the length to 0 and explicitly check for this when deriving PTK to avoid unexpected key derivation with an all-zeroes key should it be possible to somehow trigger PTK derivation to happen before PMK derivation. Change-Id: Ifef3b2ca5ee19e6e89df75fef697e7215f926cb1 Signed-off-by: Jouni Malinen <j@w1.fi> 
Instead of setting the default PMK length for the cleared PMK, set the
length to 0 and explicitly check for this when deriving PTK to avoid
unexpected key derivation with an all-zeroes key should it be possible
to somehow trigger PTK derivation to happen before PMK derivation.

Change-Id: Ifef3b2ca5ee19e6e89df75fef697e7215f926cb1
Signed-off-by: Jouni Malinen <j@w1.fi>
Add debug prints on PMK configuration in WPA supplicant 2017-10-19T18:53:12+00:00 Jouni Malinen j@w1.fi 2017-10-08T09:21:21+00:00 6dadaf9fed1f2270dfdbe5879d18d23c8be24919 This makes it easier to understand the cases where PMK gets configured based on information from upper layer call (e.g., a PSK). Change-Id: Ic7cbb18ed37de89d7378503c6b3d0f1da63db4dd Signed-off-by: Jouni Malinen <j@w1.fi> 
This makes it easier to understand the cases where PMK gets configured
based on information from upper layer call (e.g., a PSK).

Change-Id: Ic7cbb18ed37de89d7378503c6b3d0f1da63db4dd
Signed-off-by: Jouni Malinen <j@w1.fi>
WPA: Extra defense against PTK reinstalls in 4-way handshake 2017-10-19T18:53:12+00:00 Mathy Vanhoef Mathy.Vanhoef@cs.kuleuven.be 2017-10-05T21:53:01+00:00 989ffaa028b8418456655c4cc2867bebced80d17 Currently, reinstallations of the PTK are prevented by (1) assuring the same TPTK is only set once as the PTK, and (2) that one particular PTK is only installed once. This patch makes it more explicit that point (1) is required to prevent key reinstallations. At the same time, this patch hardens wpa_supplicant such that future changes do not accidentally break this property. Change-Id: Id03f4790d93deb1bc34b1055fb85ec80c5229bcc Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be> 
Currently, reinstallations of the PTK are prevented by (1) assuring the
same TPTK is only set once as the PTK, and (2) that one particular PTK
is only installed once. This patch makes it more explicit that point (1)
is required to prevent key reinstallations. At the same time, this patch
hardens wpa_supplicant such that future changes do not accidentally
break this property.

Change-Id: Id03f4790d93deb1bc34b1055fb85ec80c5229bcc
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
Remove all PeerKey functionality 2017-10-19T18:53:12+00:00 Jouni Malinen j@w1.fi 2017-09-22T11:59:13+00:00 4ecf487814046663edbc14a405407e891939a981 This was originally added to allow the IEEE 802.11 protocol to be tested, but there are no known fully functional implementations based on this nor any known deployments of PeerKey functionality. Furthermore, PeerKey design in the IEEE Std 802.11-2016 standard has already been marked as obsolete for DLS and it is being considered for complete removal in REVmd. This implementation did not really work, so it could not have been used in practice. For example, key configuration was using incorrect algorithm values (WPA_CIPHER_* instead of WPA_ALG_*) which resulted in mapping to an invalid WPA_ALG_* value for the actual driver operation. As such, the derived key could not have been successfully set for the link. Since there are bugs in this implementation and there does not seem to be any future for the PeerKey design with DLS (TDLS being the future for DLS), the best approach is to simply delete all this code to simplify the EAPOL-Key handling design and to get rid of any potential issues if these code paths were accidentially reachable. Change-Id: I10294a9ef31c46a27416a6063255939dcedc57d5 Signed-off-by: Jouni Malinen <j@w1.fi> 
This was originally added to allow the IEEE 802.11 protocol to be
tested, but there are no known fully functional implementations based on
this nor any known deployments of PeerKey functionality. Furthermore,
PeerKey design in the IEEE Std 802.11-2016 standard has already been
marked as obsolete for DLS and it is being considered for complete
removal in REVmd.

This implementation did not really work, so it could not have been used
in practice. For example, key configuration was using incorrect
algorithm values (WPA_CIPHER_* instead of WPA_ALG_*) which resulted in
mapping to an invalid WPA_ALG_* value for the actual driver operation.
As such, the derived key could not have been successfully set for the
link.

Since there are bugs in this implementation and there does not seem to
be any future for the PeerKey design with DLS (TDLS being the future for
DLS), the best approach is to simply delete all this code to simplify
the EAPOL-Key handling design and to get rid of any potential issues if
these code paths were accidentially reachable.

Change-Id: I10294a9ef31c46a27416a6063255939dcedc57d5
Signed-off-by: Jouni Malinen <j@w1.fi>
Add MGMT_TX_STATUS_PROCESS command for testing purposes 2017-10-19T18:53:12+00:00 Jouni Malinen j@w1.fi 2017-08-04T10:14:57+00:00 a270e3524539a3364cde70384b178b3890a130ba This allows ext_mgmt_frame_handling=1 cases with hostapd to process TX status events based on external processing. This is useful for increased test coverage of management frame processing. Change-Id: I056ec2a06334762245dfcb8261b9427e818ef52c Signed-off-by: Jouni Malinen <j@w1.fi> 
This allows ext_mgmt_frame_handling=1 cases with hostapd to process TX
status events based on external processing. This is useful for increased
test coverage of management frame processing.

Change-Id: I056ec2a06334762245dfcb8261b9427e818ef52c
Signed-off-by: Jouni Malinen <j@w1.fi>
FT: Do not allow multiple Reassociation Response frames 2017-10-19T18:53:11+00:00 Jouni Malinen j@w1.fi 2017-09-22T09:06:37+00:00 bae1637cde1fbca92872c6bad335ee4f5149fedb The driver is expected to not report a second association event without the station having explicitly request a new association. As such, this case should not be reachable. However, since reconfiguring the same pairwise or group keys to the driver could result in nonce reuse issues, be extra careful here and do an additional state check to avoid this even if the local driver ends up somehow accepting an unexpected Reassociation Response frame. Change-Id: Ie76301550e96bfcfe252d874f2e83deb0aeb9533 Signed-off-by: Jouni Malinen <j@w1.fi> 
The driver is expected to not report a second association event without
the station having explicitly request a new association. As such, this
case should not be reachable. However, since reconfiguring the same
pairwise or group keys to the driver could result in nonce reuse issues,
be extra careful here and do an additional state check to avoid this
even if the local driver ends up somehow accepting an unexpected
Reassociation Response frame.

Change-Id: Ie76301550e96bfcfe252d874f2e83deb0aeb9533
Signed-off-by: Jouni Malinen <j@w1.fi>
TDLS: Reject TPK-TK reconfiguration 2017-10-19T18:53:11+00:00 Jouni Malinen j@w1.fi 2017-09-22T08:03:15+00:00 38057c5da63cc2a139d79c93b905eac730c31c8e Do not try to reconfigure the same TPK-TK to the driver after it has been successfully configured. This is an explicit check to avoid issues related to resetting the TX/RX packet number. There was already a check for this for TPK M2 (retries of that message are ignored completely), so that behavior does not get modified. For TPK M3, the TPK-TK could have been reconfigured, but that was followed by immediate teardown of the link due to an issue in updating the STA entry. Furthermore, for TDLS with any real security (i.e., ignoring open/WEP), the TPK message exchange is protected on the AP path and simple replay attacks are not feasible. As an additional corner case, make sure the local nonce gets updated if the peer uses a very unlikely "random nonce" of all zeros. Change-Id: I84131f30c358f27aaf6277e8957d165bca5102aa Signed-off-by: Jouni Malinen <j@w1.fi> 
Do not try to reconfigure the same TPK-TK to the driver after it has
been successfully configured. This is an explicit check to avoid issues
related to resetting the TX/RX packet number. There was already a check
for this for TPK M2 (retries of that message are ignored completely), so
that behavior does not get modified.

For TPK M3, the TPK-TK could have been reconfigured, but that was
followed by immediate teardown of the link due to an issue in updating
the STA entry. Furthermore, for TDLS with any real security (i.e.,
ignoring open/WEP), the TPK message exchange is protected on the AP path
and simple replay attacks are not feasible.

As an additional corner case, make sure the local nonce gets updated if
the peer uses a very unlikely "random nonce" of all zeros.

Change-Id: I84131f30c358f27aaf6277e8957d165bca5102aa
Signed-off-by: Jouni Malinen <j@w1.fi>