This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Fixed CVEs

1 - CVE-2021-25741

Vulnerability details

This is a volume security issue related to permission access. A user can access files and directories outside the volume mounting directory, including the host’s file system, through the volume mounting method of subpath in the created container.

Scope

This vulnerability affects related behaviors of kubelet, and the issue is particularly serious for cluster administrators who may strictly restrict the creation of hostPath.

CVSS scores

This vulnerability is rated as medium-risk with a CVSS score of 5.5.

Prevention

For users who do not want to upgrade kubelet, they can use two preventative measures:

  • Disable VolumeSubpath for kubelet and kube-apiserver and remove all pods that are using this feature.
  • Use admission control to prevent users with low trust levels from running the container with the root permission.

Fixed by official

  • v1.22.2
  • v1.21.5
  • v1.20.11
  • v1.19.15

Fixed by KLTS

2 - CVE-2021-3121

Vulnerability details

A program with this vulnerability may crash because of processing some messages that contain malicious Protobuf. If the version of Gogo Protobuf you are using is too low, this vulnerability may exist.

Scope

The Kubernetes system component has its own recovery mechanism to deal with crashes and will not interrupt service when encountering a maliciously submitted Protobuf message, so it is not within the scope affected by the vulnerability.

When the program receives and processes the Protobuf message in the application system, if the component does not have a recovery mechanism to deal with the crash, then such programs are within the scope of the vulnerability, and the service may be interrupted when such a malicious attack comes.

The Kubernetes community has tested and verified that API Server is not affected by this vulnerability, but in order to prevent you from being affected by the hidden risk of this security vulnerability, the community has upgraded the relevant Protobuf files.

Prevention

If you use the automatically generated Protobuf message in your application code and find that the relevant component exits due to the following exception, the vulnerability may exist.

panic: runtime error: index out of range [-9223372036854775804]

goroutine 1 [running]:

v1.(*MessageName).Unmarshal(0xc00006f1e8, 0xc0000281a8, 0xa, 0x10, 0xc00006f1b8, 0x1)

        .../protofile.pb.go:250 +0xb86

If you use a component related to the Protobuf message, it is recommended to upgrade the Gogo Protobuf compiler to the bug-fixed version (v1.3.2 or higher), and then regenerate the relevant Protobuf message based on the upgraded Protobuf compiler.

Fixed by official

  • v1.21.1
  • v1.20.7
  • v1.19.11
  • v1.18.19

Fixed by KLTS

3 - CVE-2020-8559

Vulnerability details

This is a security vulnerability of the kube-apiserver component. An attacker can intercept certain upgrade requests sent to the node kubelet, and forward the request to other target nodes through the original access credentials in the request that could allow an attacker to escalate privileges from a node compromise to a full cluster compromise.

Scope

Since kube-apiserver allows the request to be propagated back to the source client in the proxied upgrade request, the attacker can intercept certain upgrade requests sent to the node kubelet, and then use the original access credentials in the request to forward requests to other target nodes, resulting in a privilege escalation vulnerability on the attacked node.

CVSS scores

This vulnerability is rated as medium-risk with a CVSS score of 6.4. If multiple clusters share the same CA and authentication credentials, an attacker can use this vulnerability to attack other clusters. In this case, it is a high-risk vulnerability.

Prevention

For cross-node attacks in the cluster, it is recommended that you take the following preventative measures:

  • Timely revoke kubeconfig credentials that may cause leakage potentially, and follow the least principle of minimum permissions to converge unnecessary pods/exec, pods/attach, pods/portforward and proxy resource models with the RBAC permission.

Fixed by official

  • v1.18.6
  • v1.17.9
  • v1.16.13

Fixed by KLTS

4 - CVE-2020-8558

Vulnerability details

The kube-proxy component was found to set the kernel parameter net.ipv4.conf.all.route_localnet=1 in both iptables and ipvs modes to allow local loopback access. An attacker may use the container sharing the host network, or bind and listen to the TCP/UDP service of the local 127.0.0.1 on the cluster node to access the same LAN or adjacent node under the second layer network to obtain interface information. If your service does not set the necessary security certification, it may cause the risk of information leakage.

Scope

When an attacker has the capability of configuring host network or can access a container instance with the CAP_NET_RAW capability, he can get the socket service information by listening to 127.0.0.1 on the target node. If there is an exposed service that can be accessed by 127.0.0.1 and does not require any authentication on the target host, then the service information can be obtained by the attacker.

CVSS scores

  • If the cluster API Server opens the non-authenticated port (default 8080), then the attacker may obtain information about the API Server interface, the threat level is high-risk vulnerabilities, and the score is 8.8.
  • If the cluster API Server closes non-authenticated ports by default, the threat level is medium-risk vulnerability, and the score is 5.4.

Prevention

It is recommended that you take the following preventative measures:

If the business container needs to use the host network mode and listen on a non-secure port, you can mitigate this vulnerability by manually adding the iptables rule on the node.

Run the following command to configure the iptables rule in the cluster to deny non-local access traffic to 127.0.0.1:

iptables -I INPUT --dst 127.0.0.0/8 ! --src 127.0.0.0/8 -m conntrack ! --ctstate RELATED,ESTABLISHED,DNAT -j DROP

If the cluster does not need to open the API Server insecure port, you can add --insecure-port=0 to the kubernetes API server command line to disable the port.

If untrusted containers are running in the cluster, you can prohibit Container from enabling the CAP_NET_RAW capability, and disable the Container’s CAP_NET_RAW capability in pod spec.

securityContext:
  capabilities:
    drop: 
    - "NET_RAW"

