staging/pepe2k/package/libs, branch v21.02.6

openssl: bump to 1.1.1t

2023-02-18T15:16:44Z

Changes between 1.1.1s and 1.1.1t [7 Feb 2023] *) Fixed X.400 address type confusion in X.509 GeneralName. There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This vulnerability may allow an attacker who can provide a certificate chain and CRL (neither of which need have a valid signature) to pass arbitrary pointers to a memcmp call, creating a possible read primitive, subject to some constraints. Refer to the advisory for more information. Thanks to David Benjamin for discovering this issue. (CVE-2023-0286) This issue has been fixed by changing the public header file definition of GENERAL_NAME so that x400Address reflects the implementation. It was not possible for any existing application to successfully use the existing definition; however, if any application references the x400Address field (e.g. in dead code), note that the type of this field has changed. There is no ABI change. [Hugo Landau] *) Fixed Use-after-free following BIO_new_NDEF. The public API function BIO_new_NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO_f_asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. (CVE-2023-0215) [Viktor Dukhovni, Matt Caswell] *) Fixed Double free after calling PEM_read_bio_ex. The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload data. If the function succeeds then the "name_out", "header" and "data" arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. (CVE-2022-4450) [Kurt Roeckx, Matt Caswell] *) Fixed Timing Oracle in RSA Decryption. A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. (CVE-2022-4304) [Dmitry Belyavsky, Hubert Kario] Signed-off-by: John Audia (cherry picked from commit 4ae86b3358a149a17411657b12103ccebfbdb11b) The original commit removed the upstreamed patch 010-padlock.patch, but it's not on OpenWrt 21.02, so it doesn't have to be removed. Signed-off-by: Michal Vasilek

wolfssl: update to v5.5.3

2022-11-27T15:36:53Z

Remove "200-ecc-rng.patch" because it was upstramed by: https://github.com/wolfSSL/wolfssl/commit/e2566bab2122949a6a0bb2276d0a52598794d7d0 Refreshed "100-disable-hardening-check.patch". Fixes CVE 2022-42905. Release Notes: - https://github.com/wolfSSL/wolfssl/releases/tag/v5.5.2-stable - https://github.com/wolfSSL/wolfssl/releases/tag/v5.5.3-stable Signed-off-by: Nick Hainke (cherry picked from commit 745f1ca9767716c43864a2b7a43ed60b16c25560)

openssl: bump to 1.1.1s

2022-11-27T13:04:37Z

Changes between 1.1.1r and 1.1.1s [1 Nov 2022] *) Fixed a regression introduced in 1.1.1r version not refreshing the certificate data to be signed before signing the certificate. [Gibeom Gwon] Changes between 1.1.1q and 1.1.1r [11 Oct 2022] *) Fixed the linux-mips64 Configure target which was missing the SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that platform. [Adam Joseph] *) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was causing incorrect results in some cases as a result. [Paul Dale] *) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to report correct results in some cases [Matt Caswell] *) Fixed a regression introduced in 1.1.1o for re-signing certificates with different key sizes [Todd Short] *) Added the loongarch64 target [Shi Pujin] *) Fixed a DRBG seed propagation thread safety issue [Bernd Edlinger] *) Fixed a memory leak in tls13_generate_secret [Bernd Edlinger] *) Fixed reported performance degradation on aarch64. Restored the implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid 32-bit lane assignment in CTR mode") for 64bit targets only, since it is reportedly 2-17% slower and the silicon errata only affects 32bit targets. The new algorithm is still used for 32 bit targets. [Bernd Edlinger] *) Added a missing header for memcmp that caused compilation failure on some platforms [Gregor Jasny] Build system: x86_64 Build-tested: bcm2711/RPi4B Run-tested: bcm2711/RPi4B Signed-off-by: John Audia (cherry picked from commit a0814f04ed955eb10b25df0ce6666ed91f11ca1b)

treewide: fix security issues by bumping all packages using libwolfssl

2022-10-05T19:09:50Z

