openwrt/package/network/services/hostapd/patches/061-0007-SAE-Mask-timing-of-MODP-groups-22-23-24.patch

114 lines
3.5 KiB
Diff
Raw Normal View History

hostapd: fix CVE-2019-9494 SAE side-channel attacks Published: April 10, 2019 Identifiers: - VU#871675 - CVE-2019-9494 (cache attack against SAE) Latest version available from: https://w1.fi/security/2019-1/ Vulnerability Number of potential side channel attacks were discovered in the SAE implementations used by both hostapd (AP) and wpa_supplicant (infrastructure BSS station/mesh station). SAE (Simultaneous Authentication of Equals) is also known as WPA3-Personal. The discovered side channel attacks may be able to leak information about the used password based on observable timing differences and cache access patterns. This might result in full password recovery when combined with an offline dictionary attack and if the password is not strong enough to protect against dictionary attacks. Cache attack A novel cache-based attack against SAE handshake was discovered. This attack targets SAE with ECC groups. ECC group 19 being the mandatory group to support and the most likely used group for SAE today, so this attack applies to the most common SAE use case. Even though the PWE derivation iteration in SAE has protections against timing attacks, this new cache-based attack enables an attacker to determine which code branch is taken in the iteration if the attacker is able to run unprivileged code on the victim machine (e.g., an app installed on a smart phone or potentially a JavaScript code on a web site loaded by a web browser). This depends on the used CPU not providing sufficient protection to prevent unprivileged applications from observing memory access patterns through the shared cache (which is the most likely case with today's designs). The attacker can use information about the selected branch to learn information about the password and combine this information from number of handshake instances with an offline dictionary attack. With sufficient number of handshakes and sufficiently weak password, this might result in full discovery of the used password. This attack requires the attacker to be able to run a program on the target device. This is not commonly the case on access points, so the most likely target for this would be a client device using SAE in an infrastructure BSS or mesh BSS. The commits listed in the end of this advisory change the SAE implementation shared by hostapd and wpa_supplicant to perform the PWE derivation loop using operations that use constant time and memory access pattern to minimize the externally observable differences from operations that depend on the password even for the case where the attacker might be able to run unprivileged code on the same device. Timing attack The timing attack applies to the MODP groups 22, 23, and 24 where the PWE generation algorithm defined for SAE can have sufficient timing differences for an attacker to be able to determine how many rounds were needed to find the PWE based on the used password and MAC addresses. When the attack is repeated with multiple times, the attacker may be able to gather enough information about the password to be able to recover it fully using an offline dictionary attack if the password is not strong enough to protect against dictionary attacks. This attack could be performed by an attacker in radio range of an access point or a station enabling the specific MODP groups. This timing attack requires the applicable MODP groups to be enabled explicitly in hostapd/wpa_supplicant configuration (sae_groups parameter). All versions of hostapd/wpa_supplicant have disabled these groups by default. While this security advisory lists couple of commits introducing additional protection for MODP groups in SAE, it should be noted that the groups 22, 23, and 24 are not considered strong enough to meet the current expectation for a secure system. As such, their use is discouraged even if the additional protection mechanisms in the implementation are included. Vulnerable versions/configurations All wpa_supplicant and hostapd versions with SAE support (CONFIG_SAE=y in the build configuration and SAE being enabled in the runtime configuration). Acknowledgments Thanks to Mathy Vanhoef (New York University Abu Dhabi) and Eyal Ronen (Tel Aviv University) for discovering the issues and for discussions on how to address them. Possible mitigation steps - Merge the following commits to wpa_supplicant/hostapd and rebuild: OpenSSL: Use constant time operations for private bignums Add helper functions for constant time operations OpenSSL: Use constant time selection for crypto_bignum_legendre() SAE: Minimize timing differences in PWE derivation SAE: Avoid branches in is_quadratic_residue_blind() SAE: Mask timing of MODP groups 22, 23, 24 SAE: Use const_time selection for PWE in FFC SAE: Use constant time operations in sae_test_pwd_seed_ffc() These patches are available from https://w1.fi/security/2019-1/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available - In addition to either of the above alternatives, disable MODP groups 1, 2, 5, 22, 23, and 24 by removing them from hostapd/wpa_supplicant sae_groups runtime configuration parameter, if they were explicitly enabled since those groups are not considered strong enough to meet current security expectations. The groups 22, 23, and 24 are related to the discovered side channel (timing) attack. The other groups in the list are consider too weak to provide sufficient security. Note that all these groups have been disabled by default in all hostapd/wpa_supplicant versions and these would be used only if explicitly enabled in the configuration. - Use strong passwords to prevent dictionary attacks Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> [bump PKG_RELEASE] Signed-off-by: Jo-Philipp Wich <jo@mein.io>
2019-04-11 00:53:10 +00:00
From 90839597cc4016b33f00055b12d59174c62770a3 Mon Sep 17 00:00:00 2001
From: Jouni Malinen <jouni@codeaurora.org>
Date: Sat, 2 Mar 2019 12:24:09 +0200
Subject: [PATCH 07/14] SAE: Mask timing of MODP groups 22, 23, 24
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>
---
src/common/sae.c | 38 ++++++++++++++++++++++++++++----------
1 file changed, 28 insertions(+), 10 deletions(-)
--- a/src/common/sae.c
+++ b/src/common/sae.c
@@ -578,22 +578,27 @@ fail:
}
+static int sae_modp_group_require_masking(int group)
+{
+ /* Groups for which pwd-value is likely to be >= p frequently */
+ return group == 22 || group == 23 || group == 24;
+}
+
+
static int sae_derive_pwe_ffc(struct sae_data *sae, const u8 *addr1,
const u8 *addr2, const u8 *password,
size_t password_len, const char *identifier)
{
- u8 counter;
+ u8 counter, k;
u8 addrs[2 * ETH_ALEN];
const u8 *addr[3];
size_t len[3];
size_t num_elem;
int found = 0;
+ struct crypto_bignum *pwe = NULL;
- if (sae->tmp->pwe_ffc == NULL) {
- sae->tmp->pwe_ffc = crypto_bignum_init();
- if (sae->tmp->pwe_ffc == NULL)
- return -1;
- }
+ crypto_bignum_deinit(sae->tmp->pwe_ffc, 1);
+ sae->tmp->pwe_ffc = NULL;
wpa_hexdump_ascii_key(MSG_DEBUG, "SAE: password",
password, password_len);
@@ -617,7 +622,9 @@ static int sae_derive_pwe_ffc(struct sae
len[num_elem] = sizeof(counter);
num_elem++;
- for (counter = 1; !found; counter++) {
+ k = sae_modp_group_require_masking(sae->group) ? 40 : 1;
+
+ for (counter = 1; counter <= k || !found; counter++) {
u8 pwd_seed[SHA256_MAC_LEN];
int res;
@@ -627,19 +634,30 @@ static int sae_derive_pwe_ffc(struct sae
break;
}
- wpa_printf(MSG_DEBUG, "SAE: counter = %u", counter);
+ wpa_printf(MSG_DEBUG, "SAE: counter = %02u", counter);
if (hmac_sha256_vector(addrs, sizeof(addrs), num_elem,
addr, len, pwd_seed) < 0)
break;
- res = sae_test_pwd_seed_ffc(sae, pwd_seed, sae->tmp->pwe_ffc);
+ if (!pwe) {
+ pwe = crypto_bignum_init();
+ if (!pwe)
+ break;
+ }
+ res = sae_test_pwd_seed_ffc(sae, pwd_seed, pwe);
if (res < 0)
break;
if (res > 0) {
- wpa_printf(MSG_DEBUG, "SAE: Use this PWE");
found = 1;
+ if (!sae->tmp->pwe_ffc) {
+ wpa_printf(MSG_DEBUG, "SAE: Use this PWE");
+ sae->tmp->pwe_ffc = pwe;
+ pwe = NULL;
+ }
}
}
+ crypto_bignum_deinit(pwe, 1);
+
return found ? 0 : -1;
}