Racing to Fix the OpenSSL Critical Vulnerability – What you need to know
This is a developing story. Updates will be amended as new information and guidance become available.
The implications of a severe vulnerability
The OpenSSL Project team announced that on November 1st, 2022, between 1300-1700 UTC, OpenSSL version 3.0.7 will be released. This new version will fix a critical vulnerability in the library affecting OpenSSL versions 3.0.0 and above.
Since the specifics of this vulnerability have not been released yet, it is difficult to predict the potential risk. However, past experience has shown that critical OpenSSL vulnerabilities should be taken seriously. Anyone who experienced the devastation of Heartbleed (CVE-2014-0160), another critical severity OpenSSL vulnerability, will attest to that.
Why is the OpenSSL Project team preannouncing these security fixes?
SSL and TLS are cryptographic protocols that enable secure communication across networks, and the OpenSSL library implements them.
Following the critical Heartbleed bug in 2014, the security of computer systems, the internet as a whole, and individual users were clearly dependent on the “good health” of this ubiquitous software library.
A wide range of operating systems (Windows, macOS, various Linux distributions, etc.) and client-side software are supported by OpenSSL, as well as web and email server software (Apache, Nginx), network appliances (Cisco, Fortinet, Juniper, etc.), and industrial control systems.
That being said, the OpenSSL team usually announces security fixes via its site and mailing list, as well as contacting organizations that make general-purpose operating systems using OpenSSL, the maintainers of popular open-source projects derived from OpenSSL, as well as organizations with whom the project has commercial ties. A vulnerability detail and a patch are shared in advance with them.
How bad is it? Putting the situation in perspective
One positive aspect of this vulnerability is that it only impacts the newer version of OpenSSL V3, which is significantly less prevalent than OpenSSL V1. OpenSSL V1 is not impacted by this vulnerability. While most organizations will have at least one impacted environment, most are not. Wiz Data Labs identified an impacted instance in over 75% of organizations but only in 1.5% out of the total OpenSSL instances. In our current scans, only a small fraction of the assets may also be vulnerable since only new versions like Ubuntu 22 and RHEL 9 include OpenSSL v3 in their package managers.
Getting Ready to Patch
- Identify all your assets that are currently running OpenSSL 3.x. Especially those that are internet-facing, since they are exposed to direct cybercriminal attacks.
- List your vulnerable technologies and reach out to the relevant vendors to align with their timelines.
- Map each vulnerable asset to your IT and business owners to ensure that you can quickly and effectively apply any needed patch or update.
- Don’t forget about your 3rd and 4th party connections that are currently running OpenSSL 3.x. Your risk mitigation plan is incomplete without identifying such assets and taking the necessary steps to deal with them.
The Race to OpenSSL Exploit Starts on November 1
It is not clear what details will be provided at the time of the patch on November 1. What we do know with absolute certainty is that the vulnerability details will trigger a global race to the exploit. Black hats and white hats alike will work feverishly to reverse engineer the patch and identify potential exploits.
This means that on the day of the patch or a short time after, we can expect to know the full details of the vulnerability and its exploitability. That’s when we will be able to fully assess the risk.
This flaw, like multiple Log4x alarms that followed Log4Shell, may turn out to be a ‘kitten’ rather than a ‘lion.’ However, until we know for sure, you should be prepared to patch as soon as possible.
