What you need to know about the latest critical OpenSSL vulnerability
October 28, 2022
OpenSSL is an open source project that powers most of the security communications and cryptography on the internet. It’s one of those critical projects that you don’t hear much about…unless there’s a problem.
On Tuesday, 1-Nov-2022, the project released version 3.0.7 to address two high severity vulnerabilities. CVE-2022-3602 and CVE-2022-3786.
How bad is the issue?
The original heads up from the OpenSSL project was that this issue would be a critical severity. The highest possible rating. Upon review with several organizations, the project has downgraded the issue to a high level severity.
This is still important to address but is not a worst case scenario.
The project explains the reasons for downgrading in their blog post supporting this issue. The good news is that testing showed the likelihood of remote code execution was much lower than initially expected. That justified downgrading the vulnerability.
The bad news? Both of the reported issues can cause a buffer overflow which could result in a system crash. This could result in a denial of service attack.
What is the issue?
The OpenSSL change log has the specific details but the two vulnerabilities are very similar. Both occur when OpenSSL validates X.509 certificates.
When you’re creating a secure connection between systems, these certificates are used to help identify the systems and to exchange the keys used to secure the connection.
There’s a lot of complexity in the system, but in the simplest terms, certificates are verified using a chain of trust. A known and trusted third party that says, “Yes, certificate A is in fact Alice’s certificate. And certificate B is in fact Bob’s.”
It’s during this validation process that these vulnerabilities occur. If an attacker uses a maliciously crafted email address, a bug in OpenSSL 3.0.0—3.0.6 will fail to process it correctly leading to a buffer overflow…writing to memory the program shouldn’t.
For CVE-2022-3602, the result is that the attacker can write whatever they want to 4 bytes of memory on your system. If anything, that will most often result in a crash. There is an outside chance that it could allow the attacker to run their code on your system (remote code execution), but that’s highly unlikely and why the OpenSSL project downgraded the severity rating.
For CVE-2022-3786, reading that malicious email address in the certificate allows the attacker to force the system to write an arbitrary amount of bytes in memory. The attacker does not control what is written to memory which is why the result is most likely a system crash.
How widespread is this?
It has been confirmed that this vulnerability affects OpenSSL version 3.0.0 through 3.0.6. Earlier versions are not impacted.
This means any Linux distribution or server software using the latest versions will be impacted. OpenSSL 3.0.0 was released in September of 2021, so old systems may not be impacted.
The SANS Internet Storm Center has compiled a list of common Linux distributions and their corresponding default OpenSSL version.
What should I do right now?
The first step in any response is to inventory any systems in your environment that are running an impacted version of OpenSSL. With that list in hand, you can evaluate the impact of patching those systems to OpenSSL version 3.0.7.
One challenge with this issue is that the attack vector is through X.509 certificates which means that it’s highly unlikely that any security control will be able to mitigate the issue. Increase the sensitivity of your monitoring practice while you work to patch impacted systems.
In some cases, you may consider disabling TLS client authentication until the update can be applied. Whether this is the right move for your environment will depend on your threat model and risk appetite.
The next step is to prioritize your inventory list based on your risk assessment. This is where a CNAPP like the Polygraph Data Platform can help—more on that below.
Work your way through the list of impacted systems updating to the OpenSSL version 3.0.7. For operating system packages, this should be done through a package manager. For other applications, a direct patch or update may be required. Check with your operating system and application vendors for specific steps to update.
How Lacework can help
Lacework customers can search for vulnerable versions of OpenSSL by following the instructions given when logging into their console. You can search for our CVE ids of CVE-2022-3602 and CVE-2022-3786 to generate a list of affected systems for your environment.
Our documentation has more details.
Monitor, update, and continue to monitor
With the heads up from the OpenSSL project last week, teams have had a jump on this issue. Making sure that teams are prepared for a quick turnaround is a rare case for security issues.
Now that we have the specific details, this is a standard incident response for any security issue. This should be a well practiced motion in your environment. Both of these vulnerabilities are high severity which—for most environments—justifies an out-of-band update.
Thankfully, there is a patch available and you can take steps today to protect your environment.