The IT Nerd

The OpenSSL project team put out an announcement earlier this week that a “critical” fix was coming next week:

The OpenSSL project team would like to announce the forthcoming release 
of OpenSSL version 3.0.7.

This release will be made available on Tuesday 1st November 2022 between 
1300-1700 UTC.

OpenSSL 3.0.7 is a security-fix release. The highest severity issue 
fixed in this release is CRITICAL:

Now of course OpenSSL isn’t going to say what the issue is before the fix is available. But the fact that they called it “critical” means that it is not good and that if you use OpenSSL, you should upgrade to this release ASAP. Another data point, the last time that OpenSSL issued a critical vulnerability patch was in 2016, and this is just the second patch to be assigned a critical rating. So you know it’s bad. Whatever it is.

Mattias Gees, Container Product Lead at Venafi had this comment:

The announcement of the new OpenSSL critical vulnerability immediately brought back not-so-fond memories of Heartbleed or – more recently – the Log4J vulnerability. Heartbleed had a significant impact on all operations teams worldwide, and since then IT infrastructure has become 10 times more complicated. When Heartbleed was discovered, the majority of IT organizations were using dedicated hardware or virtual machines (VMs). But now we are in the Cloud Native era, which has created advanced containers and serverless architectures.

The attack vector has become a lot larger, and rather than just having to examine their VMs,  organizations need to start preparing to patch all their container images in response to this announcement. Hopefully, the Log4J vulnerability triggered a lot of teams to audit their dependencies. If this is the case, these steps will help teams quickly roll out a targeted fix on their infrastructure. SBOMs (Software Bill of Materials) of all container images are a great start to gaining those insights into the dependencies in your applications and infrastructure.

We also now know that OpenSSL versions prior to 3.0 are not impacted, and a lot of operating systems use OpenSSL 1.1, so these environments won’t be impacted. This knowledge will allow cybersecurity and operations teams to dismiss large sections of their infrastructure, and hopefully make the impact of this vulnerability smaller than initially expected. But platform engineering teams should keep investing in better auditing of their environments and their dependencies for the next threat, which is always just around the corner.

If this applies to you, I would keep an eye out on November 1st for this release and be prepared to apply patches as it is a safe bet that the bad guys are going to reverse engineer what this patch addresses and use it to launch attacks. I say that because if this was an active attack vector, I suspect that the patch would be out immediately. Thus while sysadmins have some time, it likely will not be a lot of time to patch this once the patch is out.

This entry was posted on October 28, 2022 at 12:57 pm and is filed under Commentary with tags OpenSSL. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.