High/Critical Stack CVEs from TAS/TAP Customer Scans

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

Customers of TAS and TAP deployments may be concerned about CVEs in the stack images that their various scanners discover. In many cases, this may include high/critical CVEs, but when investigated, they are not usually affected components.

In TAS, CVEs show up in:

• - cflinuxfs3
• - cflinuxfs4

In TAP, CVEs may show up in:

• - Tanzu Jammy Tiny stack / VMware Tanzu Tiny Stack for Ubuntu 22.04
• - Tanzu Jammy Base stack / VMware Tanzu Base Stack for Ubuntu 22.04
• - Tanzu Jammy Full stack / VMware Tanzu Full Stack for Ubuntu 22.04
• - Tanzu Bionic Tiny stack / VMware Tanzu Tiny Stack for Ubuntu 18.04
• - Tanzu Bionic Base stack / VMware Tanzu Base Stack for Ubuntu 18.04
• - Tanzu Bionic Full stack / VMware Tanzu Full Stack for Ubuntu 18.04

Resolution

Cause

The versions of packages that are shipped in the Tanzu stack offerings are Ubuntu OS version-specific, and oftentimes are NOT the same version as the version listed to have a fix in a generic, non-Ubuntu, CVE database. Using a generic CVE database will lead to CVEs that are being flagged as vulnerabilities that are actually FALSE POSITIVES since the scanners are not using Ubuntu-specific CVE data.

Here is an example describes the issue in more detail:

• - CVE-2022-32207 is CRITICAL in severity and showed up in a customer scan of the
• - latest release of the VMware Tanzu Base Stack for Ubuntu 22.04, but it was not actually vulnerable at all.
• - NVD (https://nvd.nist.gov/vuln/detail/CVE-2022-32207) marks this CVE as exploitable in versions of the `curl` package less than `7.84.0`.
• - By this information, the CVE would definitely show up as vulnerable, since we shipped curl `7.81.0-1ubuntu1.15` in the stack.
• - The Ubuntu-specific CVE information (https://ubuntu.com/security/CVE-2022-32207) for this CVE shows that it was resolved in `7.81.0-1ubuntu1.3` of `curl` on Ubuntu Jammy.
• - As a result, this CVE is not vulnerable, and the customer scanner provided a FALSE POSITIVE

Resolution

The first step in resolving stack-related CVEs for customers should ALWAYS be to upgrade to the latest version of the stack available.

The latest stack available to users in both TAS and TAP should always have the most up-to-date packages available from Ubuntu at the time of publishing. The buildpacks team releases new stacks whenever there are updates to the packages, by continuously polling upstream Ubuntu USN feeds and releasing stacks with the updated packages.

If a high/critical CVE still shows up in the latest stack release:
The next step would be to check the Ubuntu-specific page (https://ubuntu.com/security/<CVE ID>) for the CVE as described in the example in the Cause section.
Scrolling to the bottom of the Ubuntu page, there will be information about the package in each specific Ubuntu version.

If the CVE has a fix for the OS version (jammy, for example), we can always double check that we are definitely shipping that package version in the stack.

If the customer wants to quickly check this themselves, they can do so by running `dpkg -l | grep <package name>` on the stack image.

As mentioned, if there is a fix available for our OS version, ideally we will have already shipped a release. If for some reason this is not the case, please let the Buildpacks team know as soon as possible, so that we can patch the CVE.

In some cases, the CVE may not have a fix yet in the OS version we are interested in according to Ubuntu. In this scenario, the CVE may be vulnerable, but the Buildpacks team cannot fix the CVE until there is an upstream fix.

An example of this scenario can be observed at https://ubuntu.com/security/CVE-2020-27752. For Ubuntu Bionic, the CVE fix is listed as “Deferred”, meaning that it has not been fixed upstream. Therefore, this CVE is potentially exploitable but cannot be fixed in the stacks.