Use PodSecurityPolicy to restrict deployment privileges or shared host network containers. In addition, you can configure requiredDropCapabilities in the policy to force container deployment to close the CAP_NET_RAW capability.

Fixed by official

  • v1.18.4
  • v1.17.7
  • v1.16.11

Fixed by KLTS

5 - CVE-2020-8552

Vulnerability details

This vulnerability may make the API Server vulnerable to a DoS (Denial of Service) attack caused by successful API requests.

Scope

API Server is vulnerable to a denial of service attack via successful API requests.

Fixed by Official

  • v1.17.3
  • v1.16.7
  • v1.15.10

Fixed by KLTS

6 - CVE-2019-1002101

Vulnerability details

This vulnerability may allow an attacker to modify or monitor any file in the directory with the same name in the symbolic link header during the unpacking process of the kubectl cp command, thereby causing damage.

Scope

The kubectl cp command allows copying files between containers and the user machine. An attacker may implant a malicious tar package with a symbolic link header into the image or running container, and modify or monitor any file in the directory that has the same name as the symbolic link header during the unpacking process of the cp command, thereby causing damage.

Fixed by Official

  • v1.14.1
  • v1.13.6
  • v1.12.8
  • v1.11.10

Fixed by KLTS

7 - CVE-2019-11251

Vulnerability details

This vulnerability may allow an attacker to use the kubectl cp command to write malicious files in the container tar package to any path on the host using Path Traversal. This process is limited only by the system permissions of the local user.

Scope

This vulnerability has a similar impact caused by CVE-2019-1002101, CVE-2019-11246, and CVE-2019-11249 that were found not long before.

The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine.

If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path (Path Traversal) on the user’s machine when kubectl cp is called.

Fixed by Official

  • v1.15.4
  • v1.14.7
  • v1.13.11

Fixed by KLTS

8 - CVE-2019-11248

Vulnerability details

The debugging endpoint /debug/pprof is exposed over the unauthenticated Kubelet healthz port.

Scope

The go pprof endpoint is exposed over the Kubelet’s healthz port. This debugging endpoint can potentially leak sensitive information such as internal Kubelet memory addresses and configuration, or for limited denial of service. The issue is of medium severity, but not exposed by the default configuration.

Fixed by Official

  • v1.14.4
  • v1.13.8
  • v1.12.10

Fixed by KLTS

9 - CVE-2019-11247

Vulnerability details

API Server mistakenly allows access to a cluster-scoped custom resource.

Scope

The Kubernetes kube-apiserver mistakenly allows access to a cluster-scoped custom resource if the request is made as if the resource were namespaced.

Authorizations for the resource accessed in this manner are enforced using roles and role bindings within the namespace, meaning that a user with access only to a resource in one namespace could create, view update or delete the cluster-scoped resource (according to their namespace role privileges).

Fixed by Official

  • v1.12.12

Fixed by KLTS

10 - CVE-2019-11246

Vulnerability details

This vulnerability may allow an attacker to use the kubectl cp command to write malicious files in the container tar package to any path on the host using Path Traversal. This process is limited only by the system permissions of the local user.

Scope

This vulnerability has a similar impact caused by CVE-2019-1002101 that was found not long before.

The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine.

If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path (Path Traversal) on the user’s machine when kubectl cp is called.

Fixed by Official

  • v1.14.3
  • v1.13.7
  • v1.12.10

Fixed by KLTS

11 - CVE-2019-11245

Vulnerability details

Containers for pods that do not specify an explicit runAsUser attempt to run as uid 0 (root) on container restart, or if the image was previously pulled to the node. If the pod specified mustRunAsNonRoot: true, the kubelet will refuse to start the container as root. If the pod did not specify mustRunAsNonRoot: true, the kubelet will run the container as uid 0.

Scope

If a pod specifies mustRunAsNonRoot: true, the pod will run as uid 0 when it restarts or the image is pulled on to a node.

Prevention

Specify mustRunAsNonRoot: true for pods.

Fixed by Official

  • v1.14.3
  • v1.13.7

Fixed by KLTS

12 - CVE-2019-11249

Vulnerability details

This vulnerability may allow an attacker to use the kubectl cp command to write malicious files in the container tar package to any path on the host using Path Traversal. This process is limited only by the system permissions of the local user.

Scope

This vulnerability has a similar impact caused by CVE-2019-1002101 and CVE-2019-11246 that were found not long before.

The kubectl cp command allows copying files between containers and the user machine. To copy files from a container, Kubernetes runs tar inside the container to create a tar archive, copies it over the network, and kubectl unpacks it on the user’s machine.

If the tar binary in the container is malicious, it could run any code and output unexpected, malicious results. An attacker could use this to write files to any path (Path Traversal) on the user’s machine when kubectl cp is called.

Fixed by Official

  • v1.15.2
  • v1.14.5
  • v1.13.9

Fixed by KLTS

13 - nokmem

Bug details

The node has sufficient disks, but it keeps reporting that the disk is insufficient to create a Pod.

Scope

When the node is used for a long time, it prompts an error that the remaining space is insufficient. The error message is as follows:

mkdir: cannot create directory '/sys/fs/cgroup/memory/8': No space left on device

The node disk is sufficient but reports this error, and the creation of Pod always fails. This is a potential “time bomb”.

All environments that use early-version kernels and Kubernetes versions before 1.21 will be affected. In runc 1.0.0-rc94 (opencontainers/runc#2840) it has been fixed (removed directly).

Prevention

  • Upgrade the system kernel
  • Kubernetes 1.14 to 1.20
    • Rebuild Kubelet with -tags=nokmem
  • Kubernetes 1.14 or earlier
  • Kubernetes 1.21 or higher
    • not affected

Fixed by KLTS