In a nutshell
- New unauthenticated RCE in OpenSSL 3.0.x
- Much lower reach than initially thought
- Still warrants rapid patching if you’re in the vulnerable scenario
The internet has been abuzz with talks of a new, critical vulnerability in OpenSSL 3.0.x for about a week now.
Indeed on the 25th of October, the OpenSSL team announced the upcoming release of OpenSSL 3.0.7 on Nov. 1st.
The information has been relayed in a tweet by distinguished Red Hat software engineer and Apache Software Foundation VP of security Mark J Cox.
What is OpenSSL ?
Let’s start off with a little joke, OpenSSL is like The Matrix.
It’s nowhere and everywhere, it’s nothing and everything.
OpenSSL is a Library, a collection of computer functions that, when compiled, implement mathematical algorithms to perform cryptographic operations such as decrypting, encrypting, signing and verifying data.
OpenSSL is used worldwide in things such as your internet box’s web interface, your on-prem server software, or your IoT doodads such as lamps and cameras.
It is, after all is said, a small add-on on top of your existing software, that basically provides encryption.
Is the vulnerability such a big deal ?
Short answer, yes, very much.
OpenSSL is so widely spread worldwide that any vulnerability in it is de facto a problem.
A Critical vulnerability all the more so.
For end-users, this is a huge problem because it means their camera, their home’s smart lock, or even their phone could get hacked.
Sadly, the onus of getting and installing patches for those will be on them, dependent on the goodwill of the item’s manufacturer.
It gets even worse for IT teams worldwide.
This is a race against time.
This is a competition between IT teams rushing to identify and patch every system running OpenSSL 3.0.x, and hackers reverse-engineering the patch to understand what the flaw was, how to abuse it, and come up with a working malicious payload.
Make no mistake, any organization who loses that race is a potential target, and subject to tremendous risk to their data.
How do we fare over at NORBr ?
We’re happy to say, NORBr doesn’t leverage OpenSSL 3.x, nor OpenSSL 1.x for that matter.
Our frontend cryptography is handled by Cloudflare and our Cloud Provider respectively, so that one gets palmed off to them, and is marked off.
Our backend cryptography, mostly for CardHolder Data for PCI DSS compliance, is handled in HSMs we rent from our Cloud Provider.
In the few instances where we perform other cryptographic tasks, we import lightweight libraries, but nothing from OpenSSL, so that one is marked off as well.
Our workstations get automatic patches, and those that do not comply with our Zero Trust Assessment policies get denied access to NORBr’s internal tools and data.
They are also protected by a top-end NGAV/EDR solution, run by the type of people that actually find and report these kinds of vulnerabilities.
We happily mark this one off as well.
What should YOU do, as a C-level ?
You’re a C-level over at your company, and you’re unsure what to do ?
Here’s our easy steps :
For CEOs and COOs
If you have a CiSO and they haven’t called you yet, get them on the line.
Ask them about your exposure and mitigation strategies.
Ask them to coordinate with your CTO, get back to you sharp with a correction plan.
If you do not have a CiSO, get your CTO on the line right now, and ask them for their step by step operational plan.
Get your CEO or COO and your CTO on the line right now.
Explain how you assess your organization is exposed and what risks this new vulnerability entails.
Only allow them to leave the meeting after a step by step operational plan with clearly defined roles, responsibilities and task assignments has been agreed upon.
Get your infrastructure, security operations, and software operations teams on the line, and tell them in very clear terms about the new threat the company faces.
Assign responsibilities for entire projects and product lines to this or that person or group of persons.
Ensure everyone is clear and onboard with the plan, agree on progress report timings and make yourself available should any difficulties arise during rollout.
Pay the overtime, people value their free time, they won’t give it away for nothing.
Actual reveal of the vulnerabilities
In the end, we’re treated to 2 High vulnerabilities in place of the single Critical one that was teased :
While both feature a Denial of Service, the real kicker comes from CVE-2022-3602’s unauthenticated Remote Code Execution.
That is the one you want to patch ASAP on your servers if they run Client Certificate checking (which they do not, by default).
On the client side the issue is less severe than previously thought as well.
Research from Datadog shows a proof of concept crash on Windows, with a work in progress on Linux systems, but a RCE exploit remains unlikely due to most operating systems’ stack protection mechanisms.