On 25th October 2022 we notified various organisations under our Prenotification Policy. Subsequent analysis of that issue on 18th October 2022 by Viktor Dukhovni identified a second independently triggerable issue, CVE-2022-3786. Q: What was the timeline of the reporting?Ī: CVE-2022-3602 was reported in private to OpenSSL on 17th October 2022 by Polar Bear who was performing an audit of OpenSSL code. Q: Do I need to replace my TLS server certificates? Q: Are there any mitigations until I can upgrade?Ī: Users operating TLS servers may consider disabling TLS client authentication, if it is being used, until fixes are applied. This includes TLS clients, and TLS servers that are configured to use TLS client authentication. Q: Are all applications using OpenSSL 3.0 vulnerable by default?Ī: Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable. Q: Are these issues being exploited in the wild?Ī: We are not aware of any working exploit that could lead to remote code execution,Īnd we have no evidence of these issues being exploited as of the time ofĪ: No, the FIPS provider is not impacted by these issues. 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. OpenSSL 1.0.2, 1.1.1 and other earlier versions are not affected. This code was first introduced in OpenSSL 3.0.0. Q: Does this impact releases prior to 3.0?Ī: No, the bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates). Or other third party then you should seek to obtain an updated version from them If you obtain your copy of OpenSSL from your Operating System vendor We still consider these issues to be serious vulnerabilities and affected usersĪre encouraged to upgrade as soon as possible.Ī: Users of OpenSSL 3.0.0 - 3.0.6 are encouraged to upgrade to 3.0.7 as soon as Exposure to remote code execution is not expected on any platforms. This rating applied to CVE-2022-3602 and therefore it was downgraded on 1st November 2022 before being released to HIGH.ĬVE-2022-3786 was NOT rated as CRITICAL from the outset, because only the length and not the content of the overwrite is attacker controlled. States that a vulnerability might be described as CRITICAL if “remote codeĮxecution is considered likely in common situations”. 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. Secondly, many modern platforms implement stack overflow protections which would mitigateĪgainst the risk of remote code execution and usually lead to a crash instead. What happened to the CRITICAL vulnerability?Ī: 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).ĭuring 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.įirstly, 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. Q: The 3.0.7 release was announced as fixing a CRITICAL vulnerability, but CVE-2022-3786 and CVE-2022-3602 are both HIGH. This blog post will address some common questions that we Please read the advisory for specific details about these CVEs and how they (“X.509 Email Address Variable Length Buffer Overflow”) andĬVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |