[ANNOUNCE] Security regression in Kubernetes kubelet v1.13.6 and v1.14.2 only - CVE-2019-11245

388 views
Skip to first unread message

Brandon Philips

unread,
May 30, 2019, 5:57:39 PM5/30/19
to Kubernetes developer/contributor discussion, kubernetes-sec...@googlegroups.com, kubernetes-security-discuss, oss-se...@lists.openwall.com, kubernetes-distr...@googlegroups.com

Hello Kubernetes Community-


A security-related issue was discovered in kubelet versions v1.13.6 and v1.14.2. The issue is medium severity and can be mitigated with a pod spec configuration change OR by **downgrading** kubelets to v1.13.5 or v1.14.1.


**Vulnerability Details**


When a container runs for the first time on a node, it correctly respects the UID set by the container image (e.g. USER in a Dockerfile). However, on the second run, the container will run as UID 0 (aka root) which can be an undesired escalated privilege.


Pods that specify an explicit runAsUser are unaffected and continue to work properly.

PodSecurityPolicies that force a runAsUser setting are also unaffected and continue to work properly.

Pods that specify mustRunAsNonRoot:true will refuse to start the container as uid 0, which can affect availability.

This issue is filed as CVE-2019-11245. See https://github.com/kubernetes/kubernetes/issues/78308 for more details.


**Am I vulnerable?**


Run this to print out all nodes and their kubelet version:


kubectl get nodes -o=jsonpath='{range .items[*]}{.status.nodeInfo.machineID}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'


If the output lists Kubelet versions listed below you are running a vulnerable version:

  • v1.13.6

  • v1.14.2


**How do I mitigate the vulnerability?**


There are two potential mitigations to this issue:



**How do I upgrade?**


An upgrade addressing this issue is not yet available. But, will appear in v1.13.7 and v1.14.3 ASAP and will be announced here.


**Thank you**


Thank you to the many reporters, and Tim Pepper as release manager for the coordination in making this announcement.


Thank You,


Brandon on behalf of the Kubernetes Product Security Committee

Reply all
Reply to author
Forward
0 new messages