Effect of OpenSSL & Apache Tomcat vulnerabilities on Codegic PKI products
For some of you who might had thought that the Log4j issue was the last major vulnerability for this year, now here we have both OpenSSL and Apache Tomcat vulnerabilities creating concerns in security world. First we have Apache Tomcat where end of September 2022 a security weakness was found (CVE-2021-43980) allowing Apache tomcat to send responses to the wrong client. Severity of this issue is LOW due to fact that it is quite hard to exploit this issue. Nevertheless Apache community has provided a fix for this. Just recently OpenSSL is also reported to have even more severe issues where start of November two security vulnerabilities were raised termed as CVE-2022-3786 & CVE-2022-3602. Both are related to create buffer overflow and could crash OpenSSL. The first one (CVE-2022-3786) could also allow remote code execution creating more harm.
Apache Tomcat Mitigation
Users of the affected versions should apply one of the following mitigations:
- Upgrade to Apache Tomcat 10.1.0-M14 or later once released
- Upgrade to Apache Tomcat 10.0.20 or later once released
- Upgrade to Apache Tomcat 9.0.62 or later once released
- Upgrade to Apache Tomcat 8.5.78 or later once released
- Note 10.1.0-M13, 10.0.19 and 9.0.61 were not released
OpenSSL Mitigation
These issues are fixed in OpenSSL 3.0.7 (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6).
Apache Tomcat vulnerability - CVE-2021-43980
The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug in Apache Tomcat 10.1.0 to 10.1.0-M12, 10.0.0-M1 to 10.0.18, 9.0.0-M1 to 9.0.60 and 8.5.0 to 8.5.77 that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2021-43980#vulnCurrentDescriptionTitle
OpenSSL vulnerability - CVE-2022-3786
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-3786
OpenSSL vulnerability - CVE-2022-3602 (Currently being analyzed by security analysts)
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.’ character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.
Codegic Response
None of our products rely on OpenSSL hence this issue does not relate to Codegic PKI products. We do rely on Apache Tomcat webserver and although the severity of the reported vulnerability is LOW we are still providing the upgraded product versions using the latest Apache Tomcat. This will ensure that our clients will keep on using the best-in-class security products avoiding any room to malicious actors.