Since a straight version bump is not feasible, I'm applying a couple of cherry-picks of security fixes:
73076940a Fix CompareOcspReqResp f93083be7 OCSP: improve handling of OCSP no check extension (CVE-2021-38597) Also included in the series is a patch to build the library with the "Alternate certificate validation" option WOLFSSL_ALT_CERT_CHAINS, allowing uclient-fetch to connect to servers using the default Let's Encrypt chain that contains the certificate cross-signed by the expired DST Root CA X3 certificate. The original series was made when 4.8.1 was the current version in master. Since then, some more low-severity vulnerabilities were discovered: [1] - Issue with incorrectly validating a certificate that has multiple subject alternative names when given a name constraint. In the case where more than one subject alternative name is used in the certificate, previous versions of wolfSSL could incorrectly validate the certificate. Users verifying certificates with multiple alternative names and name constraints, are recommended to either use the certificate verify callback to check for this case or update the version of wolfSSL used. Fixed in 5.0.0. - Hang with DSA signature creation when a specific q value is used in a maliciously crafted key. If a DSA key with an invalid q value of either 1 or 0 was decoded and used for creating a signature, it would result in a hang in wolfSSL. Users that are creating signatures with DSA and are using keys supplied from an outside source are affected. Fixed in 5.0.0. - Client side session resumption issue once the session resumption cache has been filled up. The hijacking of a session resumption has been demonstrated so far with only non verified peer connections. That is where the client is not verifying the server’s CA that it is connecting to. There is the potential though for other cases involving proxies that are verifying the server to be at risk. - CVE-2021-44718: Potential for DoS attack on a wolfSSL client due to processing hello packets of the incorrect side. This affects only connections using TLS v1.2 or less that have also been compromised by a man in the middle attack. A CVE was reserved, but apparently not publicized yet. High-severity CVE-2022-23408 is not included because it affects versions 5.0.0 and 5.1.0 only. I've started to look at the first vulnerability, but it is not as straightforward as I was hoping. Perhaps Luiz Angelo Daros de Luca, reporter and author of the fixes, can help me out with this. Applying a large series of fixes may end up creating a new vulnerability if not done correctly, so we may need to consider the version bump again. The ABI version may create trouble for people running opkg update, but WolfSSL was not the core TLS library in 19.07 yet. Nonetheless, this series includes the one high-severity vulnerability (according to wolfssl [1]) CV-2021-38597, and can be applied before we decide what to do next. Cheers, Eneas --- v2: - Apply two security patches instead of bumping to 4.8.1 - Added patch to build with alternate certificate validation [1] https://www.wolfssl.com/docs/security-vulnerabilities/ Andre Heider (1): wolfssl: build with WOLFSSL_ALT_CERT_CHAINS Eneas U de Queiroz (2): wolfssl: Fix OCSP request/response verification wolfssl: Fix CVE-2021-38597 package/libs/wolfssl/Makefile | 8 +- .../patches/200-Fix-CompareOcspReqResp.patch | 224 ++++++++++++++++++ ...-handling-of-OCSP-no-check-extension.patch | 49 ++++ 3 files changed, 279 insertions(+), 2 deletions(-) create mode 100644 package/libs/wolfssl/patches/200-Fix-CompareOcspReqResp.patch create mode 100644 package/libs/wolfssl/patches/210-OCSP-improve-handling-of-OCSP-no-check-extension.patch _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel