Move event.assoc_info.freq selection to be after the
nl80211_get_assoc_ssid() call so that the current cfg80211 information
on the operating channel can be used should anything unexpected have
happened between the association request and completion of association.
Furthermore, update bss->freq based on assoc_freq to make that
information a bit more useful for station mode. It was already updated
after channel switches during association, but not at the beginning of
association.
Signed-off-by: Jouni Malinen <j@w1.fi>
This fixes some issues where bss->freq could have been used to replace
the current operating channel when sending out a management frame.
bss->freq has not been consistently used to track the current operating
channel in station mode, so it should not be trusted for this type of
uses. Clearing it makes this a bit more robust by at least avoiding the
cases of information from past association being used.
Signed-off-by: Jouni Malinen <j@w1.fi>
None of the ECC groups supported in the implementation had a cofactor
greater than 1, so these checks are unreachable and for all cases, the
cofactor is known to be 1. Furthermore, RFC 5931 explicitly disallow use
of ECC groups with cofactor larger than 1, so this checks cannot be
needed for any curve that is compliant with the RFC.
Remove the unneeded group cofactor checks to simplify the
implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
Based on the SAE implementation guidance update to not allow ECC groups
with a prime that is under 256 bits, reject groups 25, 26, and 27 in
EAP-pwd.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is in preparation of disallowing all use of these groups. Negative
test case for the groups will be added in a separate commit after the
implementation has been changed.
Signed-off-by: Jouni Malinen <j@w1.fi>
It looks like SSL_CTX_set1_curves_list() command alone is not sufficient
to enable ECDH curve selection with older OpenSSL versions for TLS
server, so enable automatic selection first and specify the exact list
of curves after that.
This fixes failures in openssl_ecdh_curves test case when hostapd uses
OpenSSL 1.0.2.
Signed-off-by: Jouni Malinen <j@w1.fi>
It looks like the scan operation could end up reverting regdom back to
the previously configured one, so configure 00 country before starting
the disconnect-and-stop-scan operation to give some more time for the
regdom to be cleared.
Signed-off-by: Jouni Malinen <j@w1.fi>
The last beacon report indication was set in all the beacon report
elements in the last frame of the beacon report, while it should be set
only in the last beacon report element of the last frame. This is now
fixed in wpa_supplicant, so update the test case expectation to match
the fixed behavior.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
The last beacon report indication was set in all the beacon report
elements in the last frame of the beacon report, while it should be
set only in the last beacon report element of the last frame.
Fixes: ecef0687dc ("RRM: Support for Last Beacon Report Indication subelement")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Help the user be aware of the options to configure when
wpa_supplicant will remove a BSS due to expiration.
Signed-off-by: Ben Greear <greearb@candelatech.com>
The change to python3 broke trace-cmd recording, two
strings need to be bytes instead. Fix that.
Also add a flush() that seems to be needed now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The external authentication command and event does not need to copy the
BSSID/SSID values into struct external_auth since those values are used
before returning from the call. Simplify this by using const u8 * to
external data instead of the array with a copy of the external data.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Extend commit 5ff39c1380 ("SAE: Support external authentication
offload for driver-SME cases") to support external authentication
with drivers that implement AP SME by notifying the status of
SAE authentication to the driver after SAE handshake as the
driver acts as a pass through for the SAE Authentication frames.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
This extends driver interface to nl80211 by introducing the following
changes,
1. Register for Authenication frames in driver-based AP SME mode.
2. Advertise NL80211_ATTR_EXTERNAL_AUTH_SUPPORT in set_ap when
offloaded SAE authentication is supported.
3. Extend the NL80211_CMD_EXTERNAL_AUTH interface to also send PMKID
so that the drivers can respond to the PMKSA cached connection
attempts from the stations avoiding the need to contact user space
for all PMKID-based connections.
4. Send external auth status to driver only if it is a driver based
SME solution.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
beacon_set_done did not get reset to zero on disabling interface using
DISABLE control interface command and the subsequent ENABLE command will
caused configuration of Beacon/Probe Response/Association Response frame
IEs twice. The unnecessary two step configuration can be avoided by
resetting beacon_set_done on DISABLE so that ENABLE can bring up the
interface in a single step with fully updated IEs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Binary presentations of element and scalar can be written directly to
the allocated commit message buffer instead of having to first write
them into temporary buffers just to copy them to the actual message
buffer.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
RFC 5931 has these conditions as MUST requirements, so better follow
them explicitly even if the rand,mask == 0 or rand+mask == 0 or 1 cases
are very unlikely to occur in practice while generating random values
locally.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This adds an explicit check for 0 < x,y < prime based on RFC 5931,
2.8.5.2.2 requirement. The earlier checks might have covered this
implicitly, but it is safer to avoid any dependency on implicit checks
and specific crypto library behavior. (CVE-2019-9498 and CVE-2019-9499)
Furthermore, this moves the EAP-pwd element and scalar parsing and
validation steps into shared helper functions so that there is no need
to maintain two separate copies of this common functionality between the
server and peer implementations.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When processing an EAP-pwd Commit frame, the server's scalar and element
(elliptic curve point) were not validated. This allowed an adversary to
bypass authentication, and act as a rogue Access Point (AP) if the
crypto implementation did not verify the validity of the EC point.
Fix this vulnerability by assuring the received scalar lies within the
valid range, and by checking that the received element is not the point
at infinity and lies on the elliptic curve being used. (CVE-2019-9499)
The vulnerability is only exploitable if OpenSSL version 1.0.2 or lower
is used, or if LibreSSL or wolfssl is used. Newer versions of OpenSSL
(and also BoringSSL) implicitly validate the elliptic curve point in
EC_POINT_set_affine_coordinates_GFp(), preventing the attack.
Signed-off-by: Mathy Vanhoef <mathy.vanhoef@nyu.edu>
When processing an EAP-pwd Commit frame, verify that the peer's scalar
and elliptic curve element differ from the one sent by the server. This
prevents reflection attacks where the adversary reflects the scalar and
element sent by the server. (CVE-2019-9497)
The vulnerability allows an adversary to complete the EAP-pwd handshake
as any user. However, the adversary does not learn the negotiated
session key, meaning the subsequent 4-way handshake would fail. As a
result, this cannot be abused to bypass authentication unless EAP-pwd is
used in non-WLAN cases without any following key exchange that would
require the attacker to learn the MSK.
Signed-off-by: Mathy Vanhoef <mathy.vanhoef@nyu.edu>
When processing an EAP-pwd Commit frame, the peer's scalar and element
(elliptic curve point) were not validated. This allowed an adversary to
bypass authentication, and impersonate any user if the crypto
implementation did not verify the validity of the EC point.
Fix this vulnerability by assuring the received scalar lies within the
valid range, and by checking that the received element is not the point
at infinity and lies on the elliptic curve being used. (CVE-2019-9498)
The vulnerability is only exploitable if OpenSSL version 1.0.2 or lower
is used, or if LibreSSL or wolfssl is used. Newer versions of OpenSSL
(and also BoringSSL) implicitly validate the elliptic curve point in
EC_POINT_set_affine_coordinates_GFp(), preventing the attack.
Signed-off-by: Mathy Vanhoef <mathy.vanhoef@nyu.edu>
Explicitly verify that own and peer commit scalar/element are available
when trying to check SAE confirm message. It could have been possible to
hit a NULL pointer dereference if the peer element could not have been
parsed. (CVE-2019-9496)
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Try to avoid showing externally visible timing or memory access
differences regardless of whether the derived pwd-value is smaller than
the group prime.
This is related to CVE-2019-9494.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is an initial step towards making the FFC case use strictly
constant time operations similarly to the ECC case.
sae_test_pwd_seed_ffc() does not yet have constant time behavior,
though.
This is related to CVE-2019-9494.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
These groups have significant probability of coming up with pwd-value
that is equal or greater than the prime and as such, need for going
through the PWE derivation loop multiple times. This can result in
sufficient timing different to allow an external observer to determine
how many rounds are needed and that can leak information about the used
password.
Force at least 40 loop rounds for these MODP groups similarly to the ECC
group design to mask timing. This behavior is not described in IEEE Std
802.11-2016 for SAE, but it does not result in different values (i.e.,
only different timing), so such implementation specific countermeasures
can be done without breaking interoperability with other implementation.
Note: These MODP groups 22, 23, and 24 are not considered sufficiently
strong to be used with SAE (or more or less anything else). As such,
they should never be enabled in runtime configuration for any production
use cases. These changes to introduce additional protection to mask
timing is only for completeness of implementation and not an indication
that these groups should be used.
This is related to CVE-2019-9494.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
