The OpenSSL project this week announced plans to release version 3.0.7 on November 1 to patch a critical security flaw affecting versions 3.0 and later. Co-founder Mark J. Cox noted it’s only the second critical patch “since we started rating flaws back in 2014.”
OpenSSL identifies critical issues as those affecting common configurations and likely to be exploitable, with examples including “significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys or where remote code execution is considered likely in common situations.”
ANALYGENCE senior vulnerability analyst Art Manion’s observed that November 1, All Saints’ Day, is unfortunately a public holiday in several EU countries, and Cox conceded, “We didn’t realize that. It’s pretty hard to avoid every holiday everywhere.”
See the Top Code Debugging and Code Security Tools
What to Do About OpenSSL Now
Software developer Carlos Solís asked, “So what temporary measures should be applied to our servers while the embargo is lifted?” Cox bluntly responded, “We’ve not provided any other information at the time.”
Still, Sophos researchers suggested one crucial step to take before next Tuesday, advising, “All users of OpenSSL should use this time to inventory instances of OpenSSL and prepare for immediate patching when this is released.”
Cox agreed: “This is good advice. If you know in advance where you are using OpenSSL 3.0+ and how you are using it then when the advisory comes you’ll be able to quickly determine if or how you’re affected and what you need to patch.”
To assist in that process, SANS dean of research Johannes B. Ullrich has posted a list of the OpenSSL versions for more than 25 operating systems, noting, “MacOS, by default, uses LibreSSL, not openssl installed. But openssl may be installed later by other software like Homebrew and MacPorts.”
Also read: Is the Answer to Vulnerabilities Patch Management as a Service?
The Next Heartbleed?
Venafi container product lead Mattias Gees said the announcement calls to mind highly impactful flaws like Heartbleed and Log4Shell. “Heartbleed had a significant impact on all operations teams worldwide, and since then IT infrastructure has become 10 times more complicated,” he said.
“When Heartbleed was discovered, the majority of IT organizations were using dedicated hardware or virtual machines (VMs),” Gees said. “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.”
Organizations that have already audited their dependencies in response to Log4Shell, Gees said, will be well-positioned to roll out a fix as efficiently as possible.
The fact that the flaw only impacts version 3.0 and later, he added, should at least limit its potential impact. “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.”
Read next:
