Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 7 Jun 2019 23:31:51 +0000
From: Tim Pepper <>
To: Brandon Philips <>, Kubernetes developer/contributor
 discussion <>,
	<>, kubernetes-security-discuss
	"" <>,
Subject: Re: [ANNOUNCE] Security regression in Kubernetes kubelet v1.13.6 and
 v1.14.2 only - CVE-2019-11245

Just in case anybody missed it explicitly…v1.13.7 and v1.14.3 were released yesterday, including the change for this CVE.

Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center

From: <> on behalf of Brandon Philips <>
Date: Thursday, May 30, 2019 at 2:57 PM
To: Kubernetes developer/contributor discussion <>, "" <>, kubernetes-security-discuss <>, "" <>, "" <>
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<> 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

**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
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to<>.
To post to this group, send email to<>.
Visit this group at<>.
To view this discussion on the web visit<>.
For more options, visit<>.

Powered by blists - more mailing lists

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.