Editor’s Note – Nov. 1st, 2022: With the release of OpenSSL’s blog post on Nov. 1st, the issue highlighted in this article previously considered “Critical” was downgraded and the official disclosure for security fixes to OpenSSL version 3.0.7 contains two “High” rating vulnerabilities. The vulnerability which was originally assessed as “Critical” by the OpenSSL team was given the original determination because of the assumed capabilities for buffer overflow to result in remote code execution. However, once organizations tested the vulnerability prenotification of disclosure, it was discovered that the buffer overflow resulted in “an adjacent buffer that was yet to be used and therefore there was no crash or ability case remote code execution.” OpenSSL’s post goes on to state that most organizations have stack overflow protections from causing remote code execution, and often rather results in crashing the system.
Given the much lower threat of remote code execution, CVE-2022-3602 (originally designated as “Critical” pre-discloser by the OpenSSL team) was downgraded to “High” rating, alongside CVE-2022-3786, which is another “High” rating vulnerability fixed in 3.0.7 which was never considered “Critical” during assessment due to the lack of RCE capabilities. Please refer to OpenSSL’s blog post for more information, found here.
Last week, the security world became abuzz as they uncovered that OpenSSL.org quietly announced that they would be releasing a new update to their OpenSSL software package (Version 3.0.7). This update, releasing on November 1st, will be addressing a “critical” security issue that is still yet to be disclosed but affects vulnerabilities on OpenSSL versions 3.0 to 3.0.6.
As of writing this the following Monday, October 31st, this juicy vulnerability is still nothing but whispers in NDA land and swapped warnings, as the “critical” rating of this vuln sparks rumblings of “a potential Heartbleed 2.0” situation in the security world. It’s highly likely that CISA, or even potentially NSA if the vulnerability is bad enough, is breathing down the necks of OpenSSL and OpenSSF teams alike – making for an extra spooky Halloween all around.
But, what is it about this announcement that has the hair of security researchers everywhere standing on end? And what does this release have to do with Heartbleed – an OpenSSL vulnerability uncovered in 2014 that became a phenomenon in the security space?
Lock your doors, grab some Halloween snacks, and let’s dive into this new critical vulnerability we’re internally dubbing “Heartbreak.”
Heartbleed vs. The OpenSSL 3 “Heartbreak” Vulnerability
Back in 2014, Heartbleed was a vulnerability uncovered in several OpenSSL 1.0.x versions. The vulnerability existed because of a minor coding error in the Heartbeat extension of OpenSSL which allowed for the machine running a web server to receive ‘Heartbeat’ requests from the remote machines using it. The error allowed for the requests to be manipulated to return a mirrored size of data from the server per request – anything from junk data to securely stored information.
This vulnerability quickly became a phenomenon in the security space. It was one of the first vulnerabilities to get its own massively funded marketing campaign to promote the importance of security in open-source technologies, and it prompted the Linux Foundation to kick off the Core Infrastructure Initiative, a program to improve the overall security of open-source software.
Even eight years later, we can feel just how strong the shockwaves from Heartbleed are. The announcement of a new vulnerability within the OpenSSL software has SOC teams scrambling, with many working over the Halloween weekend (despite no update release), simply because history has shown that when OpenSSL tells you in advance that a critical vulnerability is coming, you listen.
Thankfully, it looks like the magnitude of this new OpenSSL vuln will be far less widespread than the Heartbleed we all know and fear.
How Critical Is This New OpenSSL “Critical” Vulnerability Going to Be?
This “Heartbreak” OpenSSL 3 vulnerability is getting a lot of pre-disclosure media engagement due to the fact that the OpenSSL patch notice indicated that the vulnerability fixed in version 3.0.7 is rated “critical” by the OpenSSL team. Referring to their internal policy in a blog from 2015 where the new severity rating was announced,
“Critical severity: This affects common configurations 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 (excluding local, theoretical or difficult to exploit side channel attacks) or where remote code execution is considered likely in common situations.”
However, while this vulnerability will be a massive risk to those with open-facing devices (most of them) using OpenSSL, the overall impact on your environment will likely be concentrated. In fact, sites like Wiz are reporting that this new vulnerability will affect only 1.5% of OpenSSL instances in most environments.
According to many prominent voices in the space, not a lot of organizations are going to find themselves in OpenSSL 3.x+ (the versions of OpenSSL affected by this vulnerability), unless they have machines spun up with newer technologies, such as RHEL 9 and Ubuntu 22.04 which already have OpenSSL3.0 bolted on. If that’s the case and you’re currently running OpenSSL3.x in production, the critical rating of severity determined by the OpenSSL team strongly indicates the possibility that this could be a remote-enabled exploit of the OpenSSL software.
Thankfully, this vulnerability surfacing this early in OpenSSL3’s lifecycle likely means fewer vulnerable machines have been deployed, so this is a much lower impact than it would be if OpenSSL2.x were affected. RHEL versions 6, 7, and 8 are all still in support and use older versions of OpenSSL, and many organizations are still planning their transition to newer distributions like RHEL 9. Similarly, there are three LTS versions of Ubuntu still in support, all of which use OpenSSL 2.x.
So, in summary, while this looks like Heartbleed and sounds like Heartbleed, our team predicts that it’s going to be less widespread, with fewer machines to remediate and the vuln squashed before most organizations have migrated to the vulnerable version of OpenSSL. Instead, it will simply be a “Heartbreak” for those with OpenSSL3.x, and anyone out there that was hoping to jump on the Heartbleed 2.0 scare train – hence our internal name.
How to Get Ahead of OpenSSL’s Upcoming “Heartbreak” Vulnerability
If you were one of many security teams scrambling over the weekend trying to find out whether or not this new OpenSSL vulnerability might affect your environment… good news. We have a better way.
With Nucleus, assessing vulnerabilities like this can be tackled in a matter of seconds. Our customers are able to quickly query for installed software using our “Installed Software” feature under the asset tab. From there, all you would have to do is search for “OpenSSL 3” in the software search box and you can quickly see any assets you have that have the software installed. Now, instead of looking for unknown unknowns across absolutely everything, you know which 1.5% (or thereabouts) of your organization’s systems to be watching for potential funny business.
If you’re not already a Nucleus customer, there are still other roundabout methods to get some of this information. Some vulnerability scanners have a software inventory or informational vulnerability section that enumerates all the software installed on a host. You can check the software inventory or the informational vulnerabilities from your most recent scans for indicators of what version of OpenSSL you have installed on your machines.
It’s also not a bad idea to check any ASM tools you may be using, or Shodan/Censys, to see if any OpenSSL3 turns up in your public IP space. However, keep in mind it’s possible to configure web servers to lie about what they are, so authenticated vulnerability scans will always be more accurate.
Overall, the best method for clear observability of how your environment is affected is a tool like Nucleus that brings all your assets together under one roof. Ready to finally unite your security stack into one single pane of glass for smarter vulnerability assessment and remediation? Contact us today.