Everyone depends on OpenSSL. You may not know it, but OpenSSL is what makes it possible to use secure Transport Layer Security (TLS) on Linux, Unix, Windows, and many other operating systems. It’s also what is used to lock down pretty much every secure communications and networking application and device out there.
So we should all be concerned that Mark Cox, a Red Hat Distinguished Software Engineer and the Apache Software Foundation (ASF)’s VP of Security, this week tweeted, “OpenSSL 3.0.7 update to fix Critical CVE out next Tuesday 1300-1700UTC.”
How bad is “Critical”? According to OpenSSL, an issue of critical severity affects common configurations and is also likely exploitable.
It’s likely to be abused to disclose server memory contents, and potentially reveal user details, and could be easily exploited remotely to compromise server private keys or execute code execute remotely. In other words, pretty much everything you don’t want happening on your production systems.
The last time OpenSSL had a kick in its security teeth like this one was in 2016. That vulnerability could be used to crash and take over systems. Even years after it arrived, security company Check Point estimated it affected over 42% of organizations.
This one could be worse. We can only hope it’s not as bad as that all-time champion of OpenSSL’s security holes, 2014’s HeartBleed.
So why announce the security hole before the patch is in? Cox explained, “That’s our policy … to provide folks with a date they know to be ready to parse an advisory and see if the issue affects them.”
But couldn’t a hacker find it and exploit it as a zero-day? He doesn’t think so. “Given the number of changes in 3.0 and the lack of any other context information, such scouring is very highly unlikely.”
There is another little silver lining in this dark cloud. This new hole only affects OpenSSL versions 3.0.0 through 3.0.6. So, older operating systems and devices are likely to avoid these problems. For example, Red Hat Enterprise Linux (RHEL) 8.x and earlier and Ubuntu 20.04 won’t be smacked by it. RHEL 9.x and Ubuntu 22.04, however, are a different story. They do use OpenSSL 3.x.
If you’re a Linux user, you can check your own system by running the shell command:
# openssl version
In my case, my laptop in front of me is running Debian Bullseye, which uses OpenSSL 1.1, so this machine is good.
But, if you’re using anything with OpenSSL 3.x in — anything — get ready to patch on Tuesday. This is likely to be a bad security hole, and exploits will soon follow. You’ll want to make your systems safe as soon as possible.