Aqua Blog

Vulnerabilities in the Container Ecosystem: A Brief History

April 30, 2019

Now that containers have been around for a few years and have had their share of disclosed vulnerabilities, it’s time to revisit some of the more interesting ones and see if there’s a recurring theme or any underlying trend to highlight.

We found some of the more severe CVEs disclosed during 2017-2019 that affected the container ecosystem and listed them below. For details on each CVE, continue reading.

CVE	Description	Affected System
CVE-2017-1002101	subPath Volume Mount Vulnerability	Docker
CVE-2017-16995	eBPF Vulnerability	Linux
CVE-2018-1002105	Severe Privilege Escalation Vulnerability	Kubernetes
CVE-2018-8115	Windows Host Compute Service Shim (hcsshim)	Windows
CVE-2018-11757	Docker Skeleton Runtime Vulnerability	Docker
CVE-2018-1000056	Jenkins JUnit Plugin Vulnerability	Jenkins
CVE-2019-1002100	API Server Patch Permission DoS Vulnerability	Kubernetes
CVE-2019-5736	High Severity RunC Vulnerability	Docker
CVE-2019-1003065	Jenkins CloudShare Docker-Machine Plugin Vulnerability	Jenkins

What Can We Learn from Vulnerabilities?

These CVEs demonstrate that key components in the toolchain and the stack, if vulnerable, can affect a containerized application. It’s not just the container code itself, or the container engine that may affect your security posture, but rather many elements across the stack.

These components may include:

The host OS (Linux) and its kernel
Jenkins, Docker, or any other tool involved in the process of building containers
Kubernetes, and especially its API server, which is the control point of the entire cluster

Additionally, anything you put inside a container image that is vulnerable might affect your application. Code vulnerabilities inside containers can also, potentially, have a detrimental effect on the host and the cluster. This is especially the case when combined with other CVEs, or with bad practices, such as running with root privileges.

Security by Design

In addition to the shift-left approach of dealing with security issues early in the design phase before deployment and monitoring applications in runtime, I suggest using these Aqua tools to check for vulnerabilities:

MicroScanner: A free tool used for scanning your container images for package vulnerabilities. If the MicroScanner finds a high-severity vulnerability, it returns a non-zero exit code (as well as reporting the details in JSON format), and that in turn fails the image build.
Kube-Hunter: An open-source tool that hunts for Kubernetes security issues in your clusters. It was designed to increase awareness and visibility of the security controls in Kubernetes environments.
Kube-Bench: An open-source tool that will help you configure your cluster more securely so that CVEs may have less impact. You can run it on each of your nodes to establish how well your deployment meets the best practice recommendations from the CIS community. Not only do you get information about whether each test passes or fails, but you also get advice on how to remediate any issues that have been detected.

There’s no way to prevent vulnerabilities entirely. Software has always had flaws and will continue to have them. However, we can take proactive measures to reduce their proliferation in containerized applications. We can practice security by design, both before deployment and during runtime, as an attempt to keep vulnerabilities at bay so they will occur with less frequency and have less impact.

Container Vulnerabilities and Mitigations

CVE-2017-1002101: subPath Volume Mount Vulnerability

This vulnerability allows containers using subPath volume mounts to access files or directories outside of the volume, including the host’s file system.
If exploited, it could give an attacker access to a pod and full control over the node host by gaining access to the Docker socket.

Mitigation

An update is now available for Red Hat OpenShift Container Platform 3.7, 3.6, 3.5, 3.4, and 3.3.

CVE-2017-16995: eBPF Vulnerability

This vulnerability is related to a set of security vulnerabilities in the eBPF verifier. The verifier is crucial in determining if an eBPF program is safe. It checks that the eBPF program meets certain requirements.
If the verifier passes a program that is malicious, it exposes the whole system to a great amount of risk. If the verifier fails to verify access to memory, it allows “read-write” to arbitrary kernel addresses.

Mitigation

The immediate step is to update your Linux version if a patch is available.
Disable unprivileged user ability to load eBPF programs by setting sysctl knob kernel.unprivileged_bpf_disabled to true (defaulted to 0). This way, an unprivileged user will not be able to run bpf programs and use this exploit to elevate privileges.

CVE-2018-1002105: Severe Privilege Escalation Vulnerability in Kubernetes

This vulnerability allows an unauthenticated user to perform privilege escalation and gain full admin privileges on a cluster. After a remote user exploits this vulnerability and gains admin privileges, he can take ownership of a cluster. He could perform malicious actions such as injecting malicious code into containers to exfiltrate data, mine for cryptocurrencies, or access secrets.

Mitigation

Upgrade your K8s clusters to the fixed versions. The affected versions and their fixes are:

Kubernetes v1.0.x-1.9.x – no fix available
Kubernetes v1.10.0-1.10.10 – fixed in v1.10.11
Kubernetes v1.11.0-1.11.4 – fixed in v1.11.5
Kubernetes v1.12.0-1.12.2 – fixed in v1.12.3

