The IT Nerd

The OpenSSL Project is releasing a new version of OpenSSL today that will patch an undisclosed flaw in current versions of the technology, leaving companies in a bind to quickly fix the vulnerability before hackers potentially begin to exploit it. I first posted about this last week, and I recommend that everyone who uses OpenSSL update to this version ASAP.

I have some commentary on this patch from a few sources. Starting with Alex Spivakovsky, VP of Research at Pentera:

The fact that OpenSSL is self-labeling the vulnerability as a “critical flaw” means that companies would be wise to pay attention. With OpenSSL taking care of the patch, the most important thing security teams can do at this point is try to inventory their instances of OpenSSL and prioritize future remediations based on organizational impact. This will ensure that once the patch is issued they can systematically remediate their most critical instances.

I’m really impressed with OpenSSL’s handling of the process and not shying away from admitting to a flaw on this level. Software bugs and vulnerabilities happen, and it’s a natural byproduct of the software development process. OpenSSL’s proper handling of this disclosure will likely help many companies mitigate the potential impact of the flaw.”

I also wanted to share Rezilion’s information blog post on this topic, along with this commentary from Yotam Perkal, Director of Vulnerability Research at Rezilion 

“Yes. We won’t know how exploitable it is until Tuesday once the fix and more information are released. But regardless of how critical/ easily exploitable it is, what is safe to assume is that the attack surface won’t be nearly as significant as Heartbleed as OpenSSL 3.x is relatively new and hence won’t be common in a production setting. See my tweet as reference:”

Some proportion.
However critical the new OpenSSL vulnerability will be, consider its scope.

Currently, under 16,000 publicly accessible servers worldwide are running potentially vulnerable versions of OpenSSL (3.X) while ~238,000 servers are STILL vulnerable to HeartBleed. pic.twitter.com/fyC0knl3EG

— Yotam Perkal (@pyotam2) October 31, 2022

Derek McCarthy, Director, Field Engineering of XIoT Cybersecurity Firm, NetRise, provided the following commentary:

Since the details of the vulnerability have yet to be published, we can’t know exactly the impact that this will have on affected software and devices. However, OpenSSL’s definition of a ‘critical’ vulnerability (their own internal scale – not CVSS) is one that ‘affects common misconfigurations which are also likely to be exploitable”, additionally, these vulnerabilities will typically include a ‘significant disclosure of the contents of server memory’, which could often lead to serious impacts such as Remote Code Execution (RCE).

Due to the likely serious nature of these vulnerabilities, organizations should be prepared to scope and address this issue across the enterprise. This once again highlights a common issue that CISOs face, however. How do you scope which of your devices are running a vulnerable version of OpenSSL? This is more trivial for ‘traditional’ devices and applications, but in dealing with the eXtended Internet of Things (XIoT), asset owners are often left with the option of reaching out to their vendors, which is often a convoluted and inefficient (to put it lightly) process.

You can get more info on the patch here. And as I said earlier, you should download it and install it on anything that uses OpenSSL 3.

UPDATE: I have additional commentary. Starting with Neal Humphrey, AVP of Security Strategy at Deepwatch. 

“The news is out on the OpenSSL front, and thankfully things have been downgraded from Critical to High. While there is a remote code execution (RCE) aspect to the exploit, it is not at the level of the Log4J issues from last year. Log4J was an issue due to its spread and the access that it provided. The OpenSSL issues can be seen as widespread as Log4J but it just isn’t as dangerous. That being said, users should still look to upgrade based on the exploit due to the distributed nature of OpenSSL and it’s ability to modified, different from log4j”

I will have additional commentary and analysis as the day goes on. Stay tuned!

UPDATE #2: I have additional commentary from Kevin Bocek, VP of Security Strategy & Threat Intelligence at Venafi:

“Patching this new OpenSSL vulnerability is just the start, as it demonstrates how machine identities can be broken, allowing threat actors to masquerade as trusted services. Whether we’re running in the cloud in Azure, using Kubernetes in Amazon AWS, or using Apache in your datacenter, the entire digital business requires safe authentication of machine identities. The vulnerabilities in OpenSSL show the impact of poor machine identity management – specifically authenticating machine identities – opening the door to attackers. 