As wolfSSL is having hard time maintaining ABI compatibility between releases, we need to manually force rebuild of packages depending on libwolfssl and thus force their upgrade. Otherwise due to the ABI handling we would endup with possibly two libwolfssl libraries in the system, including the patched libwolfssl-5.5.1, but still have vulnerable services running using the vulnerable libwolfssl-5.4.0. So in order to propagate update of libwolfssl to latest stable release done in commit ec8fb542ec3e4 ("wolfssl: fix TLSv1.3 RCE in uhttpd by using 5.5.1-stable (CVE-2022-39173)") which fixes several remotely exploitable vulnerabilities, we need to bump PKG_RELEASE of all packages using wolfSSL library. Signed-off-by: Petr Štetiar (cherry picked from commit f1b7e1434f66a3cb09cb9e70b40add354a22e458) (cherry picked from commit 562894b39da381264a34ce31e9334c8a036fa139)

wolfssl: fix TLSv1.3 RCE in uhttpd by using 5.5.1-stable (CVE-2022-39173)

2022-10-05T19:09:48Z

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 Reported-by: Kien Truong Signed-off-by: Petr Štetiar (cherry picked from commit ec8fb542ec3e4f584444a97de5ac05dbc2a9cde5) (cherry picked from commit ce59843662961049a28033077587cabdc5243b15)

wolfssl: bump to 5.5.0

2022-10-05T19:09:47Z

Remove upstreamed: 101-update-sp_rand_prime-s-preprocessor-gating-to-match.patch Some low severity vulnerabilities fixed OpenVPN compatibility fixed (broken in 5.4.0) Other fixes && improvements Signed-off-by: Ivan Pavlov (cherry picked from commit 3d88f26d74f7771b808082cef541ed8286c40491) (cherry picked from commit 0c8425bf11590afb0c6f1545b328ecb6ed4aee87)

wolfssl: bump to 5.4.0

2022-10-05T19:09:46Z

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 (cherry picked from commit 9710fe70a68e0a004b1906db192d7a6c8f810ac5) Signed-off-by: Christian Marangi (cherry picked from commit ade7c6db1e6c2c0c8d2338948c37cfa7429ebccc)

wolfssl: bump to v5.3.0-stable

2022-10-05T19:07:49Z

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 (cherry picked from commit 73c1fe2890baa5c0bfa46f53c5387f5e47de1acb) (cherry picked from commit 6f8db8fee3b7bd5cb8b1b2be59ee710a8f96860b)

uclibc++: fix compilation with long file paths

2022-08-28T05:53:56Z

Currently, uClic++ 0.2.5 fails to compile when using a long filepath. For example, if the openwrt directory is in the path: /tmp/this_directory_name_is_very_long/more_long_paths/.../openwrt, then uclibc++ will cause a very obtuse error. Although the uclibc++ makefiles do print a "File name too long" error, it's not the final error that's printed, so it's a bit confusing: > /bin/sh: 1: > cannot create src/abi/libsupc/_libsupc++.a.dep: File name too long > > array_type_info.o: No such file or directory Although OpenWRT 22.03 and current master branch have removed uClib++, I thought I'd make a PR for OpenWRT 21.02, since I encountered it and there seems to be quite a few other people experiencing the same issue. It especially happens when using the SDK, (or when using an encrypted fs) since the pre-packaged SDKs have very long filenames. This patch is already in upstream [1], but has not yet been released. [1]: https://git.busybox.net/uClibc++/commit/?id=6687fc9276fa52defaf8592f2001c19b826aec93 Signed-off-by: Alois Klink

zlib: backport null dereference fix

2022-08-09T06:15:26Z

The curl developers found test case that crashed in their testing when using zlib patched against CVE-2022-37434, same patch we've backported in commit 7df6795d4c25 ("zlib: backport fix for heap-based buffer over-read (CVE-2022-37434)"). So we need to backport following patch in order to fix issue introduced in that previous CVE-2022-37434 fix. References: https://github.com/curl/curl/issues/9271 Fixes: 7df6795d4c25 ("zlib: backport fix for heap-based buffer over-read (CVE-2022-37434)") Signed-off-by: Petr Štetiar (cherry picked from commit f443e9de7003c00a935b9ea12f168e09e83b48cd) (cherry picked from commit 707ec48ab3db6d08bd022df1bc720aee68b3b99d)