On Tuesday, October 25 a new OpenSSL hot-fix release was announced which will patch a critical vulnerability that exists within the v3.0.X branch. OpenSSL 3.0.7 will be released on Tuesday, November 1 and in tandem the details of the vulnerability and its associated CVE will be made public.
OpenSSL is an open source project that provides easy to use cryptographic functions and is used to secure communications around the world. Put plainly, the internet runs on OpenSSL.
This blog will speculate as to the nature of the coming vulnerability and the likelihood of it being weaponize-able from an exploit developer’s perspective.
What’s Affected?
Nearly every *nix distribution uses OpenSSL. Thankfully, the lion’s share of OpenSSL usage still resides on the maintained v1 branch of the project and this vulnerability only effects the v3 branch. We have identified several major linux distributions on the v3 branch:
-
Ubuntu 22.04
-
CentOS 9
-
Fedora 9
Several distributions and appliances we’ve check that are on the v1 branch and not effected:
-
Amazon Linux AMI
-
vCenter
-
Fortinet FortiGate
To asses what version of OpenSSL is being utilized by your system you can run the following:
openssl version
Other installed applications may bring in their own dependencies outside of the system install locations so a more thorough search should be done for any non-standard services.
Open4Sslell… do we have another Log4Shell situation on our hands?
OpenSSL is even more ubiquitous than Log4j, the Java logging library that was affected by the Log4Shell (CVE-2021-44228) nearly a year ago. But, as we’ve seen with the rash of “named” vulnerabilities as of recent like “Spring4Shell” and “Text4Shell”, a critical vulnerability is not always critical.
Log4Shell was easily exploitable in the common configuration and the nature of the vulnerability allowed for attackers to easily execute arbitrary code if run on older Java runtimes.
OpenSSL rates their security issues and we can see that in order for a critical to be issued, the vulnerability must affect the common configuration, and leading to private key disclosure or is easily exploited remotely. This combination of items for an exploit developer definitely points to it being a target of interest.
If this upcoming vulnerability is like the last critical OpenSSL vulnerability in 2016, it will be significantly more difficult to weaponize than Log4Shell. The prior CVE-2016-6309 was a Use-After-Free (UAF) vulnerability that was triggered when processing large messages and only affected a single release version. Memory corruption issues like this are not so straight forward and are increasingly becoming more difficult to weaponize on modern operating systems. Libraries reside in applications which run on operating systems – and there are marathon worth of hurdles to overcome to truly weaponize a Use-After-Free or similar bug.
Conclusion
While this vulnerability may be easy to trigger, it will probably take serious investment by an organization to weaponize. This investment will take time, and time kills access when it comes to N-days and their patch cycles.
As we all eagerly wake up from our night of trick-or-treating come Tuesday morning, I think we’ll find our industry is abuzz about this new hot vulnerability – and a week later we’ll all move on.
We’ll see.
