Today we published an advisory about CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) and CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”).

Please read the advisory for specific details about these CVEs and how they might impact you. This blog post will address some common questions that we expect to be asked about these CVEs.

Q: The 3.0.7 release was announced as fixing a CRITICAL vulnerability, but CVE-2022-3786 and CVE-2022-3602 are both HIGH. What happened to the CRITICAL vulnerability?

A: CVE-2022-3602 was originally assessed by the OpenSSL project as CRITICAL as it is an arbitrary 4-byte stack buffer overflow, and such vulnerabilities may lead to remote code execution (RCE).

During the week of prenotification, several organisations performed testing and gave us feedback on the issue, looking at the technical details of the overflow and stack layout on common architectures and platforms.

Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution.

Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.

However as OpenSSL is distributed as source code we have no way of knowing how every platform and compiler combination has arranged the buffers on the stack and therefore remote code execution may still be possible on some platforms.

Our security policy states that a vulnerability might be described as CRITICAL if “remote code execution is considered likely in common situations”. We no longer felt that this rating applied to CVE-2022-3602 and therefore it was downgraded on 1st November 2022 before being released to HIGH.

CVE-2022-3786 was NOT rated as CRITICAL from the outset, because only the length and not the content of the overwrite is attacker controlled. Exposure to remote code execution is not expected on any platforms.

We still consider these issues to be serious vulnerabilities and affected users are encouraged to upgrade as soon as possible.

Q: What should users do?

A: Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as possible. If you obtain your copy of OpenSSL from your Operating System vendor or other third party then you should seek to obtain an updated version from them as soon as possible.

Q: Does this impact releases prior to 3.0?

A: No, the bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). This code was first introduced in OpenSSL 3.0.0. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected.

We did release an update to OpenSSL 1.1.1, namely 1.1.1s, also on 1st November 2022, but this is a bug fix release only and does not include any security fixes.

Q: Are these issues being exploited in the wild?

A: We are not aware of any working exploit that could lead to remote code execution, and we have no evidence of these issues being exploited as of the time of release of this post.

Q: Does this impact the FIPS provider?

A: No, the FIPS provider is not impacted by these issues.

Q: Are all applications using OpenSSL 3.0 vulnerable by default?

A: Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. This includes TLS clients, and TLS servers that are configured to use TLS client authentication.

Q: Are there any mitigations until I can upgrade?

A: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied.

Q: Do I need to replace my TLS server certificates?

A: No

Q: What was the timeline of the reporting?

A: CVE-2022-3602 was reported in private to OpenSSL on 17th October 2022 by Polar Bear who was performing an audit of OpenSSL code. Subsequent analysis of that issue on 18th October 2022 by Viktor Dukhovni identified a second independently triggerable issue, CVE-2022-3786. On 25th October 2022 we notified various organisations under our Prenotification Policy. OpenSSL 3.0.7 that contains fixes for these issues was released on 1st November 2022.

Q: How many people/servers are affected?

A: The OpenSSL project does not track deployments, so we do not have statistics for this.

Q: What is the CVSS score?

A: The OpenSSL security team does not assign CVSS or similar vulnerability scores. Please see security policy issue severity

Q: Is this a branded vulnerability?

A: The OpenSSL project has not named or created logos for either CVE. The best way to refer to them is via the CVE names to avoid confusion.

Q: What version of OpenSSL should I be using?

A: New applications should be developed to use the latest version of OpenSSL 3.0 (currently 3.0.7). Existing applications using OpenSSL 3.0 should upgrade to 3.0.7 as soon as possible. Existing applications using OpenSSL 1.1.1 are not affected by these issues. However we always recommend using the latest version (1.1.1s). OpenSSL 1.1.1 is supported until 11th September 2023. Users of older versions of OpenSSL (such as 1.0.2) are encouraged to upgrade to OpenSSL 3.0. There was no release of OpenSSL 2.