If you are reading these lines, you are probably already well aware of the upcoming critical fix announced by The OpenSSL team last week. Now, let’s talk about what you need to know to assess the potential impact of this vulnerability and prioritize your remediation efforts accordingly.
Let’s start with a quick recap: last Tuesday, the OpenSSL project team announced the upcoming release of a critical patch to the popular encryption library. The patch, version 3.0.7, will fix a vulnerability that exists in versions 3.0.0-3.0.6 of the library and will be released on Tuesday, November 1st, 2022 between 1300-1700 UTC.
The OpenSSL project definition of a critical vulnerability:
CRITICAL Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
The OpenSSL toolkit includes three different components:
- libssl, an implementation of the TLS protocol.
- libcrypto, a general-purpose cryptographic library.
- openssl, A command line tool for cryptographic tasks, testing, and analyzing.
Judging by the severity of the vulnerability and the description of the potential exploits by the OpenSSL team, it is likely that the vulnerability is part of the libssl library, which handles the encryption and decryption of TLS connections. If you are making a TLS connection to anything (including browsing to this very page), it's probably OpenSSL handling both sides of your connection. A critical vulnerability in this implementation may leave hundreds of thousands of servers using OpenSSL v3 exposed. However, many applications may also use OpenSSL for other purposes, such as encryption and decryption, creation of X.509 certificates, calculation of message digests, and more. In such instances, it is likely that your detection tools are already alerting about the critical vulnerability, but these alerts may not be as urgent to fix.
On the bright side of things, not all OpenSSL versions are affected by the issue. Version 3.0.0 was first released in September 2021, making it much less prevalent than the unaffected version 1 of the library. According to recent research by Wiz, about 75% of companies have at least one vulnerable instance of OpenSSL in their cloud environment. However, the same research also points out that only 1.5% of all OpenSSL instances are of versions 3.0.0-3.0.6, implying a potentially lower risk. While this research is obviously biased towards large enterprise companies in the US market, it still sheds some optimistic light on the story.
But when it comes to such a popular library, it is no surprise that many widely-used open-source packages use OpenSSL v3. Some of them are popular Linux distributions such as Ubuntu 20.04, Red Hat Enterprise 9, Fedora 36, and more. For your convenience, we mapped the full list of all the currently known vulnerable software packages using OpenSSL v3:
Ubuntu LTS 22.04
Red Hat Enterprise Linux 9
CentOS Stream 9
Fedora CoreOS 36
Fedora Rawhide LTS
Linux Mint 21 Vanessa
Mageia Cauldron 3.0.5
Alma Linux 9.x
Alpine Linux Edge
Debian Sid (unstable)
Rocky Linux 9
(see docker’s image vulnerability database for more details)
Other affected packages
Node.js v18.x and v19.x (announced an upcoming patch)
While it is still too early to know how severe the outcomes of this vulnerability will be, we highly recommend remediating it quickly to minimize the risk window as much as possible. To assist our customers and the cybersecurity community in doing so, Dazz has announced a 24/7 Remediation Center dedicated to remediating the OpenSSL vulnerability. No commitment, free of charge.
Want to learn more? Contact us and remediate OpenSSL NOW!
Six reasons why we build our own UI components library from scratch
Modern applications are giant meshes of services and interconnected APIs. However, there isn’t a standardized, systematic way to integrate them.
My colleagues and I are thrilled to share that we launched Dazz today. We set out at the beginning of 2021 with a twinkle in our eye...