aboutsummaryrefslogtreecommitdiffstats
path: root/package/network/services/hostapd/patches
Commit message (Collapse)AuthorAgeFilesLines
* hostapd: Remove unneeded patchHauke Mehrtens2019-11-148-28/+14
| | | | | | | | All the content of this function is proceeded by IEEE8021X_EAPOL no code accesses the ssid variable outside of this ifdef. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 0d86bf518aaefa57bef577d09a18aff03eccb70c)
* hostapd: use config option CONFIG_NO_LINUX_PACKET_SOCKET_WARHauke Mehrtens2019-11-141-12/+0
| | | | | | | Instead of patching the workaround away, just use the config option. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 9b4a27455c17c00698ce7ce24e0bcad419c6319e)
* hostapd: Update to version 2.9 (2019-08-08)Hauke Mehrtens2019-11-1439-627/+178
| | | | | | | | | | | | | | | | | | | The size of the ipkgs increase a bit (between 0.7% and 1.1%): old 2019-04-21 (2.8): 288264 wpad-basic_2019-04-21-63962824-1_mipsel_24kc.ipk 256188 wpad-mini_2019-04-21-63962824-1_mipsel_24kc.ipk 427475 wpad-openssl_2019-04-21-63962824-1_mipsel_24kc.ipk 423071 wpad-wolfssl_2019-04-21-63962824-1_mipsel_24kc.ipk new 2019-08-08 (2.9): 290217 wpad-basic_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk 258745 wpad-mini_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk 431732 wpad-openssl_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk 427641 wpad-wolfssl_2019-08-08-ca8c2bd2-1_mipsel_24kc.ipk Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 167028b750028ae3dac24f5ff96bbb1ba04e8bd7)
* hostapd: Update to version 2.8 (2019-04-21)Hauke Mehrtens2019-11-1479-5602/+413
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also syncs the configuration files with the default configuration files, but no extra options are activated or deactivated. The mesh patches were partially merged into hostapd 2.8, the remaining patches were extracted from patchwork and are now applied by OpenWrt. The patches still have open questions which are not fixed by the author. They were taken from this page: https://patchwork.ozlabs.org/project/hostap/list/?series=62725&state=* The changes in 007-mesh-apply-channel-attributes-before-running-Mesh.patch where first applied to hostapd, but later reverted in hostapd commit 3e949655ccc5 because they caused memory leaks. The size of the ipkgs increase a bit (between 1.3% and 2.3%): old 2018-12-02 (2.7): 283337 wpad-basic_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk 252857 wpad-mini_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk 417473 wpad-openssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk 415105 wpad-wolfssl_2018-12-02-c2c6c01b-11_mipsel_24kc.ipk new 2019-04-21 (2.8): 288264 wpad-basic_2019-04-21-63962824-1_mipsel_24kc.ipk 256188 wpad-mini_2019-04-21-63962824-1_mipsel_24kc.ipk 427475 wpad-openssl_2019-04-21-63962824-1_mipsel_24kc.ipk 423071 wpad-wolfssl_2019-04-21-63962824-1_mipsel_24kc.ipk Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> (cherry picked from commit 8af79550e6c280717660f66032d89d21007b15d2)
* hostapd: declare struct wpa_bss earlyLeon M. George2019-11-141-0/+19
| | | | | | | | | | | | | | | | | wps_supplicant.h assumes that 'struct wpa_bss' is forward declared if CONFIG_WPS is not defined. With the later inclusion of 600-ubus_support, the issue manifests in warnings like these: wps_supplicant.h:113:15: warning: 'struct wpa_bss' declared inside parameter list will not be visible outside of this definition or declaration struct wpa_bss *bss) ^~~~~~~ This patch forward declares 'struct wpa_bss' regardless. Signed-off-by: Leon M. George <leon@georgemail.eu> [commit message facelift] Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit f974f8213b94578581b35e6b3f8fb1fd5a35f753)
* hostapd: revert signature change in patchLeon M. George2019-11-141-1/+1
| | | | | | | | | | | | | The original wpa_hexdump uses a 'void *' for the payload. With patch 410-limit_debug_messages, the signature changes and compiler warnings occur at various places. One such warning is: wpa_debug.h:106:20: note: expected 'const u8 * {aka const unsigned char *}' but argument is of type 'struct wpa_eapol_key *' Signed-off-by: Leon M. George <leon@georgemail.eu> [commit message facelift] Signed-off-by: Petr Štetiar <ynezz@true.cz> (cherry picked from commit a123df275846b1b83aaf3d7488a1544f7c0e09aa)
* hostapd: Fix AP mode PMF disconnection protection bypassHauke Mehrtens2019-09-214-6/+72
| | | | | | | | | This fixes * CVE-2019-16275 AP mode PMF disconnection protection bypass https://w1.fi/security/2019-7/ap-mode-pmf-disconnection-protection-bypass.txt Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit a6981604b30bc1ddc1713b368fe853d89c2ba40d)
* hostapd: SAE/EAP-pwd side-channel attack updateHauke Mehrtens2019-09-108-0/+396
| | | | | | | | | Fixes this security problem: * SAE/EAP-pwd side-channel attack update https://w1.fi/security/2019-6/sae-eap-pwd-side-channel-attack-update.txt Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 7bed9bf10fc8d05df34c7efc66e8b4ade37a1a0c)
* hostapd: Fix security problem in EAP-pwdHauke Mehrtens2019-09-102-0/+80
| | | | | | | | | | | | This fixes: CVE-2019-11555 "EAP-pwd message reassembly issue with unexpected fragment" https://w1.fi/security/2019-5/eap-pwd-message-reassembly-issue-with-unexpected-fragment.txt This should not affect OpenWrt in the default settings as we do not use EAP-pwd. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit 9f34bf51d60a237696b1d4cc9b5f4835b95e7ea2)
* hostapd: fix CVE-2019-9497, CVE-2019-9498, CVE-2019-9499Stefan Lippers-Hollmann2019-04-114-0/+466
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hostapd: fix CVE-2019-9496Stefan Lippers-Hollmann2019-04-111-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hostapd: fix SAE confirm missing state validation Published: April 10, 2019 Identifiers: - CVE-2019-9496 (SAE confirm missing state validation in hostapd/AP) Latest version available from: https://w1.fi/security/2019-3/ Vulnerability When hostapd is used to operate an access point with SAE (Simultaneous Authentication of Equals; also known as WPA3-Personal), an invalid authentication sequence could result in the hostapd process terminating due to a NULL pointer dereference when processing SAE confirm message. This was caused by missing state validation steps when processing the SAE confirm message in hostapd/AP mode. Similar cases against the wpa_supplicant SAE station implementation had already been tested by the hwsim test cases, but those sequences did not trigger this specific code path in AP mode which is why the issue was not discovered earlier. An attacker in radio range of an access point using hostapd in SAE configuration could use this issue to perform a denial of service attack by forcing the hostapd process to terminate. Vulnerable versions/configurations All hostapd versions with SAE support (CONFIG_SAE=y in the build configuration and SAE being enabled in the runtime configuration). Possible mitigation steps - Merge the following commit to hostapd and rebuild: SAE: Fix confirm message validation in error cases These patches are available from https://w1.fi/security/2019-3/ - Update to 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>
* hostapd: fix CVE-2019-9495Stefan Lippers-Hollmann2019-04-111-0/+319
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EAP-pwd side-channel attack Published: April 10, 2019 Identifiers: - CVE-2019-9495 (cache attack against EAP-pwd) Latest version available from: https://w1.fi/security/2019-2/ Vulnerability Number of potential side channel attacks were recently discovered in the SAE implementations used by both hostapd and wpa_supplicant (see security advisory 2019-1 and VU#871675). EAP-pwd uses a similar design for deriving PWE from the password and while a specific attack against EAP-pwd is not yet known to be tested, there is no reason to believe that the EAP-pwd implementation would be immune against the type of cache attack that was identified for the SAE implementation. Since the EAP-pwd implementation in hostapd (EAP server) and wpa_supplicant (EAP peer) does not support MODP groups, the timing attack described against SAE is not applicable for the EAP-pwd implementation. A novel cache-based attack against SAE handshake would likely be applicable against the EAP-pwd implementation. Even though the wpa_supplicant/hostapd PWE derivation iteration for EAP-pwd has protections against timing attacks, this new cache-based attack might enable 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 could 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 recovery of the used password if that password is not strong enough to protect against dictionary attacks. This attack requires the attacker to be able to run a program on the target device. This is not commonly the case on an authentication server (EAP server), so the most likely target for this would be a client device using EAP-pwd. The commits listed in the end of this advisory change the EAP-pwd 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. Vulnerable versions/configurations 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). It should also be noted that older versions of wpa_supplicant/hostapd prior to v2.7 did not include additional protection against certain timing differences. The definition of the EAP-pwd (RFC 5931) does not describe such protection, but the same issue that was addressed in SAE earlier can be applicable against EAP-pwd as well and as such, that implementation specific extra protection (commit 22ac3dfebf7b, "EAP-pwd: Mask timing of PWE derivation") is needed to avoid showing externally visible timing differences that could leak information about the password. Any uses of older wpa_supplicant/hostapd versions with EAP-pwd are recommended to update to v2.7 or newer in addition to the mitigation steps listed below for the more recently discovered issue. 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() EAP-pwd: Use constant time and memory access for finding the PWE These patches are available from https://w1.fi/security/2019-2/ - Update to wpa_supplicant/hostapd v2.8 or newer, once available - 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>
* hostapd: fix CVE-2019-9494Stefan Lippers-Hollmann2019-04-118-0/+1082
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* hostapd: add Multi-AP patches and config optionsArnout Vandecappelle (Essensium/Mind)2019-02-2011-12/+2168
| | | | | | | | | | | | | | | | | | | | | | | | | | Cherry-pick Multi-AP commits from uptream: 9c06f0f6a hostapd: Add Multi-AP protocol support 5abc7823b wpa_supplicant: Add Multi-AP backhaul STA support a1debd338 tests: Refactor test_multi_ap bfcdac1c8 Multi-AP: Don't reject backhaul STA on fronthaul BSS cb3c156e7 tests: Update multi_ap_fronthaul_on_ap to match implementation 56a2d788f WPS: Add multi_ap_subelem to wps_build_wfa_ext() 83ebf5586 wpa_supplicant: Support Multi-AP backhaul STA onboarding with WPS 66819b07b hostapd: Support Multi-AP backhaul STA onboarding with WPS 8682f384c hostapd: Add README-MULTI-AP b1daf498a tests: Multi-AP WPS provisioning Add support for Multi-AP to the UCI configuration. Every wifi-iface gets an option 'multi_ap'. For APs, its value can be 0 (multi-AP support disabled), 1 (backhaul AP), 2 (fronthaul AP), or 3 (fronthaul + backhaul AP). For STAs, it can be 0 (not a backhaul STA) or 1 (backhaul STA, can only associate with backhaul AP). Also add new optional parameter to wps_start ubus call of wpa_supplicant to indicate that a Multi-AP backhaul link is required. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* hostapd: update the fix for a race condition in mesh new peer handlingFelix Fietkau2019-02-171-2/+2
| | | | | | | Prevent the mesh authentication state machine from getting reset on bogus new peer discovery Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: fix race condition in mesh new peer handlingFelix Fietkau2019-02-121-0/+34
| | | | | | Avoid trying to add the same station to the driver multiple times Signed-off-by: Felix Fietkau <nbd@nbd.name>
* wpa_supplicant: fix calling channel switch via wpa_cli on mesh interfacesFelix Fietkau2019-01-291-0/+39
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: add support for passing CSA events from sta/mesh to AP interfacesFelix Fietkau2019-01-292-2/+183
| | | | | | Fixes handling CSA when using AP+STA or AP+Mesh Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: update to version 2018-12-02 (2.7)Hauke Mehrtens2019-01-0237-425/+165
| | | | | | | | | | This updates hostapd to version the git version from 2018-12-02 which matches the 2.7 release. The removed patches were are already available in the upstream code, one additional backport is needed to fix a compile problem. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* hostapd: add support for WPS pushbutton stationDaniel Golle2018-12-121-0/+82
| | | | | | | | | | | | | | | | | | | | | | similar to hostapd, also add a ubus interface for wpa_supplicant which will allow handling WPS push-button just as it works for hostapd. In order to have wpa_supplicant running without any network configuration (so you can use it to retrieve credentials via WPS), configure wifi-iface in /etc/config/wireless: config wifi-iface 'default_radio0' option device 'radio0' option network 'wwan' option mode 'sta' option encryption 'wps' This section will automatically be edited if credentials have successfully been acquired via WPS. Size difference (mips_24kc): roughly +4kb for the 'full' variants of wpa_supplicant and wpad which do support WPS. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: fix MAC filter related log spamJo-Philipp Wich2018-10-163-10/+77
| | | | | | | | Backport two upstream fixes to address overly verbose logging of MAC ACL rejection messages. Fixes: FS#1468 Signed-off-by: Jo-Philipp Wich <jo@mein.io>
* hostapd: SAE: Do not ignore option sae_require_mfpHauke Mehrtens2018-10-141-0/+26
| | | | | | This patch was send for integration into the hostapd project. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* hostapd: backport build fix when OWE is activatedHauke Mehrtens2018-10-145-18/+35
| | | | | | This backports a compile fix form the hostapd project. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* hostapd: Fix compile with OpenSSL 1.1.0 + no deprecated APIsRosen Penev2018-09-101-0/+40
| | | | | | | | Patch was accepted upsteam: https://w1.fi/cgit/hostap/commit/?id=373c796948599a509bad71695b5b72eef003f661 Signed-off-by: Rosen Penev <rosenp@gmail.com>
* wpa_supplicant: fix CVE-2018-14526John Crispin2018-08-101-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unauthenticated EAPOL-Key decryption in wpa_supplicant Published: August 8, 2018 Identifiers: - CVE-2018-14526 Latest version available from: https://w1.fi/security/2018-1/ Vulnerability A vulnerability was found in how wpa_supplicant processes EAPOL-Key frames. It is possible for an attacker to modify the frame in a way that makes wpa_supplicant decrypt the Key Data field without requiring a valid MIC value in the frame, i.e., without the frame being authenticated. This has a potential issue in the case where WPA2/RSN style of EAPOL-Key construction is used with TKIP negotiated as the pairwise cipher. It should be noted that WPA2 is not supposed to be used with TKIP as the pairwise cipher. Instead, CCMP is expected to be used and with that pairwise cipher, this vulnerability is not applicable in practice. When TKIP is negotiated as the pairwise cipher, the EAPOL-Key Key Data field is encrypted using RC4. This vulnerability allows unauthenticated EAPOL-Key frames to be processed and due to the RC4 design, this makes it possible for an attacker to modify the plaintext version of the Key Data field with bitwise XOR operations without knowing the contents. This can be used to cause a denial of service attack by modifying GTK/IGTK on the station (without the attacker learning any of the keys) which would prevent the station from accepting received group-addressed frames. Furthermore, this might be abused by making wpa_supplicant act as a decryption oracle to try to recover some of the Key Data payload (GTK/IGTK) to get knowledge of the group encryption keys. Full recovery of the group encryption keys requires multiple attempts (128 connection attempts per octet) and each attempt results in disconnection due to a failure to complete the 4-way handshake. These failures can result in the AP/network getting disabled temporarily or even permanently (requiring user action to re-enable) which may make it impractical to perform the attack to recover the keys before the AP has already changes the group keys. By default, wpa_supplicant is enforcing at minimum a ten second wait time between each failed connection attempt, i.e., over 20 minutes waiting to recover each octet while hostapd AP implementation uses 10 minute default for GTK rekeying when using TKIP. With such timing behavior, practical attack would need large number of impacted stations to be trying to connect to the same AP to be able to recover sufficient information from the GTK to be able to determine the key before it gets changed. Vulnerable versions/configurations All wpa_supplicant versions. Acknowledgments Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU Leuven for discovering and reporting this issue. Possible mitigation steps - Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This can be done also on the AP side. - Merge the following commits to wpa_supplicant and rebuild: WPA: Ignore unauthenticated encrypted EAPOL-Key data This patch is available from https://w1.fi/security/2018-1/ - Update to wpa_supplicant v2.7 or newer, once available Signed-off-by: John Crispin <john@phrozen.org>
* hostapd: add ht and vht support in handle event function Add ht and vht ↵Nick Hainke2018-07-301-2/+3
| | | | | | capabilities. If a device sends a probe request, the capabilities are added. Signed-off-by: Nick Hainke <vincent@systemli.org>
* hostapd: remove unused struct hostapd_ubus_ifaceFelix Fietkau2018-07-221-10/+1
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: build with LTO enabled (using jobserver for parallel build)Felix Fietkau2018-07-101-0/+50
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: make cli treat UNKNOWN COMMAND as failingDenton Gentry2018-06-071-0/+13
| | | | | | | | | | | Avoid infinite loop at 100% CPU when running hostapd_cli if CONFIG_CTRL_IFACE_MIB is not defined. _newselect(4, [3], NULL, NULL, ...) recvfrom(3, "UNKNOWN COMMAND\n", 4095, 0, NULL, NULL) = 16 sendto(3, "STA-NEXT UNKNOWN COMMAND", 24, 0, NULL, 0) = 24 Signed-off-by: Denton Gentry <denny@geekhold.com>
* hostapd: add support for client taxonomy in the full configFelix Fietkau2018-06-051-4/+28
| | | | | | | This can be used to fingerprint clients to try to identify the exact model Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: update packaging and patchesDaniel Golle2018-05-3135-469/+355
| | | | | | | | | | Clean up conflicts/provides/depends hell and add PROVIDES for eapol-test variants while at it. Update mesh-DFS patchset from Peter Oh to v5 (with local fixes) which allows to drop two revert-patches for upstream commits which previously were necessary to un-break mesh-DFS support. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: update to git HEAD of 2018-05-21, allow build against wolfsslDaniel Golle2018-05-2434-281/+553
| | | | | | | Support for building wpa_supplicant/hostapd against wolfssl has been added upstream recently, add build option to allow users using it. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: fix VHT80 for encrypted mesh channel settingsSven Eckelmann2018-05-141-0/+45
| | | | | | | | | | | | | | | | | | | The max_oper_chwidth settings was parsed incorrectly for big endian system. This prevented the system to switch to VHT80 (or VHT160). Instead they were mapped to: * HT20: 20MHz * VHT20: 20MHz * HT40: 40MHz * VHT40: 40MHz * VHT80: 40MHz * VHT160: 40MHz This happened because each max_oper_chwidth setting in the config file was parsed as "0" instead of the actual value. Fixes: a4322eba2b12 ("hostapd: fix encrypted mesh channel settings") Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
* hostapd: fix mesh+APDaniel Golle2018-05-1413-216/+167
| | | | | | | | Fix encrypted (or DFS) AP+MESH interface combination in a way similar to how it's done for AP+STA and fix netifd shell script. Refresh patches while at it. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: fix a mesh mode crash with CONFIG_TAXONOMY enabledFelix Fietkau2018-05-031-0/+23
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: fix encrypted mesh channel settingsDaniel Golle2018-04-203-0/+223
| | | | | | | | | | | | | | | Import two patches from Peter Oh to allow setting channel bandwidth in the way it already works for managed interfaces. This fixes mesh interfaces on 802.11ac devices always coming up in VHT80 mode. Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which also skips secondary channel scan just like noscan works in AP mode. This time also make sure to add all files to the patch before committing it... Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* Revert "hostapd: fix encrypted mesh channel settings"Felix Fietkau2018-04-203-210/+0
| | | | | | | This reverts commit 7f52919a2f2894125b4dca611eb2d30181af7e0b, which is currently breaking the builds and needs to be reworked Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: fix encrypted mesh channel settingsDaniel Golle2018-04-203-0/+210
| | | | | | | | | | | | Import two patches from Peter Oh to allow setting channel bandwidth in the way it already works for managed interfaces. This fixes mesh interfaces on 802.11ac devices always coming up in VHT80 mode. Add a patch to allow HT40 also on 2.4GHz if noscan option is set, which also skips secondary channel scan just like noscan works in AP mode. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: mesh: make forwarding configurableDaniel Golle2018-04-181-0/+242
| | | | | | | | | | | For unencrypted mesh networks our scripts take care of setting the various mesh_param values. wpa_supplicant changes somes of them when being used for SAE encrypted mesh and previously didn't allow configuring any of them. Add support for setting mesh_fwding (which has to be set to 0 when using other routing protocols on top of 802.11s) and update our script to pass the value to wpa_supplicant. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: fix compile of -mini variantsDaniel Golle2018-04-131-0/+23
| | | | | | Fixes commit d88934aa5a (hostapd: update to git snapshot of 2018-04-09) Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: update to git snapshot of 2018-04-09Daniel Golle2018-04-1331-73/+1082
| | | | | | | | | And import patchset to allow 802.11s mesh on DFS channels, see also http://lists.infradead.org/pipermail/hostap/2018-April/038418.html Fix sae_password for encryption mesh (sent upstream as well). Also refreshed existing patches and fixed 463-add-mcast_rate-to-11s. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: update to git snapshot of 2018-03-26Daniel Golle2018-03-2733-1525/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patches were merged upstream: 000-hostapd-Avoid-key-reinstallation-in-FT-handshake.patch replaced by commit 0e3bd7ac6 001-Prevent-reinstallation-of-an-already-in-use-group-ke.patch replaced by commit cb5132bb3 002-Extend-protection-of-GTK-IGTK-reinstallation-of-WNM-.patch replaced by commit 87e2db16b 003-Prevent-installation-of-an-all-zero-TK.patch replaced by commit 53bb18cc8 004-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch replaced by commit 0adc9b28b 005-TDLS-Reject-TPK-TK-reconfiguration.patch replaced by commit ff89af96e 006-WNM-Ignore-WNM-Sleep-Mode-Response-without-pending-r.patch replaced by commit adae51f8b 007-FT-Do-not-allow-multiple-Reassociation-Response-fram.patch replaced by commit 2a9c5217b 008-WPA-Extra-defense-against-PTK-reinstalls-in-4-way-ha.patch replaced by commit a00e946c1 009-Clear-PMK-length-and-check-for-this-when-deriving-PT.patch replaced by commit b488a1294 010-Optional-AP-side-workaround-for-key-reinstallation-a.patch replaced by commit 6f234c1e2 011-Additional-consistentcy-checks-for-PTK-component-len.patch replaced by commit a6ea66530 012-Clear-BSSID-information-in-supplicant-state-machine-.patch replaced by commit c0fe5f125 013-WNM-Ignore-WNM-Sleep-Mode-Request-in-wnm_sleep_mode-.patch replaced by commit 114f2830d Some patches had to be modified to work with changed upstream source: 380-disable_ctrl_iface_mib.patch (adding more ifdef'ery) plus some minor knits needed for other patches to apply which are not worth being explicitely listed here. For SAE key management in mesh mode, use the newly introduce sae_password parameter instead of the psk parameter to also support SAE keys which would fail the checks applied on the psk field (ie. length and such). This fixes compatibility issues for users migrating from authsae. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
* hostapd: return with 80211 codes in handle event functionNick Hainke2018-02-211-13/+27
| | | | | | | | | | | If the auth or assoc request was denied the reason was always WLAN_STATUS_UNSPECIFIED_FAILURE. That's why for example the wpa supplicant was always trying to reconnect to the AP. Now it's possible to give reasoncodes why the auth or assoc was denied. Signed-off-by: Nick Hainke <vincent@systemli.org>
* hostapd: add support for turning on 802.11k/v features via ubusFelix Fietkau2018-02-211-0/+17
| | | | | | | Neighbor reports are enabled implicitly on use, beacon reports and BSS transition management need to be enabled explicitly Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: backport fix for wnm_sleep_mode=0Timo Sigurdsson2017-12-071-0/+35
| | | | | | | | | | | | | wpa_disable_eapol_key_retries can't prevent attacks against the Wireless Network Management (WNM) Sleep Mode handshake. Currently, hostapd processes WNM Sleep Mode requests from clients regardless of the setting wnm_sleep_mode. Backport Jouni Malinen's upstream patch 114f2830 in order to ignore such requests by clients when wnm_sleep_mode is disabled (which is the default). Signed-off-by: Timo Sigurdsson <public_timo.s@silentcreek.de> [rewrite commit subject (<= 50 characters), bump PKG_RELEASE] Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
* hostapd: rework frequency/ht/vht selection for ibss/meshFelix Fietkau2017-11-154-163/+24
| | | | | | | | | | - Remove obsolete patch chunks regarding fixed_freq - Instead of patching in custom HT40+/- parameters, use the standard config syntax as much as possible. - Use fixed_freq for mesh - Fix issues with disabling obss scan when using fixed_freq on mesh Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: set mcast_rate in mesh modeSven Eckelmann2017-11-151-0/+68
| | | | | | | | | | | | | | | | | | The wpa_supplicant code for IBSS allows to set the mcast rate. It is recommended to increase this value from 1 or 6 Mbit/s to something higher when using a mesh protocol on top which uses the multicast packet loss as indicator for the link quality. This setting was unfortunately not applied for mesh mode. But it would be beneficial when wpa_supplicant would behave similar to IBSS mode and set this argument during mesh join like authsae already does. At least it is helpful for companies/projects which are currently switching to 802.11s (without mesh_fwding and with mesh_ttl set to 1) as replacement for IBSS because newer drivers seem to support 802.11s but not IBSS anymore. Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com> Tested-by: Simon Wunderlich <simon.wunderlich@openmesh.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> [refresh]
* hostapd: refresh ubus patchFelix Fietkau2017-11-151-36/+18
| | | | Signed-off-by: Felix Fietkau <nbd@nbd.name>
* hostapd: fix up ubus supportJohn Crispin2017-10-251-18/+44
| | | | Signed-off-by: John Crispin <john@phrozen.org>
* hostapd: backport extra changes related to KRACKStijn Tintel2017-10-179-9/+442
| | | | | | | | While these changes are not included in the advisory, upstream encourages users to merge them. See http://lists.infradead.org/pipermail/hostap/2017-October/037989.html Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>