oss-security - [ANNOUNCE] Security regression in Kubernetes kubelet v1.13.6 and v1.14.2 only

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHHNuYcXG6rqgA+y3efW8yb5Kbd9CgJq_MfgKz8cUgp4AqbXRg@mail.gmail.com>
Date: Thu, 30 May 2019 14:57:25 -0700
From: Brandon Philips <bphilips@...hat.com>
To: "Kubernetes developer/contributor discussion" <kubernetes-dev@...glegroups.com>, 
	kubernetes-security-announce@...glegroups.com, 
	kubernetes-security-discuss <kubernetes-security-discuss@...glegroups.com>, 
	oss-security@...ts.openwall.com, 
	kubernetes-distributors-announce@...glegroups.com
Subject: [ANNOUNCE] Security regression in Kubernetes kubelet v1.13.6 and
 v1.14.2 only - CVE-2019-11245

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:

   -

   Downgrade to kubelet v1.13.5 or v1.14.1 as instructed by your Kubernetes
   distribution.
   -

   Set RunAsUser on all pods in the cluster that should not run as root.
   This is a Security Context feature; the docs are at
   https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod

***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 <https://github.com/kubernetes/kubernetes/pull/78178> many
<https://github.com/kubernetes/kubernetes/issues/78308> reporters
<https://github.com/rancher/k3s/issues/511>, and Tim Pepper as release
manager for the coordination in making this announcement.

Thank You,

Brandon on behalf of the Kubernetes Product Security Committee

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.