Discover more from PwnAllTheThings
If you’re in the weeds in cybersecurity, you’ll have heard over the past few days that there’s a critical OpenSSL vulnerability that needs to be patched. The details themselves were embargoed by widely expected to be listed as “critical”, leading to lots of speculation as to how bad the bug was, and cybersecurity teams scrambling to scan for vulnerable programs and prepare for an emergency patch.
Well, here we go. The details are out as CVE-2022-3786 and CVE-2022-3602. Unexpectedly both are now downrated to “high” severity.
OpenSSL also has an FAQ on the two bugs with some additional details.
So what’s this all about?
Vulnerable versions
The vulnerabilities affect OpenSSL versions 3.0.0 through 3.0.6 inclusive.
Programs and systems using these versions of OpenSSL should upgrade to 3.0.7.
If you are a system administrator and want to check your system and programs, you can use the tools and commands provided over at MalwareTech.com.
If you’re a normal user, there is not a lot for you to do, other than ensure that you regularly install updates when prompted by your software to do so.
Is it being exploited in the wild?
Not that anyone currently knows of.
The good news is that many routes to exploitation of these vulnerabilities are noisy, and will be relatively detectable. Detection may come from:
Public certificate transparency logs at public certificate authorities may detect use of malicious public CA-signed certificates
Private federated certificate authority logs inside large companies may detect use of private federated CA-signed certificates
Network security devices may detect malicious certificates traversing the network
On-device security software may detect malicious certificates arriving on a server.
Companies that do make heavy internal use of mutual TLS authentication are more at risk than others, particularly if they use unmonitored permissive private federated certificate authorities to manage certificates.
Affected software
A large (but necessarily incomplete) list of programs making use of vulnerable versions of OpenSSL can be found here.
The vulnerabilities
CVE-2022-3786 is a linear stack overflow vulnerability that occurs when parsing a TLS certificate after validation. This is a 4-byte overflow of a fixed stack buffer, with attacker control over the content of the four bytes.
CVE-2022-3786 is also a linear stack overflow vulnerability that occurs when parsing a TLS certificate after validation. This vulnerability however allows an attacker to choose how many bytes to overflow, but not the content of the overflow, which will always be the period (‘.’) character.
In both cases, these are linear stack overflow vulnerabilities. In the worst case, these could allow an attacker to take full control over the running program, and from there, usually the whole device. That’s why these two vulnerabilities are rated as “high” by OpenSSL.
That said, the exact exploitability of the vulnerability is very context dependent. It depends on the exact processor architecture, compiler, compiler version, and compiler options as to whether a program using a vulnerable version of OpenSSL will actually be exploitable.
If the program has no basic compiler anti-exploit mitigations enabled and is also unlucky, it will be potentially exploitable with a worst-case scenario of system compromise. If the program is compiled with basic anti-exploit mitigations enabled (or is lucky) the attacker will only be able to use the vulnerably to force the TLS client or server to crash, potentially causing a denial of service condition.
Triggering either bug requires a TLS certificate
In both vulnerabilities, the bug is only reachable after certificate validation. In other words, the attacker will normally need to generate a malformed certificate and have it signed by a Certificate Authority the machine trusts in order to trigger the vulnerability at all.
Certificate Authorities (CAs) come in one of two flavors: public CAs and corporate CAs (federated private CAs).
Public Certificate Authorities are the big certificate companies on which most of the public internet relies—companies like LetsEncrypt or VeriSign. If an attacker wants a public certificate, they’ll need to create a malformed certificate request and get it signed by one of these big companies. That not only gives the CAs an opportunity to proactively and centrally deny the request, but also leaves a public audit trail for the CAs who operate public certificate transparency logs.
Companies that operate private federated CAs, such as big firms, governments and datacenters, might also run into problems with malicious certificates signed by the federated CA. Those certificates will be trusted only within that federated domain. These federated domains tend to be comparatively weakly managed, often with comparatively little validation or transparency of the certificates issued.
A second case also exists: some (very brave) programs will process the certificate even if the certificate validation hasn’t succeeded. In that case, the attacker won’t necessarily need a valid CA signature. This is a rare scenario, because one of TLS’ core functions is to provide a secure authenticated channel between two computers, and engineers normally have no reason to try and manually override any part of the TLS authentication mechanism via code. Even so, it’s worth calling out that there are circumstances where the bug is reachable without a valid CA signature on the certificate, but it will likely be a small fraction of the overall software running the vulnerable versions.
Does this affect TLS servers?
Sometimes. Though it will be rare for HTTPS servers.
When a TLS client connects out to a TLS server, the default mode of operation is that the TLS server sends a TLS certificate as part of the set up of the encrypted channel. Once the TLS client knows the TLS server is legit, it can use its encrypted channel to send authentication information (like a password) to the TLS server directly. TLS servers don’t need a certificate from the client in order to form secure communication channels.
If your TLS server is configured in this (default) way—as the overwhelming majority of HTTPS servers are, for example—the TLS server never handles untrusted certificates from remote clients. The bug won’t be reachable, and so the program won’t be directly at risk from this vulnerability.
It is, however, possible to perform bi-direction authentication where both sides send each other certificates to validate the connection at both ends of the TLS layer itself. This is called mutual authentication. In this case, the TLS server will receive and handle a TLS certificate from the remote client. If that is a malformed certificate, the TLS server may be compromised, and patching is more important than for other TLS servers.
Does this affect TLS clients?
Yes.
In TLS, the client will always receive and process a TLS certificate from the server as part of the connection. If the server is malicious—either because the server itself was hacked, or because the attacker tricked the client into connecting to an attacker machine—then the TLS client will potentially be vulnerable to this code path.
While TLS clients are vulnerable, it does require connecting to an attacker’s TLS server (or the attacker first compromising the TLS server). This makes exploitation somewhat harder than would otherwise be the case with TLS servers, where mass-scanning and exploitation would otherwise be possible.
The vulnerabilities will be very hard to exploit
In both of these vulnerabilities, the underlying error is a linear stack overflow. This occurs because a fixed region of memory on the stack is allocated to hold data to write into, but the attacker can trick the program into writing past the end of this allocation, overwriting data intended for other purposes, corrupting that data.
The impact of the vulnerability therefore depends on what exactly is stored immediately after the vulnerable stack buffer. What exactly that is heavily dependent on how the program is compiled. It will change depending on which compiler is used, which version, what compiler options are specified, and what computer architecture (e.g. Intel or Arm) the program is being compiled for.
The OpenSSL community produces code, not program binaries, so here their “high” rating is based on the worst-case (rather than likely or best-case) scenario of how the program is compiled. But this means that the possibility of exploitation will itself be very target dependent.
If the exploit writer is lucky, the vulnerable OpenSSL code will be in a program compiled with no modern anti-exploit protection mechanisms enabled, and will be able to use the vulnerability to control some or all of a function return address, or other critical program data. That will allow them to surgically reorient program flow to run attacker-chosen instructions in an attacker-chosen sequence. In other words, to run the attacker’s program instead, taking full control of the vulnerable machine.
In programs that make use of the vulnerable OpenSSL code but are compiled with even basic anti-exploit protection mechanisms (in particular, stack canaries) the linear buffer overflow will corrupt a special guarded value, triggering a program abort. In this case, the attacker may be able to use the vulnerability to perform a denial of service attack on the vulnerable program, but not to fully compromise it.
From the OpenSSL FAQ, it appears that several organizations performed analysis on the vulnerabilities prior to disclosure and determined that usually stack protections are enabled, and even when they are not, the linear stack buffer overflow usually does not corrupt security-sensitive data. Even so, that doesn’t mean it never will. The only way to be sure is to take the time to upgrade and, while you’re at it, make sure programs use basic compiler security mitigations.
How worried should I be?
My view is that the circumstances and complexity of exploitation here will make this a relatively unattractive exploit for attackers to target. Companies should, of course, update vulnerable software. But exploitation will be costly and program-specific, if it takes place at all.
Internet-facing TLS servers running the vulnerable software versions that perform mutual authentication should be upgraded relatively quickly, as should mutual-authentication servers within datacenters, but otherwise cybersecurity folks should be careful not to over-emphasize these vulnerabilities to the exclusion of other, more immediate threats. Attackers will likely have better avenues to gain access.
Companies that do scan for programs making use of the vulnerable OpenSSL versions should request their respective vendors not just to release an updated version, but also insist that vendors compile new versions with compiler mitigations such as stack canaries, address space layout randomization and control flow integrity checks enabled. Vulnerabilities like this are substantially (if not always totally) mitigated through use of these mitigations, and they are nearly free for vendors to implement. Insisting on this now will protect against many future vulnerabilities of the same category, improving cybersecurity across the whole program.
Is OpenSSL wide open?
🫡🤯