OpenSSL CVE-2022-3786 and CVE-2022-3602 or "The Critical that wasn't"

First, if all you want to know is whether or not F5 products are vulnerable to CVE-2022-3786 or CVE-2022-3602, I will direct you to our Security Advisory: https://support.f5.com/csp/article/K44030142

If you want, though, stick around for a slightly deeper look into how the announcement went and my feelings on the vulnerabilities (in deployments other than F5 products).

A little history, then

OpenSSL performed a pre-announcement on October 25th, warning users that a patch version (3.0.7) would soon be released to fix a Critical vulnerability; this got a lot of people very excited, and understandably so - this would be only the second critical vulnerability announced by OpenSSL and the first in six years (the first being CVE-2016-6309) - and the assumption everyone began working on was that this could be as bad as Heartbleed, resulting in OpenSSL leaking memory contents to an attacker.

Unfortunately for us, we were working on the same information as everyone else - just what was made public - and so despite the interest the announcement generated, and the number of questions we started receiving, we couldn't put together a great answer across our product range ahead of time.

A clarification was made after the initial notification, stating that the vulnerability to be disclosed only affected OpenSSL 3.x, and from that point on we knew that we should be in good shape - the majority of F5 products are running older versions (largely due to certification requirements like FIPS) and so shouldn't be affected. Of course, we didn't want to jump the gun and announce to the world that we were not vulnerable until we were in receipt of all the facts, and so our Security Advisory went up stating that all products were under investigation.

When the vulnerabilities were actually announced on November 1st we were all slightly surprised to find out that the Critical vulnerability had, in fact, become two High severity vulnerabilities. Neither vulnerability could directly leak server memory (unlike Heartbleed) but both could result in a crash and one could potentially result in remote code execution (unproven at the time of writing this blog). That, plus factors I will go into below, serve to significantly reduce the potential impact, risk and response required and, had we known all of that on October 25th, there probably wouldn't have been quite so much abject panic and conjecture on the Internet..

So, was a pre-announcement a good idea?

It was unforunate that the severity was initially determined to be Critical and then down-graded for the public announcement, but on balance I think OpenSSL did the right thing in notifying the public that a vulnerability was coming, when the patch would be available and, at least broadly speaking, which version(s) would be impacted.

That detail allowed organisations to at least take a stab at determining their exposure; if they were running only versions prior to 3.x then they knew they were safe (and could stand down response teams) while if they had any 3.x in their estate they knew they would need to have a patch window open on November 1st and be ready to deploy patches, or at the very least inspect configurations.

The approach does, undeniably, cause some problems for vendors and system integrators who consume OpenSSL libraries, though - as I noted above, we were faced with some unanswerable questions which is always a difficult position to be put in.

What are the vulnerabilities?

The authoritative source of information here is, of course, the OpenSSL advisory: https://www.openssl.org/news/secadv/20221101.txt

To dive into the details a little:

CVE-2022-3602 is a buffer overflow which can be triggered during X.509 Certificate verification using a maliciously constructed certificate. Mitigating the risk here is the fact that the certificate chain must already have passed verification - in other words, the malicious certificate needs to have been signed by a legitimate Certificate Authority or for the application to trust certificates it cannot verify the CA chain for (rather like running 'curl -k').

Exploitation allows an attacker to overflow four bytes into the stack which would most likely lead to a crash but could, theoretically, allow remote code execution.

The most obvious threat here is to clients - where certificates are always verified (your browser, for example, has already verified the authenticity of the certificate presented by devcentral.f5.com) - but there is a potential exposure to servers if you have configured client certificate authentication.

Again, I must call out that this does not impact BIG-IP products performing client certificate authentication either for the control-plane (TMUI) or data-plane (virtual servers) regardless of configuration.

CVE-2022-3786 is almost identical to CVE-2022-3602; it shares all of the same constraints, affected configurations, and is present in the same area of code. The difference here is that the attacker can place an arbitrary number of bytes onto the stack but those bytes will all contain the '.' character. Exploitation of this bug can (as far as we are aware) only result in a crash - there is no possibility of arbitrary code execution because the bytes overflowed are always '.'.

How likely is this to be exploited?

This is entirely opinion (although others do share the same opinion, at least, like Marcus Hutchins at MalwareTech), but I don't think you are going to see large-scale weaponisation of either bug, or any kind of exploitation at scale.

Both bugs are hard to exploit (requiring either very specific application configuration or a signed, valid certificate) and result in very little gain for an attacker - either crashing a single browser thread in the case of a client side attack, or (most likely) a single server thread in the case of a server attack. It's unlikely an attacker would be able to carry out a complete denial of service against a server even given the required configuration (client certificate authentication) and even less likely that they could carry out anything more interesting by using CVE-2022-3602 to deliver arbitrary code.

How likely is it that I am affected?

Again, if you are using F5 software, very unlikely - double check our advisory to be sure, of course.

If you are using another piece of software then the likelihood is still reasonably small; OpenSSL 3.0.0 only shipped in late 2021 and most systems are very likely still running 1.0.x or 1.1.x releases which are unaffected by these bugs. Completely determining your exposure, in the absence of a Software Bill of Materials for every piece of software you use, is a little tricky, but the MalwareTech blog I linked to above has some great scripts and steps you can run across systems (Windows and Linux) to at least try and see if any OpenSSL 3.x libraries are being used in the software you have installed in your estate.

For other vendor software it is also worth checking out the National Cyber Security Centre of the Netherlands (NCSC-NL) documentation to see if the software you are using is listed and/or affected: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software

Summary

Updated Nov 02, 2022
Version 3.0
F5 SIRT
security

Was this article helpful?

No CommentsBe the first to comment