This is a work-in-progress blog post. It will be updated when more information is available.
For more detailed information about the vulnerability, see the How the Critical OpenSSL Vulnerability may affect Popular Container Images blog post.
A critical vulnerability with an expected high or critical severity rate of CVSS score is about to be announced on November 1st on the OpenSSL project. There are still no details besides an announcement on the OpenSSL mailing list on October 25th 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
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 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.
OpenSSLv3 is also included in Node.j v18.x and v.19.x package versions, and may also be nested or transitive within other dependencies, so expect more instances of it than what’s immediately obvious.
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 2 different reports, one for the package names that contains “openssl” and another one for the package names that starts with “libssl”. See the official documentation for more information on how to create reports.
To reveal affected Node.js packages, you should generate additional reports, one for package name equal to “Node.js” and version that starts with “18” and another one for package name equal to “Node.js” and version that starts with “19”.
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 contains OpenSSL and the package version 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:
In this case, it is a CSV file (it can be a JSON or NDJSON file) that contains all the available information including the image name and version as well as the 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.
Remember this example was just for the OpenSSL package, it would be required to create other similar reports for the libssl and Node.js packages explained before.
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”, one for the package name “libssl”, and one for package name “Node.js”.
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 simple 3 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 as well as available to be downloaded.
In this case, it is a CSV file (it can be a JSON file) that contains all the available information including the image name and version as well as the 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.
The post Using Sysdig Secure to prepare for the November 2022 OpenSSL Vulnerability appeared first on Sysdig.
Article Link: Using Sysdig Secure to prepare for the November 2022 OpenSSL Vulnerability – Sysdig