This is an up-date to the blog post “Using Sysdig Secure to Prepare for the November 2022 OpenSSL Vulnerability”. We have included a new section to cover how to detect and prioritize mitigation of the newly released OpenSSL 3.0.7 patch.
For more information about the OpenSSL vulnerabilities fix, see our blog posts from the Sysdig Threat Research Team 5 Steps to Stop the Latest OpenSSL Vulnerabilities: CVE-2022-3602, CVE-2022-3786 and How the Critical OpenSSL Vulnerability may affect Popular Container Images.
The awaited OpenSSL 3.0.7 patch was released on Nov. 1. The OpenSSL Project team announced two HIGH severity vulnerabilities (CVE-2022-3602, CVE-2022-3786), which affect all OpenSSL v3 versions up to 3.0.6. These vulnerabilities are remediated in version 3.0.7, which was released Nov. 1. The vulnerabilities fixed include two stack-based buffer overflows in the name constraint checking portion of X.509 certificate verification.
See below how you can use Sysdig Secure to look for the vulnerable container images using the reporting capabilities and how to prioritize mitigation by identifying containers with openssl vulnerability CVE-2022-3602 and CVE-2022-3786 in active packages at runtime.
How to detect CVE-2022-3602 & CVE-2022-3786 using Sysdig Secure
Let’s see how easy it is to find containers impacted by CVE-2022-3602 and CVE-2022-3786 (OpenSSL 3.0.7 patch) with Sysdig Secure.
On Sysdig Secure Home view, in the ToDo Recommendation box on the bottom left, under Sysdig Alerts tile, you will find the recommendation “How are you affected by the OpenSSL 3 vulnerability?.” Select it to see details and click on the “Generate Report” box in the top right corner to open a new report window. See the screenshot below:
Alternatively, you can also generate a new report by selecting on the side menu Vulnerabilities > Reporting (see screenshot)
Then, select the “Add report” button.
On the New Report view, fill the fields as follows to generate a report of container images impacted by CVE-2022-3602 and CVE-2022-3786 :
The filtering is done for the container images that have the vulnerability IDs CVE-2022-3602 and CVE-2022-3786, and it is executed against all the infrastructure.
You can customize the scheduled frequency, set it to daily, and select preferred choice for notification (email, slack, webhook).
The report can also be manually generated by selecting the report in the “Vulnerability” -> “Reporting” section and pressing the “Generate now” button:
After a few seconds (depending on your environment), the report will be ready to download.
The CSV file contains all the available information including the image name, version, and Kubernetes context (K8S cluster name, K8S namespace name, K8S workload type, K8S workload name & K8S container name).
The CSV file can be opened with LibreOffice for example.
Using the legacy engine
If using the legacy engine, the steps are quite similar (see the official documentation for more information). The report is created in the “Vulnerabilities” -> “Scheduled reports” section, and then specify the vulnerability ID in the data field as:
Prioritize Mitigation of CVE-2022-3602 & CVE-2022-3786 Using Sysdig Secure Risk Spotlight
Only vulnerabilities that are tied to packages used at runtime offer a real chance of exploitation. Risk Spotlight uses deep visibility into containers to identify and prioritize vulnerable packages loaded at runtime. These are the ones that should have your immediate attention for mitigation.
Risk Spotlight prioritization is straight forward. From the side menu, choose “Vulnerabilities > Runtime” to see all your containers in production. Next, select the container of interest.
Select the “Vulnerabilities” tab. Search for the vulnerability IDs CVE-2022-3602 and CVE-2022-3786. Filter packages used at runtime by selecting the “in-use” filter on the top menu.
By knowing what is exposed and what isn’t, Risk Spotlight removes the noise and guesswork so your team can focus on really important issues that can’t wait.
To know more about Risk Spotlight check our blog Eliminate noise and prioritize the vulnerabilities that really matter with Risk Spotlight.
The following is our original article posted on October 29, 2022 “Using Sysdig Secure to Prepare for the November 2022 OpenSSL Vulnerability”.
A critical vulnerability with an expected high or critical severity rate of CVSS score is about to be announced on Nov. 1 on the OpenSSL project. There are still no details besides an announcement on the OpenSSL mailing list on Oct. 25, that says:
Hello,
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 3.0.7.
This release will be made available on Tuesday 1st November 2022 between
1300-1700 UTC.
OpenSSL 3.0.7 is a security-fix release. The highest severity issue
fixed in this release is CRITICAL:
https://www.openssl.org/policies/general/security-policy.html
Yours
The OpenSSL Project Team
Code language: JavaScript (javascript)Given the criticality rating of the vulnerability, the commonality of OpenSSL, and prior history of broadly impacting OpenSSL vulnerabilities, it is a good idea to be prepared to update your software as soon as possible.
It is not clear if it will affect just the OpenSSL binary or the OpenSSL libraries as well, and may also be nested or transitive within other dependencies. So, expect more instances of it than what’s immediately obvious. To make things more complicated, different Linux distributions use different names for the OpenSSL libraries, such as libssl for Debian-based distributions or openssl-libs for RPM-based ones.
This article provides guidance on how you can use Sysdig Secure to generate an inventory of container images that contain OpenSSL within your environment that can be useful for executive reporting or prioritizing and aligning the teams for the inevitable remediation work.
Preparation work
The CVE ID hasn’t been disclosed yet, however, you can use the reporting capabilities to look for specific vulnerable packages and versions in your environment.
As mentioned before, different Linux distributions use different names for the OpenSSL libraries, such as libssl for Debian-based distributions or openssl-libs for RPM-based ones. To cover all the cases, you should generate two different reports: one for the package names that contains “openssl” and another for the package names that starts with “libssl.” See the official documentation for more information on how to create reports.
Let’s create a report to look for OpenSSL packages that can be affected (version 3) by going to “Vulnerability” -> “Reporting”
Then select the “Add a report” button:
The report we are looking for is as follows:
We want to use the conditions to show the container images that have a package name that starts with OpenSSL and a package version that starts with 3. You can customize the scheduled frequency, set it to daily, and select preferred choice for notification (email, slack, webhook).
As explained before, the vulnerability only affects versions 3.0.X
Then, we can press the ‘Preview’ button to show a preview of the report.
The report can also be manually generated by selecting the report in the “Vulnerability” -> “Reporting” section and pressing the “Generate now” button:
After a few seconds (depending on your environment), the report will be ready to download:
The CSV file can be opened with LibreOffice for example to get all the details.
Using the legacy engine
If using the legacy engine, the steps are quite similar (see the official documentation for more information). We should prepare similar reports, one for the package name “openssl” and another one for the package name “libssl.”
This time, the report is created in the “Vulnerabilities” -> “Scheduled reports”
Then select the “Add a report” button:
Fill in the data as previously explained, but this time, the condition is to filter the images that contain the package named “OpenSSL.” Here are the three simple steps to apply:
- Create report
- Add condition (package name only, the package version can be filtered in the CSV/JSON file directly):
- Preview and Save
Once scheduled and executed, it will be sent to the email you configured and be available for download.
In this case, it is a CSV file (it can be a JSON file) that contains all the available information, including the image name, version, and Kubernetes context (K8S cluster name, K8S namespace name, K8S workload type, K8S workload name & K8S container name).
The CSV file can be opened with LibreOffice, for example, to get all the details and filter by the package version desired:
We will keep the content updated as more information becomes available.