Powered by GitBook

FROM https://help.aliyun.com/document_detail/107320.html

修复runc漏洞CVE-2019-5736的公告

更新时间：2019-02-12 23:16:24

阿里云容器服务已修复runc漏洞CVE-2019-5736。本文介绍该漏洞的影响范围及解决方法。

阿里云容器服务已修复runc漏洞CVE-2019-5736。本文介绍该漏洞的影响范围及解决方法。

背景信息

Docker、containerd或者其他基于runc的容器在运行时存在安全漏洞，攻击者可以通过特定的容器镜像或者exec操作获取到宿主机runc执行时的文件句柄并修改掉runc的二进制文件，从而获取到宿主机的root执行权限。

漏洞CVE-2019-5736的详细信息，请参见https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736。

影响范围

对于阿里云容器服务而言，影响范围如下：

Docker版本 < 18.09.2 的所有Docker Swarm集群和Kubernetes集群（不包含Serverless Kubernetes集群）
对于用户自建的Docker/Kubernetes环境而言，影响范围如下：

Docker版本 < 18.09.2 或者使用 runc版本 <= 1.0-rc6的环境。请自行根据厂商建议进行修复。

解决方法

新建Kubernetes1.11或1.12集群。容器服务新创建的1.11或1.12版本的Kubernetes集群已经包含修复该漏洞的Docker版本。
升级Docker。升级已有集群的Docker到18.09.2或以上版本。该方案会导致容器和业务中断。
仅升级runc（针对Docker版本17.06）。为避免升级Docker引擎造成的业务中断，可以按照以下步骤，逐一升级集群节点上的runc二进制。
1. 执行以下命令定位docker-runc。docker-runc通常位于
  
  /usr/bin/docker-runc
  
  路径下。
  
  试用

 ```
 which docker-runc
 ```

执行以下命令备份原有的runc：

试用

 ```
 mv /usr/bin/docker-runc /usr/bin/docker-runc.orig.$(date -Iseconds)
 ```

执行以下命令下载修复的runc：

试用

 ```
 curl -o /usr/bin/docker-runc -sSL https://acs-public-mirror.oss-cn-hangzhou.aliyuncs.com/runc/docker-runc-17.06-amd64
 ```

执行以下命令设置docker-runc的可执行权限：

试用

 ```
 chmod +x /usr/bin/docker-runc
 ```

执行以下命令测试runc是否可以正常工作：

试用

 ```
 docker-runc -v
 # runc version 1.0.0-rc3
 # commit: fc48a25bde6fb041aae0977111ad8141ff396438
 # spec: 1.0.0-rc5
 docker run -it --rm ubuntu echo OK
 ```

如果是GPU的节点，还需要完成以下步骤额外安装下nvidia-runtime。
1. 执行以下命令定位nvidia-container-runtime。nvidia-container-runtime通常位于
  
  /usr/bin/nvidia-container-runtime
  
  路径下。
  
  试用

    ```
    which nvidia-container-runtime
    ```

 2. 执行以下命令备份原有的nvidia-container-runtime：

    [试用](https://api.aliyun.com/new#/tutorial?id=107320)



    ```
    mv /usr/bin/nvidia-container-runtime /usr/bin/nvidia-container-runtime.orig.$(date -Iseconds)
    ```

 3. 执行以下命令下载修复的nvidia-container-runtime：

    [试用](https://api.aliyun.com/new#/tutorial?id=107320)



    ```
    curl -o /usr/bin/nvidia-container-runtime -sSL https://acs-public-mirror.oss-cn-hangzhou.aliyuncs.com/runc/nvidia-container-runtime-17.06-amd64
    ```

 4. 执行以下命令设置nvidia-container-runtime的可执行权限：

    [试用](https://api.aliyun.com/new#/tutorial?id=107320)



    ```
    chmod +x /usr/bin/nvidia-container-runtime
    ```

 5. 执行以下命令测试nvidia-container-runtime是否可以正常工作：

    [试用](https://api.aliyun.com/new#/tutorial?id=107320)



    ```
    nvidia-container-runtime -v
    #  runc version 1.0.0-rc3
    #  commit: fc48a25bde6fb041aae0977111ad8141ff396438-dirty
    #  spec: 1.0.0-rc5

    docker run -it --rm -e NVIDIA_VISIBLE_DEVICES=all ubuntu nvidia-smi -L
    #  GPU 0: Tesla P100-PCIE-16GB (UUID: GPU-122e199c-9aa6-5063-0fd2-da009017e6dc)
    ```

FROM https://kubernetes.io/blog/2019/02/11/runc-and-cve-2019-5736/

Runc and CVE-2019-5736

Monday, February 11, 2019

Runc and CVE-2019-5736

This morning a container escape vulnerability in runc was announced. 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.

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.

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 and CentOS both include appropriate SELinux permissions with their packages and so are believed to be unaffected if SELinux is enabled.

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:

apiVersion: v1
kind: Pod
metadata:
  name: run-as-uid-1000
spec:
  securityContext:
    runAsUser: 1000
  # ...

This can also be enforced globally using a PodSecurityPolicy:

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@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:

Ubuntu - runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1
Debian - runc 0.1.1+dfsg1-2
RedHat Enterprise Linux - docker 1.13.1-91.git07f3374.el7 (if SELinux is disabled)
Amazon Linux - docker 18.06.1ce-7.25.amzn1.x86_64
CoreOS - 2051.0.0
Kops Debian - in progress
Docker - 18.09.2

Some platforms have also posted more specific instructions:

Google Container Engine (GKE)

Google has issued a security bulletin 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 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 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 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.

Getting More Information

If you have any further questions about how this vulnerability impacts Kubernetes, please join us at discuss.kubernetes.io.

If you would like to get in contact with the runc team, you can reach them on Google Groups or #opencontainers on Freenode IRC.

results matching ""

No results matching ""