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
