OpenSSL Issues Update to Fix Formerly ‘Critical’ Vulnerability Nov. 1
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5.00 out of 5)
Loading...

OpenSSL Issues Update to Fix Formerly ‘Critical’ Vulnerability Nov. 1

This high-severity vulnerability affects the OpenSSL version 3.0 series. If you’re using an earlier version of OpenSSL (i.e., anything 3.X.X) on your server or platform, then this CVE doesn’t affect you

If your web servers or other systems use OpenSSL version 3.X.X, you’ll want to update to version 3.0.7 immediately. The OpenSSL Project released an update that addresses a high-level vulnerability in the version 3.0 series of their open source library and command line tool. If you saw similar headlines over the last week, you may have noticed that there was a critical vulnerability that they said they’d fix in the OpenSSL version 3.0.7 release on Nov. 1. However, the good news is that this common vulnerability exploit (CVE-2022-3602) has been downgraded to a high-severity vulnerability instead.

If the Project stuck with the original critical ranking, it would have made this the second critical severity vulnerability they’ve announced since 2014 (when the organization started ranking them). Remember the OpenSSL Heartbleed bug? Yeah, that was the reason why the OpenSSL Project started ranking the severity of these vulnerabilities in the first place.

Now, don’t misinterpret what we’re saying — this OpenSSL vulnerability is still a serious issue that you need to address quickly. Knowing this, we’ll jump right to what you need to know about CVE-2022-3602.

Let’s hash it out.

A Quick Overview of the Situation

On Oct. 25, The OpenSSL Project Team announced the upcoming release of OpenSSL version 3.0.7. This is a security-fix release that’s meant to mitigate a critical security issue affecting the OpenSSL version 3.0 series.

According to the Nov. 1 official advisory, the concern is that a buffer overrun could be triggered after the certificate’s digital signature has been checked simply by an attacker using a malicious email address in the certificate. This could occur if the TLS client connects to a malicious server or if a malicious client authenticates to your server.

The issue here would be the risk of your server crashing or an attacker executing malicious code remotely. However, for this to happen, one of two important factors would have to play a role:

  1. The issuing certificate authority would need to sign a malicious certificate, or
  2. The application itself would need to move forward with the certificate verification despite not being able to track an end certificate back to the CA’s trusted root.

The risk is also reduced because many platforms have stack overflow protections in place.

How Bad Is the Situation?

Honestly, it’s better than originally anticipated. Up until they released the CVE advisory after 11:00 a.m. (ET), OpenSSL originally ranked the severity of this vulnerability as critical, meaning the worst-of-the-worst kind of situation. To put this in perspective, OpenSSL ranks issues in four categories of severity: critical, high, moderate, and low.

So, what qualifies as a high-severity vulnerability?

“This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions.”

Well, that’s a little vague but it sure as heck beats the former critical severity ranking, which included risks like server memory disclosures and private key compromises in addition to higher risks of remote code executions.

But there still is a big complication. In the perspective of website security, it’s something that many servers use to enable secure connections between parties (i.e., turning on HTTPS). The issue here is that OpenSSL version 3.0 has a vulnerability that, if left unmitigated, leaves your systems at risk. If this happens and you did nothing to address it quickly, your customers likely won’t be very understanding.

Which Versions of OpenSSL Are Affected?

If you’re using OpenSSL series versions 3.0.0, 3.0.6, or anything in between, you need to apply this patch immediately. In October, the OpenSSL Project released version 3.0.6 but quickly ended up walking back the release (along with version 1.1.1r) due to a “report of a significant regression.” Instead, they’ve decided to move forward with the release of versions 3.0.7 and 1.1.1s, both of which have been released today (Nov. 1).

Are these two version issues related? Not according to OpenSSL Project Team. Earlier versions of OpenSSL aren’t susceptible to the same risk because the critical security issue (which will be issued a CVE on Tuesday) reportedly only affects versions OpenSSL 3.0, meaning the affected versions include:

  • OpenSSL 3.0.0
  • OpenSSL 3.0.1
  • OpenSSL 3.0.2
  • OpenSSL 3.0.3
  • OpenSSL 3.0.4
  • OpenSSL 3.0.5
  • OpenSSL 3.0.6

Examples of Vulnerable Applications That Rely on OpenSSL

