CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L, 4.9 (medium)

In kubelet v1.13.6 and v1.14.2, 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.

CVE-2019-11245 will be fixed in the following Kubernetes releases:

• v1.13.7 in Revert "Use consistent imageRef during container startup" #78320
• v1.14.3 in Revert "Use consistent imageRef during container startup" #78316

Fixed by #78261 in master

Affected components:

• Kubelet

Affected versions:

• Kubelet v1.13.6
• Kubelet v1.14.2

Affected configurations:

Clusters with:

• Kubelet versions v1.13.6 or v1.14.2
• Pods that do not specify an explicit runAsUser: <uid> or mustRunAsNonRoot:true

Impact:

If a pod is run without any user controls specified in the pod spec (like runAsUser: <uid> or mustRunAsNonRoot:true), a container in that pod that would normally run as the USER specified in the container image manifest can sometimes be run as root instead (on container restart, or if the image was previously pulled to the node)

• pods that specify an explicit runAsUser are unaffected and continue to work properly
• podSecurityPolicies that force a runAsUser setting are unaffected and continue to work properly
• pods that specify mustRunAsNonRoot:true will refuse to start the container as uid 0, which can affect availability
• pods that do not specify runAsUser or mustRunAsNonRoot:true will run as uid 0 on restart or if the image was previously pulled to the node

Mitigations:

This section lists possible mitigations to use prior to upgrading.

• Specify runAsUser directives in pods to control the uid a container runs as
• Specify mustRunAsNonRoot:true directives in pods to prevent starting as root (note this means the attempt to start the container will fail on affected kubelet versions)
• Downgrade kubelets to v1.14.1 or v1.13.5 as instructed by your Kubernetes distribution.

original issue description follows

What happened:

When I launch a pod from a docker image that specifies a USER in the Dockerfile, the container only runs as that user on its first launch. After that the container runs as UID=0.

What you expected to happen:
I expect the container to act consistently every launch, and probably with the USER specified in the container.

How to reproduce it (as minimally and precisely as possible):
Testing with minikube (same test specifying v1.14.1, kubectl logs test always returns 11211):

$ minikube start --kubernetes-version v1.14.2
😄  minikube v1.1.0 on linux (amd64)
💿  Downloading Minikube ISO ...
 131.28 MB / 131.28 MB [============================================] 100.00% 0s
🔥  Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
🐳  Configuring environment for Kubernetes v1.14.2 on Docker 18.09.6
💾  Downloading kubeadm v1.14.2
💾  Downloading kubelet v1.14.2
🚜  Pulling images ...
🚀  Launching Kubernetes ... 
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"
$ cat test.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: memcached:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/bash"]
    args:
    - -c
    - 'id -u; sleep 30'
$ kubectl apply -f test.yaml 
pod/test created

# as soon as pod starts
$ kubectl logs test
11211
# Wait 30 seconds for container to restart
$ kubectl logs test
0
# Try deleting/recreating the pod
$ kubectl delete pod test
pod "test" deleted
$ kubectl apply -f test.yaml 
pod/test created
$ kubectl logs test
0

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version): I get the results I expect in v1.13.5 and v1.14.1. The problem exists in v1.13.6 and v1.14.2
• Cloud provider or hardware configuration: minikube v1.1.0 using VirtualBox
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others: