Fixes denial of service attack and buffer overflow against TLS 1.3
servers using session ticket resumption. When built with
--enable-session-ticket and making use of TLS 1.3 server code in
wolfSSL, there is the possibility of a malicious client to craft a
malformed second ClientHello packet that causes the server to crash.
This issue is limited to when using both --enable-session-ticket and TLS
1.3 on the server side. Users with TLS 1.3 servers, and having
--enable-session-ticket, should update to the latest version of wolfSSL.
Thanks to Max at Trail of Bits for the report and "LORIA, INRIA, France"
for research on tlspuffin.
Complete release notes https://github.com/wolfSSL/wolfssl/releases/tag/v5.5.1-stable
Fixes: CVE-2022-39173
Fixes: https://github.com/openwrt/luci/issues/5962
References: https://github.com/wolfSSL/wolfssl/issues/5629
Tested-by: Kien Truong <duckientruong@gmail.com>
Reported-by: Kien Truong <duckientruong@gmail.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit ec8fb542ec)
(cherry picked from commit ce59843662961049a28033077587cabdc5243b15)
This version fixes two vulnerabilities:
-CVE-2022-34293[high]: Potential for DTLS DoS attack
-[medium]: Ciphertext side channel attack on ECC and DH operations.
The patch fixing x86 aesni build has been merged upstream.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 9710fe70a6)
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit ade7c6db1e6c2c0c8d2338948c37cfa7429ebccc)
This is mostly a bug fix release, including two that were already
patched here:
- 300-fix-SSL_get_verify_result-regression.patch
- 400-wolfcrypt-src-port-devcrypto-devcrypto_aes.c-remove-.patch
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 73c1fe2890)
(cherry picked from commit 6f8db8fee3b7bd5cb8b1b2be59ee710a8f96860b)
Rename libwolfssl-cpu-crypto to libwolfsslcpu-crypto so that the
regular libwolfssl version comes first when running:
opkg install libwolfssl
Normally, if the package name matches the opkg parameter, that package
is preferred. However, for libraries, the ABI version string is
appended to the package official name, and the short name won't match.
Failing a name match, the candidate packages are sorted in alphabetical
order, and a dash will come before any number. So in order to prefer
the original library, the dash should be removed from the alternative
library.
Fixes: c3e7d86d2b (wolfssl: add libwolfssl-cpu-crypto package)
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit d08c9da43c)
Move CONFIG_PACKAGE_libwolfssl-benchmark from the top of
PKG_CONFIG_DEPENDS to after PKG_ABI_VERSION is set.
This avoids changing the ABI version hash whether the bnechmark package
package is selected or not.
Fixes: 05df135cac (wolfssl: Rebuild when libwolfssl-benchmark gets changes)
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 50d0b41b38)
libwolfssl-cpu-crypto is a variant of libwolfssl with support for
cryptographic CPU instructions on x86_64 and aarch64.
On aarch64, wolfSSL does not perform run-time detection, so the library
will crash when the AES functions are called. A preinst script attempts
to check for support by querying /proc/cpuinfo, if installed in a
running system. When building an image, the script will check the
DISTRIB_TARGET value in /etc/openwrt_release, and will abort
installation if target is bcm27xx.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit c3e7d86d2b)
This forces a rebuild of the wolfssl package when the
libwolfssl-benchmark OpenWrt package gets activated or deactivated.
Without this change the wolfssl build will fail when it compiled without
libwolfssl-benchmark before and it gets activated for the next build.
Fixes: 18fd12edb8 ("wolfssl: add benchmark utility")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 05df135cac)
Disable the usage of target specific CPU crypto instructions by default
to allow the package being shared again. Since WolfSSL does not offer
a stable ABI or a long term support version suitable for OpenWrt release
timeframes, we're forced to frequently update it which is greatly
complicated by the package being nonshared.
People who want or need CPU crypto instruction support can enable it in
menuconfig while building custom images for the few platforms that support
them.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
(cherry picked from commit 0063e3421d)
The armvirt target is also used to run OpenWrt in lxc on other targets
like a Raspberry Pi. If we set WOLFSSL_HAS_CPU_CRYPTO by default the
wolfssl binray is only working when the CPU supports the hardware crypto
extension.
Some targets like the Raspberry Pi do not support the ARM CPU crypto
extension, compile wolfssl without it by default. It is still possible
to activate it in custom builds.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit d1b5d17d03)
Apply an upstream patch that removes unnecessary CFLAGs, avoiding
generation of incompatible code.
Commit 0bd5367233 is reverted so the
accelerated version builds by default on x86_64.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 639419ec4f)
Without this, WOLFSSL_HAS_DH can be disabled even if WOLFSSL_HAS_WPAS is
enabled, resulting in an "Anonymous suite requires DH" error when trying
to compile wolfssl.
Signed-off-by: Pascal Ernster <git@hardfalcon.net>
Reviewed-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 21825af2da)
WolfSSL is crashing with an illegal opcode in some x86_64 CPUs that have
AES instructions but lack other extensions that are used by WolfSSL
when AES-NI is enabled.
Disable the option by default for now until the issue is properly fixed.
People can enable them in a custom build if they are sure it will work
for them.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 0bd5367233)
This enables AES & SHA CPU instructions for compatible armv8, and x86_64
architectures. Add this to the hardware acceleration choice, since they
can't be enabled at the same time.
The package was marked non-shared, since the arm CPUs may or may not
have crypto extensions enabled based on licensing; bcm27xx does not
enable them. There is no run-time detection of this for arm.
NOTE:
Should this be backported to a release branch, it must be done shortly
before a new minor release, because the change to nonshared will remove
libwolfssl from the shared packages, but the nonshared are only built in
a subsequent release!
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 0a2edc2714)
Enabling different hardware crypto acceleration should not change the
library ABI. Add them to PKG_CONFIG_DEPENDS after the ABI version hash
has been computed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 677774d445)
This is mostly a bug fix release, including two that were already
patched here:
- 300-fix-SSL_get_verify_result-regression.patch
- 400-wolfcrypt-src-port-devcrypto-devcrypto_aes.c-remove-.patch
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit 73c1fe2890)
This is trivial fix of a duplicate definition of 'int ret'.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit df622768da10f36ceeb20346b4c4ee4eb9a8a9ad)
Fixes two high-severity vulnerabilities:
- CVE-2022-25640: A TLS v1.3 server who requires mutual authentication
can be bypassed. If a malicious client does not send the
certificate_verify message a client can connect without presenting a
certificate even if the server requires one.
- CVE-2022-25638: A TLS v1.3 client attempting to authenticate a TLS
v1.3 server can have its certificate heck bypassed. If the sig_algo in
the certificate_verify message is different than the certificate
message checking may be bypassed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit e89f3e85eb)
Backport fix for API breakage of SSL_get_verify_result() introduced in
v5.1.1-stable. In v4.8.1-stable SSL_get_verify_result() used to return
X509_V_OK when used on LE powered sites or other sites utilizing
relaxed/alternative cert chain validation feature. After an update to
v5.1.1-stable that API calls started returning X509_V_ERR_INVALID_CA
error and thus rendered all such connection attempts imposible:
$ docker run -it openwrt/rootfs:x86_64-21.02.2 sh -c "wget https://letsencrypt.org"
Downloading 'https://letsencrypt.org'
Connecting to 18.159.128.50:443
Connection error: Invalid SSL certificate
Fixes: #9283
References: https://github.com/wolfSSL/wolfssl/issues/4879
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit b9251e3b40)
x509v3 SAN extension is required to generate a certificate compatible with
chromium-based web browsers (version >58)
It can be disabled via unsetting CONFIG_WOLFSSL_ALT_NAMES
Signed-off-by: Sergey V. Lobanov <sergey@lobanov.in>
(cherry picked from commit dfd695f4b9)
fixing linking error when --enable-devcrypto=yes
fixes: 7d92bb0509 wolfssl: update to 4.8.1-stable
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit be3e260f92)
It's the default anyway and this just looks confusing, as if it wasn't.
Switch to AUTORELEASE while at it.
The binary size is unchanged.
Signed-off-by: Andre Heider <a.heider@gmail.com>
(cherry picked from commit 7cb5af30f4)
This gates out anything that might introduce semantically frivolous jitter,
maximizing chance of identical object files.
The binary size shrinks by 8kb:
1244352 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f
1236160 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f
Signed-off-by: Andre Heider <a.heider@gmail.com>
(cherry picked from commit c76300707e)
Changes from 4.7.0:
Fix one high (OCSP verification issue) and two low vulnerabilities
Improve compatibility layer
Other improvements and fixes
For detailed changes refer to https://github.com/wolfSSL/wolfssl/releases
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit 7d92bb0509)
[Added patch to allow compilation with libtool 2.4]
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Backport upstream patch to fix build with GCC 10 on 32 x86 targets.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit 718a4f4780)
"Alternate certification chains, as oppossed to requiring full chain
validataion. Certificate validation behavior is relaxed, similar to
openssl and browsers. Only the peer certificate must validate to a trusted
certificate. Without this, all certificates sent by a peer must be
used in the trust chain or the connection will be rejected."
This fixes e.g. uclient-fetch and curl connecting to servers using a Let's
Encrypt certificate which are cross-signed by the now expired
DST Root CA X3, see [0].
This is the recommended solution from upstream [1].
The binary size increases by ~12.3kb:
1236160 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f
1248704 staging_dir/target-mipsel_24kc_musl/usr/lib/libwolfssl.so.4.8.1.39c36f2f
[0] https://github.com/openwrt/packages/issues/16674
[1] https://github.com/wolfSSL/wolfssl/issues/4443#issuecomment-934926793
Signed-off-by: Andre Heider <a.heider@gmail.com>
[bump PKG_RELEASE]
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 28d8e6a871)
Since commit 6467de5a8840 ("Randomize z ordinates in scalar
mult when timing resistant") wolfssl requires a RNG for an EC
key when the hardened built option is selected.
wc_ecc_set_rng is only available when built hardened, so there
is no safe way to install the RNG to the key regardless whether
or not wolfssl is compiled hardened.
Always export wc_ecc_set_rng so tools such as hostapd can install
RNG regardless of the built settings for wolfssl.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit ef9b103107)
Biggest fix for this version is CVE-2021-3336, which has already been
applied here. There are a couple of low severity security bug fixes as
well.
Three patches are no longer needed, and were removed; the one remaining
was refreshed.
This tool shows no ABI changes:
https://abi-laboratory.pro/index.php?view=objects_report&l=wolfssl&v1=4.6.0&v2=4.7.0
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
(cherry picked from commit d1dfb577f1)
This fixes the build on MIPS BE like ath25 and ath79 target.
We get this error message when linking libwolfssl:
mips-openwrt-linux-musl/bin/ld: /home/hauke/openwrt/openwrt/staging_dir/target-mips_mips32_musl/usr/lib/libwolfssl.so: unknown type [0x7000002a] section `.MIPS.abiflags'
mips-openwrt-linux-musl/bin/ld: /home/hauke/openwrt/openwrt/staging_dir/target-mips_mips32_musl/usr/lib/libwolfssl.so: unknown type [0x7000002a] section `.MIPS.abiflags'
mips-openwrt-linux-musl/bin/ld: skipping incompatible /home/hauke/openwrt/openwrt/staging_dir/target-mips_mips32_musl/usr/lib/libwolfssl.so when searching for -lwolfssl
mips-openwrt-linux-musl/bin/ld: cannot find -lwolfssl
collect2: error: ld returned 1 exit status
This reverts commit 2591c83b34.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This should fix CVE-2021-3336:
DoTls13CertificateVerify in tls13.c in wolfSSL through 4.6.0 does not
cease processing for certain anomalous peer behavior (sending an
ED22519, ED448, ECC, or RSA signature without the corresponding
certificate).
The patch is backported from the upstream wolfssl development branch.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes the following build problem in hostapd:
mipsel-openwrt-linux-musl/bin/ld: /builder/shared-workdir/build/tmp/ccN4Wwer.ltrans7.ltrans.o: in function `crypto_ec_point_add':
<artificial>:(.text.crypto_ec_point_add+0x170): undefined reference to `ecc_projective_add_point'
mipsel-openwrt-linux-musl/bin/ld: <artificial>:(.text.crypto_ec_point_add+0x18c): undefined reference to `ecc_map'
mipsel-openwrt-linux-musl/bin/ld: /builder/shared-workdir/build/tmp/ccN4Wwer.ltrans7.ltrans.o: in function `crypto_ec_point_to_bin':
<artificial>:(.text.crypto_ec_point_to_bin+0x40): undefined reference to `ecc_map'
Fixes: ba40da9045 ("wolfssl: Update to v4.6.0-stable")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This version fixes a large number of bugs, although no security
vulnerabilities are listed.
Full changelog at:
https://www.wolfssl.com/docs/wolfssl-changelog/
or, as part of the version's README.md:
https://github.com/wolfSSL/wolfssl/blob/v4.6.0-stable/README.md
Due a number of API additions, size increases from 374.7K to 408.8K for
arm_cortex_a9_vfpv3-d16. The ABI does not change from previous version.
Backported patches were removed; remaining patch was refreshed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This enables all OpenSSL API available. It is required to avoid some
silent failures, such as when performing client certificate validation.
Package size increases from 356.6K to 374.7K for
arm_cortex-a9_vfpv3-d16.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Tnis adds the --enable-lighty option to configure, enabling the minimum
API needed to run lighttpd, in the packages feed. Size increase is
about 120 bytes for arm_cortex-a9_vfpv3-d16.
While at it, speed up build by disabling crypt bench/test.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This fixes the following security problems:
* In earlier versions of wolfSSL there exists a potential man in the
middle attack on TLS 1.3 clients.
* Denial of service attack on TLS 1.3 servers from repetitively sending
ChangeCipherSpecs messages. (CVE-2020-12457)
* Potential cache timing attacks on public key operations in builds that
are not using SP (single precision). (CVE-2020-15309)
* When using SGX with EC scalar multiplication the possibility of side-
channel attacks are present.
* Leak of private key in the case that PEM format private keys are
bundled in with PEM certificates into a single file.
* During the handshake, clear application_data messages in epoch 0 are
processed and returned to the application.
Full changelog:
https://www.wolfssl.com/docs/wolfssl-changelog/
Fix a build error on big endian systems by backporting a pull request:
https://github.com/wolfSSL/wolfssl/pull/3255
The size of the ipk increases on mips BE by 1.4%
old:
libwolfssl24_4.4.0-stable-2_mips_24kc.ipk: 386246
new:
libwolfssl24_4.5.0-stable-1_mips_24kc.ipk: 391528
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
32-bit x86 fail to compile fast-math feature when compiled with frame
pointer, which uses a register used in a couple of inline asm functions.
Previous versions of wolfssl had this by default. Keeping an extra
register available may increase performance, so it's being restored for
all architectures.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This version adds many bugfixes, including a couple of security
vulnerabilities:
- For fast math (enabled by wpa_supplicant option), use a constant time
modular inverse when mapping to affine when operation involves a
private key - keygen, calc shared secret, sign.
- Change constant time and cache resistant ECC mulmod. Ensure points
being operated on change to make constant time.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>