mirror of
https://github.com/openwrt/openwrt.git
synced 2024-12-23 15:32:33 +00:00
8f17c019a1
EAP-pwd missing commit validation Published: April 10, 2019 Identifiers: - CVE-2019-9497 (EAP-pwd server not checking for reflection attack) - CVE-2019-9498 (EAP-pwd server missing commit validation for scalar/element) - CVE-2019-9499 (EAP-pwd peer missing commit validation for scalar/element) Latest version available from: https://w1.fi/security/2019-4/ Vulnerability EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP peer) was discovered not to validate the received scalar and element values in EAP-pwd-Commit messages properly. This could result in attacks that would be able to complete EAP-pwd authentication exchange without the attacker having to know the used password. A reflection attack is possible against the EAP-pwd server since the hostapd EAP server did not verify that the EAP-pwd-Commit contains scalar/element values that differ from the ones the server sent out itself. This allows the attacker to complete EAP-pwd authentication without knowing the password, but this does not result in the attacker being able to derive the session key (MSK), i.e., the attacker would not be able to complete the following key exchange (e.g., 4-way handshake in RSN/WPA). An attack using invalid scalar/element values is possible against both the EAP-pwd server and peer since hostapd and wpa_supplicant did not validate these values in the received EAP-pwd-Commit messages. If the used crypto library does not implement additional checks for the element (EC point), this could result in attacks where the attacker could use a specially crafted commit message values to manipulate the exchange to result in deriving a session key value from a very small set of possible values. This could further be used to attack the EAP-pwd server in a practical manner. An attack against the EAP-pwd peer is slightly more complex, but still consider practical. These invalid scalar/element attacks could result in the attacker being able to complete authentication and learn the session key and MSK to allow the key exchange to be completed as well, i.e., the attacker gaining access to the network in case of the attack against the EAP server or the attacker being able to operate a rogue AP in case of the attack against the EAP peer. While similar attacks might be applicable against SAE, it should be noted that the SAE implementation in hostapd and wpa_supplicant does have the validation steps that were missing from the EAP-pwd implementation and as such, these attacks do not apply to the current SAE implementation. Old versions of wpa_supplicant/hostapd did not include the reflection attack check in the SAE implementation, though, since that was added in June 2015 for v2.5 (commit 6a58444d27fd 'SAE: Verify that own/peer commit-scalar and COMMIT-ELEMENT are different'). Vulnerable versions/configurations All hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled in the runtime configuration) are vulnerable against the reflection attack. All wpa_supplicant and hostapd versions with EAP-pwd support (CONFIG_EAP_PWD=y in the build configuration and EAP-pwd being enabled in the runtime configuration) are vulnerable against the invalid scalar/element attack when built against a crypto library that does not have an explicit validation step on imported EC points. The following list indicates which cases are vulnerable/not vulnerable: - OpenSSL v1.0.2 or older: vulnerable - OpenSSL v1.1.0 or newer: not vulnerable - BoringSSL with commit 38feb990a183 ('Require that EC points are on the curve.') from September 2015: not vulnerable - BoringSSL without commit 38feb990a183: vulnerable - LibreSSL: vulnerable - wolfssl: vulnerable Acknowledgments Thanks to Mathy Vanhoef (New York University Abu Dhabi) for discovering and reporting the issues and for proposing changes to address them in the implementation. Possible mitigation steps - Merge the following commits to wpa_supplicant/hostapd and rebuild: CVE-2019-9497: EAP-pwd server: Detect reflection attacks CVE-2019-9498: EAP-pwd server: Verify received scalar and element EAP-pwd: Check element x,y coordinates explicitly CVE-2019-9499: EAP-pwd client: Verify received scalar and element EAP-pwd: Check element x,y coordinates explicitly These patches are available from https://w1.fi/security/2019-4/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
54 lines
2.0 KiB
Diff
54 lines
2.0 KiB
Diff
From 8ad8585f91823ddcc3728155e288e0f9f872e31a Mon Sep 17 00:00:00 2001
|
|
From: Mathy Vanhoef <mathy.vanhoef@nyu.edu>
|
|
Date: Sun, 31 Mar 2019 17:43:44 +0200
|
|
Subject: [PATCH 13/14] EAP-pwd client: Verify received scalar and element
|
|
|
|
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>
|
|
---
|
|
src/eap_peer/eap_pwd.c | 20 ++++++++++++++++++++
|
|
1 file changed, 20 insertions(+)
|
|
|
|
--- a/src/eap_peer/eap_pwd.c
|
|
+++ b/src/eap_peer/eap_pwd.c
|
|
@@ -594,6 +594,26 @@ eap_pwd_perform_commit_exchange(struct e
|
|
goto fin;
|
|
}
|
|
|
|
+ /* verify received scalar */
|
|
+ if (crypto_bignum_is_zero(data->server_scalar) ||
|
|
+ crypto_bignum_is_one(data->server_scalar) ||
|
|
+ crypto_bignum_cmp(data->server_scalar,
|
|
+ crypto_ec_get_order(data->grp->group)) >= 0) {
|
|
+ wpa_printf(MSG_INFO,
|
|
+ "EAP-PWD (peer): received scalar is invalid");
|
|
+ goto fin;
|
|
+ }
|
|
+
|
|
+ /* verify received element */
|
|
+ if (!crypto_ec_point_is_on_curve(data->grp->group,
|
|
+ data->server_element) ||
|
|
+ crypto_ec_point_is_at_infinity(data->grp->group,
|
|
+ data->server_element)) {
|
|
+ wpa_printf(MSG_INFO,
|
|
+ "EAP-PWD (peer): received element is invalid");
|
|
+ goto fin;
|
|
+ }
|
|
+
|
|
/* check to ensure server's element is not in a small sub-group */
|
|
if (!crypto_bignum_is_one(cofactor)) {
|
|
if (crypto_ec_point_mul(data->grp->group, data->server_element,
|