All Products
Search
Document Center

Container Service for Kubernetes:Vulnerability fixed: CVE-2020-15257

Last Updated:May 18, 2023

The containerd community disclosed the GHSA-36xw-fx78-c5r4 vulnerability. The Common Vulnerabilities and Exposures (CVE) identifier of the vulnerability is CVE-2020-15257. If a container shares the same networking namespace with the host and the UID of the container is 0, attackers can use the containerd-shim API to control containerd-shim processes in the host and launch attacks with elevated privileges. This topic describes the impacts, causes, and preventive measures of the vulnerability.

The severity of the CVE-2020-15257 vulnerability is medium and the Common Vulnerability Scoring System (CVSS) score of the vulnerability is 5.2.

Impacts

The containerd community has fixed the vulnerability in containerd 1.3.9 and 1.4.3. All clusters of Container Service for Kubernetes (ACK) are affected by this vulnerability. To query pods that use host networking, run the following kubectl command:

kubectl get pods -A -o json |
  jq -c '.items[] | select(.spec.hostNetwork==true) |[.metadata.namespace, .metadata.name]'

Vulnerability description

containerd and containerd-shim communicate with each other by using abstract sockets. If a container is in the same networking namespace as the host with a UID of 0, attackers can access containerd-shim processes in the host as a root user. Consequently, the attackers can escape the container and use the containerd-shim API to launch attacks with elevated privileges.

Note
  • As a runtime of Kubernetes clusters, containerd manages underlying runC containers. containerd includes a daemon and exposes gRPC service interfaces through on-premises UNIX sockets. This way, containerd can manage container lifecycle.

  • containerd-shim is a component of containerd. It is used to isolate the daemon of containerd and container processes. You can call runC interfaces through containerd-shim to manage your containers.

Preventive measures

To minimize the probability of privilege escalation attacks, you must run your applications in the following five core namespaces: Net, Mount, IPC, PID, and UTS. The more you share the namespace of the host with containers, the higher the probability of being attacked. Avoid using the host networking mode in a pod. You can restrict the use of the host networking mode in the following ways:

  • Enable the Pod Security Policy (PSP) feature. You can set the hostNetwork parameter in a PSP to prevent pods in a specified namespace from using host networking. ACK allows you to configure PSPs in the ACK console. For more information, see Configure and enforce ACK pod security policies.

  • Install the gatekeeper component. For more information about the component, see gatekeeper. For more information about how to install the component, see Example of open policy agent.

If you need to use the host networking mode, we recommend that you start your containers as a non-root user by setting the securityContext parameter in the pod. Then, set the allowPrivilegeEscalation parameter to false. The following code block is an example:

hostNetwork: true   #Your containers must use host networking due to business requirements.
containers:
- name: foo
  securityContext:
    runAsUser: 12345
    allowPrivilegeEscalation: false