5 Steps to Stop the Latest OpenSSL Vulnerabilities: CVE-2022-3602, CVE-2022-3786

Originally published by Sysdig.

Written by Michael Clark, Sysdig.

The OpenSSL Project team announced two HIGH severity vulnerabilities (CVE-2022-3602, CVE-2022-3786) on Oct. 25, which affect all OpenSSL v3 versions up to 3.0.6. These vulnerabilities are remediated in version 3.0.7, which was released Nov. 1. OpenSSL 1.X versions are unaffected by the vulnerabilities. CVE-2022-3602 was originally tagged as CRITICAL severity, but after a week of testing from several OpenSSL partner organizations, it was found that in the most common configurations and platforms, the bug is not plausibly exploitable. Therefore, OpenSSL downgraded the severity to HIGH.

The vulnerabilities fixed include two stack-based buffer overflows in the name constraint checking portion of X.509 certificate verification. According to the maintainers, it requires that a Certificate Authority (CA) signed a malicious certificate OR that the vulnerable application proceeds with certificate verification despite no path to a trusted issuer.

In a TLS Client configuration (aka mutual authentication), the vulnerability can be triggered when the client connects to a malicious server. In the TLS Server configuration, the bug can be reached if the server specifies Client Authentication and the client connects with a malicious certificate.

The main remotely reachable bug of note (CVE-2022-3602) involves an attacker crafting a malicious email address, which ends up overflowing 4 bytes on the stack with attacker-controlled data. Depending on the stack layout (which changes based on platform architecture and compiler used), this could be enough for an attacker to achieve a Denial of Service (DoS), but Remote Code Execution (RCE) is unlikely. As with the previous CVE, the most common combinations of compiler and platform were evaluated and it was found that the buffer that ends up being overflowed goes unused, which makes exploitation (RCE or DoS) impossible. In addition, most platforms have included stack-based buffer overflow protection through a variety of means since 1997. It should be understood that advanced attackers have done more with less, so patching is still important.

The other bug fixed in the patch, CVE-2022-3786, is also rated as HIGH, due to the fact that only the length of the overflow is attacker-controlled. It allows an attacker to overflow a buffer with an arbitrary number of “.” characters, and exposure to remote code execution is not expected on any platforms.

1. Discover vulnerable workloads and hosts

OpenSSL is a software library that provides cryptographic and secure communications capabilities to most of the software on the Internet. It is most well known for securing HTTP connections via Transport Layer Security (TLS) for software like Apache and NGINX. The OpenSSL library is ubiquitous and included with and used by many different applications, even if they do not use the network at all. If cryptography is involved, it is a good bet OpenSSL is being used.

As an example, an Apache server administrator can use the tool grep to see if TLS Client Authentication is enabled in their Apache config file(s). If the returned lines show SSLVerifyClient having status “require“, TLS Client Auth is enabled.

grep -n SSLVerifyClient <apache_config_file>
grep -n "SSLVerifyDepth 1" <apache_config_file>

Since OpenSSL can be everywhere, gaining full visibility can be a challenge. If you can’t see it, you can’t fix it.

In order to identify where OpenSSL is being used, your host and container environments need to be checked, both in the cloud and on-prem. The first step is to use manifest-based (aka SBOM) vulnerability management tools, which will provide a list of affected workloads and assets. It is important to remember agentless vulnerability management tools will have difficulty assessing on-premise environments, so they cannot be solely relied upon.

However, this will not be enough on its own as OpenSSL can be used by devices on your network, even those you don’t manage yourself. A traditional vulnerability scanner which can discover OpenSSL versions from these devices is highly recommended. Many incident response engagements are the result of these unmanaged devices going without critical patches.

2. Prioritize what is being used

After running the scan, you might end up with a very long list of affected workloads and hosts.

It won’t be possible to respond to them all in a reasonable amount of time, so the list needs to be reduced to what is actually critical to fix. Many packages may include OpenSSL but not actually use it. This can happen for a number of reasons, including being accidently left in or just a part of the application that you don’t use. Teams should leverage runtime insights (i.e., looking at loaded packages at runtime) to determine if the package is in-use. This can separate the wheat from the chaff by eliminating noise, and only focus on the ones actually running in production.

Now that the list is a much more manageable size, further prioritization can be accomplished by understanding which workloads are critical. By fusing container, cloud, and Kubernetes metadata in the report, it becomes easier to understand which workloads are important, such as production versus development. Any hosts or workloads that receive traffic from the Internet should also be at the top of the list. With this shorter list, making these decisions becomes even more manageable.

Sysdig analyzed all images with an impacted openssl version, and looked at how many are actually running in production.

Note: at the time of extracting this information, the install base of images containing the openssl 3.x branch was relatively small in comparison with other versions. These percentages may change as the 3.x branch gets widely adopted.

3. Remediate or mitigate the threat

In an ideal world, all applications using a vulnerability would be simple to fix and result in no issues. Sadly, this is not the world we live in … yet. Once the critical hosts and workloads have been identified, the teams responsible for them need to be involved in order to deploy a fix.

If it is in a container or its image, then the development team should be responsible for updating OpenSSL. There is a caveat, though. If OpenSSL is in the base image, like the OS, then a different team may be responsible. Metadata from the container runtime (CRI) or Kubernetes can simplify this process by allowing you to understand what the application is and which team may be responsible for its development directly from the report. If OpenSSL is present on a host, then the infrastructure team should be tasked to upgrade the package.

Immediate patching, even on critical systems, is not always possible as sometimes the new version breaks the application or causes other problems. In this case, it is best to try to mitigate the vulnerability.

The current recommended remediation from the OpenSSL project is to disable client TLS authentication until the libraries can be patched.

4. Detect and respond to any exploitation

While this exploitation of this vulnerability is most likely to manifest as a crash (Denial of Service), there is still a possibility of remote code execution. It would occur in the application doing the client TLS authentication, such as Apache. If successful, an attacker would gain access using the permissions of apache, which is usually an unprivileged account. From here, standard post-exploitation activities would occur to raise privileges and work towards their goal.

For threat detection information and rules, see these resources:

• Detecting and mitigating CVE-2022-42889 a.k.a. Text4shell
• Compromising read-only containers with fileless malware

5. Validate remediation is occuring

Remediating the OpenSSL vulnerability isn’t an atomic operation, it is a cycle. You will need to continually reassess the status of your environment using your vulnerability management tools to validate that applications and systems are being patched. How often this validation occurs depends on your vulnerability management policies and goals.

Scheduling a report to be run once per day is a good place to start. It will show the systems which are still vulnerable, while the remediated systems will have fallen off of the report. By leveraging runtime insights, any workloads which have just started to use a vulnerable version of OpenSSL will also be reported so they can be addressed without delay.

Conclusion

The OpenSSL vulnerabilities turned out not to be another Heartbleed situation, thankfully. However, exploits for bugs that researchers initially thought unexploitable have been released before. Therefore, it is still important and valuable to exercise the full vulnerability management process. Much like incident response and other disciplines, practice is an important part of dealing with vulnerabilities and can help reveal any gaps.