From f48d7268e89623d65ecc6fe8426c4a4646bfc7fc Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 18:01:38 -0800 Subject: [PATCH 1/7] First pass on a blog post about CVE-2019-5736. --- .../_posts/2019-02-11-runc-CVE-2019-5736.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md new file mode 100644 index 0000000000000..9e4237ca94f72 --- /dev/null +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -0,0 +1,79 @@ +--- +title: Runc and CVE-2019-5736 +date: 2019-02-11 +--- + +This morning [a container escape vulnerability in runc was announced](https://www.openwall.com/lists/oss-security/2019/02/11/2). We wanted to provide some guidance to Kubernetes users to ensure everyone is safe and secure. + +## What Is Runc? + +Very briefly, runc is the low-level tool which does the heavy lifting of spawning a Linux container. Other tools like Docker, Containerd, and CRI-O sit on top of runc to deal with things like data formatting and serialization, but runc is at the heart of all of these systems. + +### What Is The Vulnerability? + +While full details are still embargoed to give people time to patch, the rough version is that when running a process as root (UID 0) inside a container, that process can exploit a bug in runc to gain root privileges on the host running the container. This then allows them unlimited access to the server as well as any other containers on that server. + +If the process inside the container is either trusted (something you know is not hostile) or is not running as UID 0, then the vulnerability does not apply. It can also be prevented by SELinux, if an appropriate policy has been applied. RedHat Enterprise Linux, CentOS, and Fedora all include appropriate SELinux permissions with their packages and so are believed to be unaffected. + +The most common source of risk is attacker-controller container images, such as unvetted images from public repositories. + +### What Should I Do? + +As with all security issues, the two main options are to mitigate the vulnerability or upgrade your version of runc to one that includes the fix. + +As the exploit requires UID 0 within the container, a direct mitigation is to ensure all your containers are running as a non-0 user. This can be set within the container image, or via your pod specification: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: run-as-uid-1000 +spec: + securityContext: + runAsUser: 1000 + # ... +``` + +This can also be enforced globally using a PodSecurityPolicy: + +```yaml +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: non-root +spec: + privileged: false + allowPrivilegeEscalation: false + runAsUser: + # Require the container to run without root privileges. + rule: 'MustRunAsNonRoot' +``` + +Setting a policy like this is highly encouraged given the overall risks of running as UID 0 inside a container. + +Another potential mitigation is to ensure all your container images are vetted and trusted. This can be accomplished by building all your images yourself, or by vetting the contents of an image and then pinning to the image version hash (`image: external/someimage:1985144b2f29`). + +Upgrading runc can generally be accomplished by upgrading the package `runc` for your distribution or by upgrading your OS image if using immutable images. This is a list of known safe versions for various distributions and platforms: + +* Ubuntu - `runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1` +* Debian - `runc 0.1.1+dfsg1-2` +* Amazon Linux - `docker 18.06.1ce-7.25.amzn1.x86_64` +* CoreOS - `2051.0.0` +* Kops Debian - [in progress](https://github.com/kubernetes/kops/pull/6460) +* Docker - [`18.09.2`](https://github.com/docker/docker-ce/releases/tag/v18.09.2) + +Some platforms have also posted more specific instructions: + +#### Google Container Engine (GKE) + +Google has issued a [security bulletin](https://cloud.google.com/kubernetes-engine/docs/security-bulletins#february-11-2019-runc) with more detailed information but in short, if you are using the default GKE node image then you are safe. If you are using an Ubuntu or CoreOS node image then you will need to mitigate or upgrade to an image with a fixed version of runc. + +#### Amazon Elastic Container Service for Kubernetes (EKS) + +Amazon has also issued a [security bulletin](https://aws.amazon.com/security/security-bulletins/AWS-2019-002/) with more detailed information. All EKS users should mitigate the issue or upgrade to a new node image. + +### Docker + +We don't have specific confirmation that Docker for Mac and Docker for Windows are vulnerable, however it seems likely. Docker has released a fix in [version 18.09.2](https://github.com/docker/docker-ce/releases/tag/v18.09.2) and it is recommended you upgrade to it. This also applies to other deploy systems using Docker under the hood. + + From 3858bc26030a11e77e20042026953ee96ce6d4ee Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 18:04:22 -0800 Subject: [PATCH 2/7] Clarify that k8s is not the problem. --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index 9e4237ca94f72..b133075874098 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -9,6 +9,8 @@ This morning [a container escape vulnerability in runc was announced](https://ww Very briefly, runc is the low-level tool which does the heavy lifting of spawning a Linux container. Other tools like Docker, Containerd, and CRI-O sit on top of runc to deal with things like data formatting and serialization, but runc is at the heart of all of these systems. +Kubernetes in turn sits on top of those tools, and so while no part of Kubernetes itself is vulnerable, most Kubernetes installations are using runc under the hood. + ### What Is The Vulnerability? While full details are still embargoed to give people time to patch, the rough version is that when running a process as root (UID 0) inside a container, that process can exploit a bug in runc to gain root privileges on the host running the container. This then allows them unlimited access to the server as well as any other containers on that server. From 51a511d2a182a8634b2133bdea1ce80572604c88 Mon Sep 17 00:00:00 2001 From: Zach Arnold Date: Mon, 11 Feb 2019 21:18:20 -0800 Subject: [PATCH 3/7] Fix example of pinning to an image hash. My mistake deftly caught by @zparnold. Co-Authored-By: coderanger --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index b133075874098..c42e59a05afcc 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -53,7 +53,7 @@ spec: Setting a policy like this is highly encouraged given the overall risks of running as UID 0 inside a container. -Another potential mitigation is to ensure all your container images are vetted and trusted. This can be accomplished by building all your images yourself, or by vetting the contents of an image and then pinning to the image version hash (`image: external/someimage:1985144b2f29`). +Another potential mitigation is to ensure all your container images are vetted and trusted. This can be accomplished by building all your images yourself, or by vetting the contents of an image and then pinning to the image version hash (`image: external/someimage@sha256:7832659873hacdef`). Upgrading runc can generally be accomplished by upgrading the package `runc` for your distribution or by upgrading your OS image if using immutable images. This is a list of known safe versions for various distributions and platforms: From 7a98ebf08676d0c8aa00254687ece7303262adef Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 21:18:48 -0800 Subject: [PATCH 4/7] Add links to the rest of the notices or releases. --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index c42e59a05afcc..f11db61c0195c 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -57,10 +57,10 @@ Another potential mitigation is to ensure all your container images are vetted a Upgrading runc can generally be accomplished by upgrading the package `runc` for your distribution or by upgrading your OS image if using immutable images. This is a list of known safe versions for various distributions and platforms: -* Ubuntu - `runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1` -* Debian - `runc 0.1.1+dfsg1-2` -* Amazon Linux - `docker 18.06.1ce-7.25.amzn1.x86_64` -* CoreOS - `2051.0.0` +* Ubuntu - [`runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1`](https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-5736.html) +* Debian - [`runc 0.1.1+dfsg1-2`](https://security-tracker.debian.org/tracker/CVE-2019-5736) +* Amazon Linux - [`docker 18.06.1ce-7.25.amzn1.x86_64`](https://alas.aws.amazon.com/ALAS-2019-1156.html) +* CoreOS - [`2051.0.0`](https://coreos.com/releases/#2051.0.0) * Kops Debian - [in progress](https://github.com/kubernetes/kops/pull/6460) * Docker - [`18.09.2`](https://github.com/docker/docker-ce/releases/tag/v18.09.2) From b9e0091d3132565a2b354ea1bc9b1eafc7b84674 Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 21:19:19 -0800 Subject: [PATCH 5/7] Add ways to get more info. --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index f11db61c0195c..f024b48ab80c9 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -79,3 +79,8 @@ Amazon has also issued a [security bulletin](https://aws.amazon.com/security/sec We don't have specific confirmation that Docker for Mac and Docker for Windows are vulnerable, however it seems likely. Docker has released a fix in [version 18.09.2](https://github.com/docker/docker-ce/releases/tag/v18.09.2) and it is recommended you upgrade to it. This also applies to other deploy systems using Docker under the hood. +## Getting More Information + +If you have any further questions about how this vulnerability impacts Kubernetes, please join us at [discuss.kubernetes.io](https://discuss.kubernetes.io/). + +If you would like to get in contact with the [runc team](https://github.com/opencontainers/org/blob/master/README.md#communications), you can reach them on [Google Groups](https://groups.google.com/a/opencontainers.org/forum/#!forum/dev) or `#opencontainers` on Freenode IRC. From 569cfc3d996f065546d8d121c069656c8c3e3848 Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 21:25:22 -0800 Subject: [PATCH 6/7] RHEL link for those that don't selinux. --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index f024b48ab80c9..1aa08855e6a09 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -59,6 +59,7 @@ Upgrading runc can generally be accomplished by upgrading the package `runc` for * Ubuntu - [`runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1`](https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-5736.html) * Debian - [`runc 0.1.1+dfsg1-2`](https://security-tracker.debian.org/tracker/CVE-2019-5736) +* RedHat Enterprise Linux - [`docker 1.13.1-91.git07f3374.el7`](https://access.redhat.com/security/vulnerabilities/runcescape) (if SELinux is disabled) * Amazon Linux - [`docker 18.06.1ce-7.25.amzn1.x86_64`](https://alas.aws.amazon.com/ALAS-2019-1156.html) * CoreOS - [`2051.0.0`](https://coreos.com/releases/#2051.0.0) * Kops Debian - [in progress](https://github.com/kubernetes/kops/pull/6460) From cbb745cb5d92af87dfcee117abcc3a1695a3aad5 Mon Sep 17 00:00:00 2001 From: Noah Kantrowitz Date: Mon, 11 Feb 2019 21:25:33 -0800 Subject: [PATCH 7/7] Link to Rancher's back ports. --- content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md index 1aa08855e6a09..331bb3de92f34 100644 --- a/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md +++ b/content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md @@ -79,6 +79,7 @@ Amazon has also issued a [security bulletin](https://aws.amazon.com/security/sec We don't have specific confirmation that Docker for Mac and Docker for Windows are vulnerable, however it seems likely. Docker has released a fix in [version 18.09.2](https://github.com/docker/docker-ce/releases/tag/v18.09.2) and it is recommended you upgrade to it. This also applies to other deploy systems using Docker under the hood. +If you are unable to upgrade Docker, the Rancher team has provided backports of the fix for many older versions at [github.com/rancher/runc-cve](https://github.com/rancher/runc-cve). ## Getting More Information