Feb 7th, 2023 – OpenSSL Vulnerability Overview:
OpenSSL releases vulnerability patches for two freely supported open-source binary trains (3.0 and 1.1.1x). It also patched the paid subscription release train, version 1.0.2. While companies have reasons for paid support, now might be a good time to consider moving off paid support. Seven (7) of these vulnerabilities are memory management issues. Safe memory management is allegedly difficult when programming in C. The loan 8th vulnerability was a timing issue. The summary recommendation of this article: review your architecture and patch impacted OpenSSL systems quickly. Now lets see what versions are impacted.
Impacted Versions of OpenSSL:
The versions you want to see after you’ve updated OpenSSL are:
- 3.0 series: new version will be 3.0.8.
- 1.1.1 series: new version will be 1.1.1t (that’s T-for-Tango at the end).
- 1.0.2 series: new version will be 1.0.2zg (Zulu-Golf).
If you have these versions let’s see next what you should be doing and planning.
Companies need to patch their OpenSSL deployments. Pay particular attention to applications that bundle OpenSSL into their releases. Ensure you have an accurate inventory of all your hardware and software assets. Review your software database to determine your potential impact from these vulnerabilities. Be careful patching systems where applications have bundled in their own version of OpenSSL. If you have the means to scan systems with authentication, do so to ensure you have patched all installed versions of OpenSSL pre- and -post-patching. There are special circumstances to follow when patching Linux systems to be aware of. Review your OS vendors advisory for patching OpenSSL. Are their any workarounds to patching?
Emergency Workaround if Patching is not Possible:
There are currently no known work-arounds to alleviate these risks outside of patching. Now we move on to vulnerability management.
You have a Vulnerability Alert Management Process, right?
If you’re a subscriber to CyberHoot’s awareness training platform, you have access to our Policy and Process library which contains the Vulnerability Alert Management Process (VAMP) document. This document prescribes how to respond to situations like this and in what time frame. If your company has not yet adopted a VAMP-like process, now is a great time to get started.
If you’re a vCISO client, we’ve built this process for you and now you must execute according to the prescribed measures and timeframes. If you’re not a vCISO client or CyberHoot Product subscriber, perhaps you want to sign up here.