Linux-based applications and systems (including many web servers) frequently rely on OpenSSL — some of which include the vulnerable 3.X.X versions. Here are a few examples of some such distributions:

To see a list of other recent OpenSSL vulnerabilities that have been addressed, check out their OpenSSL vulnerabilities reporting page. You can also request to join the OpenSSL Announce List if you want to stay abreast of these security issues and fixes.

How to Check If Your System Is Using a Vulnerable Version of OpenSSL

If you use the OpenSSL command line utility, you can easily check to see which version you’re using. Simply load the OpenSSL tool and the version should display as your first entry. Otherwise, you also can view the version information by entering the following command (as illustrated in the screenshot below):

openssl version
An OpenSSL example screenshot that shows the version of the command line utility tool

Image caption: A screenshot of a vulnerable version of the OpenSSL command line utility tool that shows the OpenSSL version that’s running on a device.

How to Mitigate This Issue

Honestly, the cure for this ail is pretty simple: upgrade OpenSSL on your server to version 3.0.7. Yup, it’s really that straightforward.

Of course, if you don’t have OpenSSL on your server because it’s bundled with a third-party’s software or platform, you should reach out to your vendor ASAP to ensure that they’re taking care of things on their end.

Note: You do not need to update your SSL/TLS certificate. The vulnerability is only in the OpenSSL software and not in the certificate itself.

Why Is This Vulnerability Now Listed as High Instead of Critical Severity?

As with virtually everything in life, things change. In the case of CVE-2022-3602, they continued to analyze the vulnerability after making their initial pre-announcement on Oct. 25 and determined that it wasn’t as severe a risk as originally anticipated:

“Our security policy states that a vulnerability might be described as CRITICAL if ‘remote code execution is considered likely in common situations’. We no longer felt that this rating applied to CVE-2022-3602 and therefore it was downgraded on 1st November 2022 before being released to HIGH.”

Now, don’t get me wrong: it’s still bad and is definitely something you should address immediately by installing the latest version of OpenSSL (3.0.7). But it’s good that the situation isn’t thought to be as dire as originally anticipated.

Why Announce the Vulnerability Early If the Patch to Fix It Isn’t Immediately Available?

Mark Cox, an open source evangelist who works with Red Hat and the OpenSSL Project, says that making this type of early announcement is their policy because it gives organizations time to plan ahead to set time aside to address these issues. The idea here is that if you know about it ahead of time, you won’t find yourself having to drop everything at the last minute to roll out updates immediately.

But doesn’t making an early announcement potentially cause security risks? After all, these announcements inform bad guys that there’s a confirmed vulnerability they might be able to exploit. Yes, that’s technically correct. But Cox shares on his Twitter page that this type of scenario isn’t likely: “Given the number of changes in 3.0 and the lack of any other context information, such scouring is very highly unlikely.”

A screenshot of the tweets from Mark Cox's twitter page that talks about why OpenSSL releases pre-notifications of their security advisories
Image caption: A screenshot from Mark Cox’s Twitter page.

As with anything on the internet, there’s always a risk that someone, somewhere will figure out how to exploit vulnerabilities. But every cybercriminal is going to ask themselves whether the juice is worth the squeeze. They’d have to spend hours or even days trying to determine the vulnerability and then figure out how to exploit it. By that time, it’s likely that the patch will already be available and applied.

This OpenSSL Vulnerability Isn’t the First (And Won’t Be the Last)

As we touched on earlier, CVE-2022-3602 isn’t the first severity vulnerability that’s been identified in OpenSSL. We saw that years ago with CVE-2014-0160, or what’s more commonly known as Heartbleed, was another critical vulnerability that plagued OpenSSL. We won’t get into all the technical on how it worked, but this vulnerability wound up enabling secret encryption keys and other unencrypted data to be passed along (and potentially compromised).

Now that this new vulnerability (CVE-2022-3602) has been downgraded, it just serves as a reminder of how important it is to keep your systems patched and updated. This way, as vendors and others roll out vulnerability mitigations, you’ll be able to keep your systems as secure as possible.

Author

Casey Crane

Casey Crane is a regular contributor to and managing editor of Hashed Out. She has more than 15 years of experience in journalism and writing, including crime analysis and IT security. Casey also serves as the Content Manager at The SSL Store.