How to track CVE vulnerability files in Tanzu Application Services

Products

• VMware Tanzu Application Service
• VMware Tanzu Platform
• Vmware Tanzu Platform - SM
• VMware Tanzu Platform Spring
• VMware Tanzu tc Server

Issue/Introduction

CVE scans might report .jar files that are vulnerable to certain exploits. The vulnerability scan typically reports files per Diego Cell, rather than per application. This KB provides steps to gather all application GUIDs, write them into a script, then query Garden on the reported Diego Cell to examine the filesystem on each application container. 

Environment

This procedure is applicable to tiles managed by Tanzu Application Service deployed on Diego Cells.

Cause

Because vulnerability scanners query the Diego Cell filesystem, they do not report the application impacted by each CVE reported that relates to a specific .jar file. This makes it difficult to correlate the CVE with individual applications.

Resolution

The below example is used to find example vulnerability file presented on the Diego Cell here: "/home/vcap/app/BOOT-INF/lib/spring-cloud-core-3.1.3.jar"

 

1. Use bosh ssh command to SSH into one of the Diego Cells in the vulnerability scan reported to contain the vulnerable file.
2. From an SSH into the impacted Diego cell, gather the App name, Org name, Diego Cell IP, and app GUID, sorted by Diego Cell IP so you know which apps are running on which nodes:
   
   # cfdot actual-lrps | jq  '{diego_cell: .address, org: .metric_tags.organization_name, app_ame: .metric_tags.app_name, guid: .instance_guid} | join (",")' | sort
   
   
   
3. From SSH into a Diego cell we know is presenting the CVE scan failure, create a local file with all containerIDs. This will be used in later steps:
   
   # /var/vcap/packages/runc/bin/runc --root /run/containerd/runc/garden list | tail -n+2 |  awk '{print $1}' | egrep -v "envoy|liveness" > local_containerIDs.txt
   
   
   
4. Use a for loop to reference the local_containerIDs.txt to build out a script we can run to identify containers, by ID, that are using the problem jar files:
   
   # for c in $(cat local_containerIDs.txt); do echo "echo $c"; echo /var/vcap/packages/runc/bin/runc --root /run/containerd/runc/garden exec -t $c /bin/ls /home/vcap/app/BOOT-INF/lib \| grep spring-cloud; done > container_commands.sh

NOTE: In the above command, the highlighted "/bin/ls /home/vcap/app/BOOT-INF/lib \| grep spring-cloud" section is using "/bin/ls" to list all files in the "/home/vcap/app/BOOT-INF/lib" directory and searching for any hits that match "spring-cloud". The grep entry can be changed from "spring-cloud" to another name if you are searching for a different .jar file.
   
   
   
5. View the container_commands.sh file to confirm the echo for each container prior to the "/var/vcap/packages/runc/garden exec" command. This script can be run from the Diego cell to view the containers and search for the problem .jar file:
   
   # cat container_commands.txt

echo 0580b037-43dd-4d60-477a-60a1
/var/vcap/packages/runc/bin/runc --root /run/containerd/runc/garden exec -t 0580b037-43dd-4d60-477a-60a1 /bin/ls /home/vcap/app/BOOT-INF/lib | grep spring-cloud

echo 1b8a9f12-df06-495e-7c18-9c74
/var/vcap/packages/runc/bin/runc --root /run/containerd/runc/garden exec -t 1b8a9f12-df06-495e-7c18-9c74 /bin/ls /home/vcap/app/BOOT-INF/lib | grep spring-cloud


NOTE: The script is required in order to echo the containerID with the files reported in the garden exec command output in order to correlate the files with the container they're running in.
   
   
   
6. You will have to chmod the script to make it executable, then you can run it:
   
   # chmod +x container_commands.sh
# ./container_commands.sh

 

The output of the container_commands.sh script will list the container by ID, along with any matches for the jar file. These can be compared against the cfdot atcual-lrps command run in Step2 to identify the impacted application.