OpenSSL is a widely-used open-source software library for implementing secure communications over computer networks. How widely used? Well, chances are that if you’ve ever accessed an HTTPS web page you did so over an OpenSSL encryption. The library provides cryptographic functions and protocols for data encryption, decryption, authentication, and digital signature verification. OpenSSL can be found almost anywhere where there’s a need to secure web servers, email servers, virtual private networks (VPNs), and other types of network communication.
Looking at the paragraph above it should be clear how important OpenSSL is to the proper work of the internet. It is a critical component of the security infrastructure for many computer systems and applications. It helps to protect sensitive data from unauthorized access and helps to ensure the integrity and authenticity of network communications. That’s why the maintainers of the library take vulnerabilities very seriously and attempt to patch them as soon as possible. Imagining attackers gaining access to the secure communication lines of the world wide web infrastructure is almost unthinkable.
In this article, we’ll examine the vulnerabilities that prompted the OpenSSL patch 3.0.7 on October 2022, and look at what we can learn from the way the OpenSSL maintainers took care of the issue.
The Vulnerabilities
On October 25th, 2022, the OpenSSL Project published an advisory warning that a new patch will be coming soon to deal with some critical vulnerabilities. The ‘critical’ tag implies that the vulnerabilities are likely to be exploitable and that the stealing of private keys and/or RCE on affected servers is likely.
A week later, on November 1st, 2022, the OpenSSL Project released both the new patch, 3.0.7, and the specific vulnerabilities they were aiming to fix. In the intervening time, the rating of the vulnerabilities has been downgraded from critical to ‘high severity’.
So, what are these vulnerabilities?
CVE-2022-3602 – X.509 Email Address 4-byte Buffer Overflow – In X.509 certificate verification, specifically in name constraint checking, a buffer overrun of four bytes can occur. Four attacker-controlled bytes on the stack can be overflowed by an attacker using a malicious email address. A crash (resulting in a denial of service) or potentially remote code execution could be caused by this buffer overflow. Initially, it was categorized as critical but additional testing showed that numerous platforms use stack overflow safeguards to reduce the risk of remote code execution.
CVE-2022-3786 – X.509 Email Address Variable Length Buffer Overflow – In X.509 certificate verification, specifically in name constraint checking, a buffer overrun can occur. An attacker can create a malicious email address in a certificate to fill up the stack with any number of bytes that contain the character “.,” which is the decimal number 46. A crash might occur as a result of this buffer overflow (causing a denial of service).
Just to reiterate how serious these vulnerabilities are, CISA, the U.S. Cybersecurity, and Infrastructure Security Agency, released an advisory the very same day as OpenSSL, encouraging users and administrators to review the OpenSSL documentation and upgrade, where applicable, to the new patch 3.0.7.
As discussed earlier, RCE (remote code execution) on operating systems or mail servers running OpenSSL would be very bad so it makes sense to only reveal the vulnerabilities once a proper patch has been found and offered.
What Happens Next
As soon as the initial advisory was published people began scrambling. ‘Don’t panic’ was a common phrase at the time showing just how seriously people took the news that OpenSSL has critical vulnerabilities.
As soon as the advisory was published all relevant stakeholders were clambering to figure out what version of OpenSSL was used in their server, OS, application, package, etc. Beyond just internal OpenSSL usage, people also needed to figure out if any of their 3rd party vendors or service providers were using a vulnerable OpenSSL version. At the time, if you weren’t sure which version you were using or you weren’t sure which version your vendors and service providers were using, it was deemed safer to take an application offline rather than risk potential RCE.
Since the advisory gave the timeline for the patch in advance that gave people the time to figure their own infrastructure and that of their vendors and service providers out. The idea was to plan everything needed in terms of the infrastructure involved so that as soon as the patch was released, the upgrade, if needed, could take place.
How Would You Handle It?
Now let’s say that you are an engineer in a company that as far as you know uses OpenSSL in its servers. As soon as the advisory drops you need to figure out which version of the library is in use where (including any legacy code if it’s still being run) and then figure the same thing for any of your vendors or service providers.
This is where an SBOM could really come in handy. An SBOM stands for a Software Bill Of Materials and It is a list of all the components and software dependencies that make up a particular software product. An SBOM typically includes information such as the names and versions of all software components (see where I’m going with this), their sources and licenses, and any known vulnerabilities or security issues associated with each component.
If you, as the responsible engineer that you are, made sure to have an updated SBOM for each of your products then finding where you were using OpenSSL and which version was in use would have been a simple matter of running a search on the SBOM file. If you also made sure to ask for updated SBOMs from any vendor or service provider your company was working with you could have done the same search there as well.
Since you were told that the vulnerabilities were only affecting versions between 3.0.0 and 3.0.6, all you have to do is check which versions you were running to know which applications needed to be taken down or updated with the new patch – 3.0.7.
Just to show how extensive the list of well-known operating systems and enterprise applications using OpenSSL is, check out this list published as a public service so that people would know how worried they should be.
How can an Evidence-Based Security Hub Can Help
As part of the evolving cybersecurity landscape, including such far-reaching vulnerabilities, we are currently witnessing the evolution of Application Security to Software Supply Chain Security. A new generation of tools and technologies has been developed to try to solve these problems. By offering an evidence-based continuous code security assurance platform that can vouch for the dependability of the software development life cycle and software components, automated tools and solutions assist organizations in achieving a new level of security. Continuously mapping out dependencies and vulnerabilities makes it simpler to remediate or apply patches when they become available.
Scribe is a Software Supply Chain Security hub. It gathers proof and presents it for every build that goes through your CI/CD pipeline. The goal of Scribe’s solution was to make it easier to adhere to EU and U.S. regulations and best practices for enhancing software transparency and fostering trust between software developers and users. The platform makes it possible to create and share comprehensive SBOMs as well as other security insights. Additionally, the platform can confirm that the build you are viewing complies with both NIST’s SSDF framework and SLSA level 3 requirements. You no longer have to fumble around trying to figure out where you’re using what version of what library because you have an evidence store with an SBOM for each of your builds. Now, figuring it out is as simple as looking for a particular sentence in a text document.
A Final Word: Be prepared for the next big vulnerability disclosure
The OpenSSL Project story of patch 3.0.7 offers us two, equally important, points of view about how to deal with potentially critical vulnerabilities.
From the affected side – the company or project that was potentially compromised by these vulnerabilities, we have informed transparency. They do not immediately disclose information that might cause harm, but they do disclose whatever they can as soon as they are aware of a problem. Not only that they also offer a timeline for remediation in addition to as much information about the problem as possible. Once a patch or remediation exists they were not shy about disclosing exactly what was wrong and how it could potentially be exploited. This kind of transparency encourages trust. Users and clients want to know and feel that the company cares about them more, or at least as much, as it does for the bottom line or its board of directors.
In 2014 the OpenSSL project fell victim to a critical bug dubbed ‘HeartBleed’ – a critical flaw in OpenSSL’s TLS/DTLS implementation that made it possible for an attacker to obtain secrets like encryption key material, passwords, and other sensitive information from affected servers. Heartbleed showed what a critical vulnerability in OpenSSL can do as it affected a wide variety of programs and Linux distributions. Trying to identify and fix every vulnerable system gave security teams months of headaches. Implementing a tool, like an SBOM, that could make it faster and simpler to update and patch your software would be a boon to any company’s cybersecurity team.
From the remediating side – knowing exactly what you have to work with – which version of what packages you’re using where is essential to being able to handle any such potential emergency. Taking Log4J as an example – some companies are still trying to figure out whether or not they’re affected by this vulnerability more than a year after it was discovered.
The fact that it’s not just your software and servers you need to worry about, it’s also those of any third-party vendors you’re using, or any service providers you’re working with, even using API connections, means that we, all of us, really need to build a web of trust between us. Such trust should depend as much as possible on hard evidence. Create and track your own SBOMs and those of any company you’re in business with, share those SBOMs, and show good faith in announcing and fixing any exploitable vulnerability you become aware of.
It would take all of us working together to get to a world where sharing such evidence is as commonplace as sharing the company’s latest PR on social media. Without this trust, we’re just setting up the stage for the next big critical vulnerability to break apart the interconnected infrastructure we all work so hard to maintain.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
