This issue was reported in the Kubernetes Security Audit Report

Description
Kubelet fetches a process’s PID by checking the process name when the pidfile file doesn’t exist. This fallback mechanism doesn’t validate the target process allowing an attacker to spoof it.

Kubelet’s container manager first tries to use a hardcoded pidfile path to retrieve the PIDs of important processes, like dockerd and docker-containerd (Figure 1).

const (
	// (...)
	dockerProcessName     = "docker"
	dockerPidFile         = "/var/run/docker.pid"
	containerdProcessName = "docker-containerd"
	containerdPidFile     = "/run/docker/libcontainerd/docker-containerd.pid"
)

Figure 16.1: Hardcoded pidfiles paths.

If these hard-coded files do not exist, then the container manager will fall back to scanning /proc/<pid>/cmdline. If the pidfile is not there, and this happens to be the case on our setup, an attacker may move an unprivileged, cgroups-limited process on the host to manager’s cgroup and set its OOM-killer badness heuristic to -999, making the process less likely to be killed in out-of-memory scenarios.

Exploit Scenario
Alice has kubelet running on a machine where the docker-containerd pidfile is located in a different path than the hardcoded one. Eve gains access to Alice’s machine and notices kubelet is running. Eve’s current cgroup limits her too much for what she is attempting to perform on the machine, so she uses kubelet’s cgroup monitoring to migrate her process into an elevated cgroup.

Eve can execute the attack by simply renaming her malicious process to docker-containerd, launching it and waiting five minutes (so kubelet moves it to the cgroup and sets the OOM-killer badness heuristic).

Recommendation
Use only pidfiles and let users configure paths to them. This relates to issue #34066. If enforcing the use of pidfiles only is not an option, consider adding checks to identify whether given PID is really the targeted process and warn users that the pidfile hasn’t been found.

Anything else we need to know?:

See #81146 for current status of all issues created from these findings.

The vendor gave this issue an ID of TOB-K8S-021 and it was finding 16 of the report.

The vendor considers this issue Medium Severity.

To view the original finding, begin on page 50 of the Kubernetes Security Review Report

Environment:

• Kubernetes version: 1.13.4