You can run Kube-Hunter on your network to discover whether your infrastructure is exposed to this vulnerability. It is used to discover all Kubernetes nodes in the network and to run automated penetration testing based on known vulnerabilities and exploitation techniques.

CVE-2018-8115: Windows Host Compute Service Shim (hcsshim)

In the image pull process, files from a malicious image can be extracted into any directory on the host file system. This happens as part of the image ‘unpacking’ process, where the code that processes the tar archive joins the destination directory with the file path specified in an archive.
The vulnerability is that this file path is not sanitized – a file in the image can include directory traversal (e.x. ../../../), links, etc. If exploited, the destination file can be written to an arbitrary location on the victim’s host.

Mitigation

Aqua has an open-source tool that tests images to see if they are clear of this vulnerability. You should use this if you have older versions and can’t upgrade them right away.
The tool downloads an image from a registry, without extracting it, and checks the tar archives for bad paths, links, etc.

SCAN-CVE-2018-8115 is available on GitHub ›

CVE-2018-11757: Docker Skeleton Runtime Vulnerability

In Docker Skeleton Runtime for Apache OpenWhisk, a Docker action inheriting the Docker tag openwhisk/dockerskeleton:1.3.0 (or earlier) may allow an attacker to replace the user function inside the container if the user code is vulnerable to code exploitation.
An “attacker may exploit this issue and inject and execute arbitrary code within the context of the affected application. This may aid in further attacks.”

Mitigation

Executable Python script for a proxy service to dockerSkeleton

CVE-2018-1000056: Jenkins JUnit Plugin Vulnerability

Jenkins is a popular CI tool which is often run inside of containers. It has a number of plugins, such as the Jenkins Junit. The Jenkins JUnit plugin can be affected by an XML External Entity (XXE) processing vulnerability. This allows an attacker to configure build processes such that JUnit plugin parses a maliciously crafted file that uses external entities for extraction of secrets from the Jenkins master, server-side request forgery, or denial-of-service attacks.
If this is not caught in time, an exploitation could mean privilege escalation vulnerability (SSRF), which has a negative impact on confidentiality, integrity, and availability.

Mitigation

The external entity resolution has been adjusted to avoid XXE and still satisfy the existing features.

CVE-2019-1002100: Mitigating the Kubernetes API Server Patch Permission DoS Vulnerability

This vulnerability, if exploited, could lead to a denial-of-service on the K8s API server, which in turn may lead to the cluster becoming inoperable.

Mitigation

Vulnerable versions of Kubernetes are v1.0.0-1.10.x, v1.11.0-1.11.7, v1.12.0-1.12.5, v1.13.0-1.13.3.
You can upgrade your kube-apiserver to newer versions, namely v1.11.8, v1.12.6, or v1.13.4, in which it has been fixed.
If you cannot upgrade, or until you do, the best course of action is to remove patch permissions from untrusted users, or generally from admins who don’t really use it. This is done via “verb” definitions in Kubernetes RBAC authorization.

CVE-2019-5736: High Severity RunC Vulnerability

This vulnerability allows an attacker to potentially compromise the container host. The vulnerability allows a malicious container to overwrite the host runc binary and gain root-level code execution capability on the host.

Mitigation

Patches are already available from most providers. You can prevent this vulnerability from being exploited by applying the appropriate runtime policies. Patch your systems with a new version of Docker and RunC. There is no need to patch your container images. You should only patch your hosts. We recommend Host Scanning and Container Runtime Protection.

CVE-2019-1003065: Jenkins CloudShare Docker-Machine Plugin Vulnerability

Jenkins CloudShare Docker-Machine Plugin stores credentials unencrypted in its global configuration file on the Jenkins master where they can be viewed by users with access to the master file system.

If exploited, an “attacker may leverage these issues to execute arbitrary script code in the browser of the victim in the context of the affected site, steal cookie-based authentication credentials, and gain access to sensitive information. This may aid in further attacks.”

Mitigation

Jenkins suggests this mitigation, CloudShare Docker-Machine Plugin stores credentials unencrypted in its global configuration file com.cloudshare.jenkins.CloudShareConfiguration.xml on the Jenkins master. These credentials can be viewed by users with access to the master file system.

Published under: VULNERABILITY MANAGEMENT

Tags: Container Security, Container Vulnerability

Aqua Team

Aqua Security is the largest pure-play cloud native security company, providing customers the freedom to innovate and accelerate their digital transformations. The Aqua Platform is the leading Cloud Native Application Protection Platform (CNAPP) and provides prevention, detection, and response automation across the entire application lifecycle to secure the supply chain, secure cloud infrastructure and secure running workloads wherever they are deployed. Aqua customers are among the world’s largest enterprises in financial services, software, media, manufacturing and retail, with implementations across a broad range of cloud providers and modern technology stacks spanning containers, serverless functions and cloud VMs.