kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update CVE-2019-5736 article 

- Add authors
- Tidy formatting

NOT marking this article as evergreen because it mentions
PodSecurityPolicy.
pull/32146/head
Tim Bannister 2022-03-09 12:11:56 +00:00
parent c3607e80b9
commit 5fe8d4f2a1
No known key found for this signature in database
GPG Key ID: 1E76582C4F66FA48
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
content/en/blog/_posts/2019-02-11-runc-CVE-2019-5736.md
View File

@ -1,17 +1,20 @@
---
title: Runc and CVE-2019-5736
date: 2019-02-11
evergreen: false # mentions PodSecurityPolicy
---
Authors: Kubernetes Product Security Committee
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?
## 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.
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?
### 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.
@ -19,13 +22,14 @@ If the process inside the container is either trusted (something you know is not
The most common source of risk is attacker-controller container images, such as unvetted images from public repositories.
### What Should I Do?
### 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:
@ -39,6 +43,7 @@ spec:
This can also be enforced globally using a PodSecurityPolicy:
```yaml
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
@ -89,7 +94,7 @@ We don't have specific confirmation that Docker for Mac and Docker for Windows a
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
## 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/).