Security

How to remediate OpenSSL CVE-2022-XXXXX

Tomer Schwartz

,

Co-founder & CTO

,

BRIEF SUMMARY FOR THE UNINFORMED

Last Tuesday the OpenSSL project announced that they will be issuing a fix for a critical vulnerability with the release of OpenSSL 3.0.7. OpenSSL is the de facto standard implementation for SSL and TLS, which is how most traffic is encrypted these days. OpenSSL flaws are far from common: it’s a mature, well-audited project. The project team is very responsible in remediating vulnerabilities when found, and the last critical vulnerability was announced in 2016. Still, every major vulnerability in the project is a major vulnerability for the internet: some of us may remember Heartbleed, a vulnerability that impacted the same project.

Since the announcement on Tuesday last week, there has been quite a bit of speculation on what the vulnerability is and what is the impact will be. The OpenSSL team has finally released the advisory today, so this blog post will cover the technical details now that they are clear.

IS IT THAT BIG OF A DEAL?

Yes and no.

First, the vulnerability is in a part of the code that was only introduced in the last major release of OpenSSL, which means that only versions 3.0.0-3.0.6 are impacted. OpenSSL 3.0.0 was released in September 2021, and it takes time for the open source community to adopt new versions downstream. In our last blog post before the details were clear, we noted that many long-term support versions will not need to be patched. According to our analysis, while the vast majority of our customers are impacted, most of their workloads in the cloud are not. Still, there are plenty of reasons these customers are working tirelessly to remediate the vulnerability.

Another thing that lessens the impact is that an exploit is not an end-of-the-world scenario: this vulnerability alone cannot cause remote code execution, and while it is classified as information disclosure, the risk of certificate compromise or PII leak is extremely unlikely. We will explain how we came to this conclusion below, and we will update the blog post if new information becomes available.

Having said that, the OpenSSL team was right to take this vulnerability very seriously. The vulnerability can cause a pre-authenticated denial of service, affects the default configurations, and is trivial to exploit. This is a big problem if critical workloads are relying on OpenSSL for communications. What it means is that if you have any service that accepts traffic from untrusted sources and relies on OpenSSL 3.0.0-3.0.6, you should definitely patch as soon as possible, or expect uncontrolled downtimes.

TECHNICAL BREAKDOWN

The vulnerability itself is in

Text text text

<<<

CODE HERE

>>>

Text text text

<<<

MORE CODE

MORE CODE

>>>

REMEDIATION GUIDELINES

Now that version 3.0.7 is officially released, the short answer is that if you are using 3.0.0, upgrade to 3.0.7 as soon as possible. For a single workload or application it should be easy enough: just upgrade the relevant packages, dependencies, or images. If you are dealing with a large environment with multiple applications and services, this is where it gets tricky.

DISCOVER

First, you should focus on mapping your inventory to understand which software components may be affected by the vulnerability. Some of the affected components

See Dazz for  yourself.

Get a demo