By Guest Author Teja Myneedu, Director—Product Security Engineering and Research, TripActions
OpenSSL is a commonly used cryptographic toolkit widely used for SSL/TLS across web-based applications. The OpenSSL project routinely releases bug fixes and patches without prior warning. So, when they forewarned everyone about an upcoming patch release that had a fix for a CRITICAL severity vulnerability, most technology businesses were concerned about a widespread breakdown in Internet security and the impact to their application security and product. When the patch for the OpenSSL vulnerability (CVE-2022-3602, CVE-2022-3786) was released on Tuesday, November 1, it turned out to be much lower risk than originally thought. This is because the buffer overflow vulnerabilities which were fixed in version 3.0.7 are not only hard to exploit, they also affect a much smaller percentage of OpenSSL implementations because most applications use an earlier version of the software. So, the good news is that it is unlikely that most software products and applications are affected by the OpenSSL vulnerability. However, Deepfactor recommends identifying affected versions of OpenSSL and patching them with OpenSSL 3.0.7 or later as soon as possible.
How do you know whether you are affected by CVE-2022-3602 or CVE-2022-3786?
Most developers might not realize that OpenSSL powers the underlying execution when they use a library in their code to perform any cryptographic operations like hashing, or encryption. This is because OpenSSL is commonly shipped as an operating system package and programming languages use a library as a wrapper. PyOpenSSL is a good example. In order to check whether you are affected by this, these are the different places you need to check:
- the Host Operating Systems within your infrastructure
- the Docker base images you use within your infrastructure
- the programming languages you use which might in turn use the underlying OpenSSL library on the operating system
NCSC-NL has published this list of affected/not-affected software that is worth consulting.
Manually checking for the newly released OpenSSL vulnerability can consume many hours of engineer, QA, and application security teams’ time, which is why it is important for organizations to have automated security tooling that can identify, prioritize, and help engineering teams remediate vulnerabilities in their operating system packages and dependencies.
Using Deepfactor to quickly and precisely validate if you are affected
With Deepfactor, you can quickly search for all packages and dependencies installed in your application by using the search feature as part of the Software Bill Of Materials (SBOM) to identify if a vulnerable version of the OpenSSL package is installed.
Using the Deepfactor Dynamic SBOM capability, engineering teams can identify if the vulnerable library is loaded and being used by any applications. In the example below we can see that the libcrypto and libssl libraries were loaded by the application, which helps developers prioritizing remediation efforts.
How do you protect yourself against attackers exploiting this vulnerability?
The simplest way to protect yourself against exploit attempts using this vulnerability is by upgrading all your OpenSSL 3.0.x packages to version 3.0.7. If your host operating system is affected, you should run a package-update or update the base OS image. Alternatively, if your Docker image is affected, you should update the base Docker image.
Deepfactor Free OpenSSL Risk Assessment
If you do not have automated security tooling capable of identifying vulnerable OpenSSL packages, Deepfactor offers a free 60-minute risk assessment with a complete Software Bill of Materials (SBOM) report that includes supply chain risks such as vulnerable dependencies, OS packages, and container images. The report will provide detailed information about which libraries and packages were loaded by each component of the application, helping to accelerate remediation of the OpenSSL vulnerability.