“The current lack of visibility of complex cloud environments leaves businesses dangerously open to attack. Cloud is an untapped war front for threat actors, and I suspect we’ll see a lot more attacks on cloud native environments over the next few months. There’s a knowledge gap on both the threat actor and security sides, so we’re yet to truly understand the security implications, the attacks we might face, and vulnerabilities we may uncover. As we develop a deeper understanding of these complex environments, we’ll see a lot more critical vulnerabilities and high-impact attacks unearthed.

“Now that the seriousness of this vulnerability has been disclosed, it is likely that threat actors are already looking to take advantage of it. To protect themselves, organizations must prioritize patching, and fast. But as with Heartbleed, organizations also need to replace the machine identities impacted by OpenSSL’s vulnerability. We can’t be successful in digital business without the four tasks of machine identity management – authentication, authorization, lifecycle, and governance – work correctly. History has shown that the industry needs to be ready for these events, now and in the future.”

UPDATE #3: I have a blog post from Rezilion that goes into the weeds by analyzing this issue in detail. Plus I have additional commentary from Yotam Perkal, Director of Vulnerability Research at Rezilion:

Is there any cause for concern?

The short answer is, you should be worried.

How worried should you be?

Well, that depends how many vulnerable instances of OpenSSL3.x you have in your environment and do you have the ability to accurately detect them so that you could apply the patch once it’s out.

The OpenSSL team announcement caused significant concern for several reasons. First, this is only the second time that the OpenSSL project team classifies a vulnerability as critical. The previous time being Heartbleed (CVE-2014-0160) which enables attackers to compromise sensitive information such as secrets and private keys that were meant to be protected by SSL/TLS.

Second, OpenSSL is extremely prevalent in modern computer environments. The relatively long advance warning window provided by the OpenSSL project team has added to the speculations regarding the significance of this vulnerability.

That said, the potential impact in this case seems relatively limited. Mainly due to the fact that the vulnerability only affects OpenSSL versions 3.x.

Why is that significant?

Well, version 3.0 of OpenSSL was only released a year ago. In IT terms, it is considered a new library. Hence, not many software projects and applications have migrated to use it which makes it relatively rare to find in production systems.

For proportion, there are currently under 16,000 publicly accessible servers worldwide running potentially vulnerable versions of OpenSSL (3.X) while close to 240,000 servers are STILL vulnerable to Heartbleed 8 years after its initial discovery

Does Yotam think this is an issue worth covering?

Yes. It definitely deserves coverage.

What kind of tools this vulnerability might affect. What platforms/companies etc use this?

As I mentioned earlier, Second, OpenSSL is extremely prevalent in modern computer environments. Yet since version 3.x is relatively new it is less common to find in a production setting.

These are several Linux OS distributions that come with OpenSSL 3.x out-of-the-box. For example (a more comprehensive list is available here):

CentOs stream 9

Fedora 36

Fedora Rawhide

Kali 2022.3

Linux Mint 21 Vanessa

Mageia Cauldron

OpenMandriva 4.3

Redhat ES 9

Rocky Linux release 9.0

Ubuntu 22.04 (Jimmy)

Do note that there is a possibility that an OS distribution does not come with OpenSSL 3.x by default yet it was actively installed at a later stage.

If you are running Docker containers in your environment, please refer to the DockerHub image vulnerability database which tracks vulnerable container images under DSA-2022-0001.

Docker currently estimates that around 1,000 docker image repositories (Official Images and Verified Publisher Images) are potentially vulnerable.

UPDATE #4: I have commentary from Mattias Gees, Container Product Lead at Venafi

“When OpenSSL first announced this patch was coming, I immediately thought back to major vulnerabilities of the past, such as Heartbleed and Log4j. However, this vulnerability has been downgraded from critical to high severity by OpenSSL, mainly because it doesn’t cause data leakage and the attack vector is relatively small. But this doesn’t mean we’re off the hook as the risk of DDoS attacks is still high if servers request client authentication, and a malicious server connects.

“Servers that are on OpenSSL 3.0 and are using Client Authentication in a non-trusted environment – such as public facing servers – should patch immediately to ensure they don’t fall victim to DDoS attacks. Servers running in trusted environments should still be patched, but the urgency here is reduced as attacks won’t be effective unless a threat actor manages to infiltrate your network.”