The OpenSSL Project, the organization that maintains the widely used OpenSSL software, has issued a vulnerability patch flagged as High severity. Prior to the announcement the release was widely briefed as being of 'Critical' severity. Whether this was industry analysts reading the runes incorrectly or whether it was clever expectation management by OpenSSL is unclear. Whichever is the correct explanation this is still a vulnerability that needs taking seriously and action needs to be taken.
Tod Beardsley, Director of Research at Rapid7 commented:
“The OpenSSL vulnerability disclosures (and fixes) are, thankfully, not nearly as bad as all the speculation would have led us to believe. Vendors and operators should update their dependencies on OpenSSL to 3.0.7 when it's practical to do so, respecting normal change control procedures and taking into account the specific risk profile for those organizations. For most people, this is not actually the emergency situation we were all expecting.
“Specifically, implementations that are configured for mutual authentication, where both the client and the server are providing OpenSSL-provided certificates for authentication, should definitely be fast-tracking this update. But, this is an unusual use case, so if you don't know if you are supporting that or not, you're probably not. For most installations, it's okay to take your time with this one.”
Original headline: OpenSSL Project issues first critical vulnerability patch since 2016
Original text:
The OpenSSL Project, the organization that maintains the widely used OpenSSL software, announced that it is issuing a critical vulnerability patch. The last time OpenSSL issued a critical vulnerability patch was in 2016.
OpenSSL is a ‘full-featured toolkit for general-purpose cryptography and secure communication’.
The OpenSSL project team says that the security-fix release (version 3.0.7) will be made available on Tuesday 1st November 2022 between 1300-1700 UTC.
Commenting on the vulnerability, Mattias Gees, Container Product Lead at Venafi, told Continuity Central:
“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 cyber security 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.”
