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

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)

zlib: backport fix for heap-based buffer over-read (CVE-2022-37434)

2022-08-08T08:00:39Z

zlib through 1.2.12 has a heap-based buffer over-read or buffer overflow in inflate in inflate.c via a large gzip header extra field. NOTE: only applications that call inflateGetHeader are affected. Some common applications bundle the affected zlib source code but may be unable to call inflateGetHeader. Fixes: CVE-2022-37434 References: https://github.com/ivd38/zlib_overflow Signed-off-by: Petr Štetiar (cherry picked from commit 7df6795d4c25447683fd4b4a4813bebcddaea547)

openssl: bump to 1.1.1q

2022-07-17T12:27:41Z

Changes between 1.1.1p and 1.1.1q [5 Jul 2022] *) AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation would not encrypt the entirety of the data under some circumstances. This could reveal sixteen bytes of data that was preexisting in the memory that wasn't written. In the special case of "in place" encryption, sixteen bytes of the plaintext would be revealed. Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected. (CVE-2022-2097) [Alex Chernyakhovsky, David Benjamin, Alejandro Sedeño] Signed-off-by: Dustin Lundquist (cherry picked from commit 3899f68b54b31de4b4fef4f575f7ea56dc93d965)

openssl: bump to 1.1.1p

2022-07-15T13:52:13Z

Changes between 1.1.1o and 1.1.1p [21 Jun 2022] *) In addition to the c_rehash shell command injection identified in CVE-2022-1292, further bugs where the c_rehash script does not properly sanitise shell metacharacters to prevent command injection have been fixed. When the CVE-2022-1292 was fixed it was not discovered that there are other places in the script where the file names of certificates being hashed were possibly passed to a command executed through the shell. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. (CVE-2022-2068) [Daniel Fiala, Tomáš Mráz] *) When OpenSSL TLS client is connecting without any supported elliptic curves and TLS-1.3 protocol is disabled the connection will no longer fail if a ciphersuite that does not use a key exchange based on elliptic curves can be negotiated. [Tomáš Mráz] Signed-off-by: Andre Heider (cherry picked from commit eb7d2abbf06f0a3fe700df5dc6b57ee90016f1f1)