Docker/Kubernetes Part 2: Vulnerability Attribution

We recently conducted a study of the vulnerabilities associated with two of the most prominent names in containerization – Kubernetes and Docker. Last time, we shared some of our observations related to exploits in the wild. Before we can share other insights, we have to take a little time to explain how we identified vulnerabilities as being related to Kubernetes or Docker.

The Common Vulnerabilities and Exposures (CVE) list maintained in the National Vulnerability Database (NVD) coordinated between NIST and the MITRE Corporation has now been around for over 20 years. Part of what the list provides is Common Platform Enumeration (CPE) information that makes it easier to identify vulnerabilities related to particular operating systems or applications. It seemed that making use of CPE information would be a straightforward way to identify Kubernetes and Docker relevant vulnerabilities; however, it turns out that these technologies are sufficiently new and insufficiently well understood that looking at CPE information alone was inadequate.

For this study, we focused on Docker and Kubernetes vulnerabilities within the named cohorts CVE-2014-xxxx thru CVE-2020-xxxx that were published through the end of calendar year 2020. Docker/Kubernetes-related vulnerabilities were identified in a multi-step process involving three steps:

2) examine all CVE records for the presence of “docker” or “kubernetes” somewhere in the CPE information, e.g., cpe:2.3:a:google:kubernetes:-:*:*:*:*:*:*:*

3) take the results from steps 1 & 2 and manually examining the CVE description in the NVD as well as many of the referenced advisories, solutions, and tools linked from the corresponding CVE’s NVD page.

Identification of relevant Docker and Kubernetes vulnerabilities is a bit trickier than identification of vulnerabilities related to other products (e.g., Microsoft). There are several reasons for this which include difficulty in determining if there is a problem in the project technology (Docker or Kubernetes) or in someone’s use of that technology (e.g. Docker image with a blank password) or in a particular implementation of that project (e.g. RedHat’s OpenShift or Rancher’s Kubernetes enterprise distributions). Below are three brief examples that illustrate the problem of easily identifying Docker/Kubernetes-related vulnerabilities and understanding what exactly is causing the problem.

Example 1
CVE-2016-1906, cpe:2.3:a:kubernetes:kubernetes:-:*:*:*:*:*:*:*

CVE-2015-5305, cpe:2.3:a:redhat:openshift:3.0:*:*:*:enterprise:*:*:*

These CVEs have a single CPE entry apiece that does not make it clear how closely related they are, nor what group is ultimately responsible for dealing with fixing the security problem. It turns out that on Kubernetes’ GitHub, both CVEs are identified in a manner opposite to what the CPEs indicate:

“CVE-2016-1906 is OpenShift-specific, fixed in openshift/origin#6576 (OpenShift v1.1.1)”

“CVE-2015-5305 was fixed in #15975 (Kubernetes v1.2.0)”

Example 2
CVE-2020-15257, cpe:2.3:a:linuxfoundation:containerd:*:*:*:*:*:*:*:*

Example 3
CVE-2018-8115, cpe:2.3:a:microsoft:windows_host_compute_service_shim:*:*:*:*:*:*:*:*

This CVE has over 50 CPE entries, but all simply enumerate various versions of the windows_host_compute_service_shim. This Docker for Windows vulnerability did not show up in our combined keyword and CPE search because Docker is referenced in neither the description nor in the CPE entry.

Per MITRE, CPE was developed to fill the “need to refer to IT products and platforms in a standardized way that is suitable for machine interpretation and processing.” However, the system is only as good as the data provided and it may take a while to mature the way in which Docker and Kubernetes CVEs’ CPE information is created.

Of the CVEs published through 4 January 2021, we found 105 Kubernetes-related CVEs and 138 Docker-related CVEs using search criteria 1 & 2 above. During the scrub process (step 3), we categorized each vulnerability into one of four groups: relevant, partly relevant, configuration/implementation-related, not related. There was a certain amount of subjectivity involved in the scrub/grouping process and reasonable people might disagree with the group designations we made for some of the CVEs; however, we think it was an important step and key to understanding where weaknesses lie in the enumeration of the Kubernetes/Docker vulnerabilities landscape.