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. 

DockerKubernetes Part 2  Vulnerability Attribution

 

The Common Vulnerabilities and Exposures (CVE) list maintained in the National Vulnerability Database (NVDcoordinated 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: 

1) search the CVE website with keywords:  Docker, Kubernetes, and Kubelet; e.g. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=docker 

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-1906cpe:2.3:a:kubernetes:kubernetes:

CVE-2015-5305cpe: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-15257cpe:2.3:a:linuxfoundation:containerd

This CVE has over 40 CPE entries, but all are for different versions of containers and none include Docker or Kubernetes – those projects are only mentioned in the CVE description.  If running Docker containers with docker run –net=host or running Kubernetes Pods with .spec.hostNetwork: true, then this CVE is a problem; otherwise, it is not. 

Example 3 

CVE-2018-8115cpe: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. 

 

Kubernetes 

Docker 

Relevant 

40 

49 

Partly relevant 

7 

5 

Configuration/distribution 

51 

*62 

Not related 

7 

23 

Total 

105 

*139 

*NOTE:  The Docker for Windows vulnerability (CVE-2018-8115) mentioned above was discovered during the scrub process (step 3) and is included in the following analysis. 

For the purposes of evaluating the identified vulnerabilities, we combined the relevant and partly relevant CVE groups, kept the configuration/implementation-related CVEs separate, and excluded the CVEs that we determined were not closely related despite the explicit mention of Docker or Kubernetes somewhere in the description.  In the analysis charts in subsequent blog posts, we refer to the relevant/partly relevant groups as the platform name abbreviation, K8s or Dock, and to the configuration/distribution-related group as Kube Dist or Dock Cfg. 

Read Part 3: COVID-19 Effect 

CYR3CON helps teams prioritize vulnerabilities and prevent breaches.  Contact us today to learn how we have become the most accurate, peer-reviewed, predictor of weaponized exploits.