关于 containerd 安全漏洞的声明公告

​近日,社区发现了 containerd (一个 Docker 组件)的一个安全漏洞(编号 CVE-2020-15257,评分 5.2 分(CVSS v3 指标,总分 10 分),中等级别。该漏洞是由 Jeff Dileo 在 11 月 30 日最先披露出来(见底部参考链接 3 )。

01

漏洞介绍与影响

当容器内的进程用 root 用户 (UID 0) 启动并且能够访问到 containerd-shim 所在网络(通常情况下,containerd-shim 使用主机网络 hostnetwork)时, 该漏洞会导致恶意容器有机会通过调用 containerd-shim API 获取所在宿主机更多权限(例如:启动新的特权进程进行攻击)。

DaoCloud Enterprise 的「容器运行时」是以 docker 19.03 为基线的,该基线版本包含的 containerd 也会受到这个漏洞的影响。

  触发场景

该漏洞的触发场景需要有一个恶意的应用容器运行在容器平台中,并同时满足如下 3 个条件:

  • 该应用容器的来源是不被信任的
  • 该应用容器以 root 用户运行
  • 该应用容器运行在主机网络模式下(hostnetwork)

如果不受信任的用户在您的平台无法创建主机网络模式(hostnetwork)下的容器,或者容器内的进程是以非 root  用户(UID 0)运行,则不会触发该漏洞。

此外,如果您的 DCE 平台已经配置了「容器组安全策略」,亦无需过多担忧该漏洞。

  漏洞影响

该漏洞被社区评分为 5.2 分 / 10 分的安全隐患,有一定的触发条件、攻击路径较长,所以风险程度属于中等水平。DaoCloud Enterprise (以下简称 DCE)会在 4.0.4 版本对该漏洞进行修复。

  漏洞原理

该漏洞原理详见后文。

02

DaoCloud Enterprise 平台的安全预案

对于满足上述 3 条触发条件的 DCE (4.0.4 版本以下)的用户,我们推荐通过开启「容器组安全策略」来规避漏洞(如下图)。

当「容器组安全策略」启用后,平台会对容器组(Pod)中的某些特权(如容器共享 hostPID、hostIPC、hostnetwork、以及容器的 Linux capabilities 及 hostPath )进行限制,也因此可以避免本次漏洞触发攻击。

DCE 的管理员还可以通过 DCE 的「网络管理」页面(如下图)查看当前集群中使用「主机网络模式」的容器组列表,进行安全审计,检查当前集群是否运行着有潜在风险的容器组。

当「容器组安全策略」被启用,恶意的外部用户无法启动「主机网络模式」的容器组,也无法进行该漏洞相关的攻击。

当前, DCE 用户通过开启「容器组安全策略」可以有效防止通过该漏洞进行的攻击。但是建议后续根据情况,择机进行版本升级以确保漏洞修复(敬请联系 DaoCoud 安全与支持中心,为您提供详细的升级评估和参考)。我们预计在 12 月中下旬 DCE 发布 4.0.4 版本,届时将提供升级 docker 和 containerd 组件的补丁,以避免该漏洞影响。

03

重视安全是企业的生命线

DaoCloud 始终重视企业系统平台安全,我们衷心感谢每一位客户对 DaoCloud 产品的信赖和支持,我们也将一如既往地提供最优质,最周到的服务支持。

目前,我们也收到许多用户关于此次 containerd 安全漏洞及相关安全问题的咨询,他们或在使用开源产品,或在使用其他的商业平台产品;如果您也有任何容器相关的问题,欢迎随时通过服务热线、邮件、DaoVoice  等方式联系我们,我们期待与您的沟通。

END.

 漏洞原理解析

首先介绍一下这里涉及到的几个组件:docker、containerd、 containerd-shim、runC。

  • docker 是基于 containerd 提供容器运行时的,提供了更好的 API  和 CLI  体验;
  • containerd 是容器运行时。作为守护进程,containerd 通过 containerd-shim 调用 runC 管理容器,并对外提供 gRPC 接口;
  • containerd-shim 调用 runC 管理容器,runC 是基于 OCI  标准实现的。

   攻击原理

  1. containerd-shim 所使用的 Unix 虚拟域套接字,是绑定在了主机的网络命名空间上的。此时,当一个恶意容器同样处于主机的网络命名空间中,恶意容器内的 root 用户,可以通过譬如 netstat -xl  或者 /proc/net/unix 来扫描,找到 containerd-shim 的套接字,然后就可以链接 containerd-shim 的 API 执行命令。
  2. 当 containerd 调用 containerd-shim 的 API 时,该调用过程使用了标准的 Unix 域套接字来验证连接的有效性。该验证检查两部分:一是网络命名空间是否一致,二是 UID/EUID 是否为 0(通常等价于是否为 root 用户) 。也就是说,当攻击者的容器处于主机网络命名空间,并且是 root 用户,这时攻击者可以欺骗 containerd-shim,“假装” 成 containerd,调用 containerd-shim 的 API,然后进行包括创建、删除容器等各类越权操作。

   漏洞攻击条件(同时满足以下几点):

  • 容器使用主机网络 hostnetwork 部署,此时容器和主机共享同样的网络命名空间;
  • 容器使用 root 用户 (UID 0);
  • 平台的 containerd 版本在 <=1.3.7 或者 1.4.0、 1.4.1 。

   应对方法(任选其一即可):

  • 通过 PSP (PodSecurityPolicy) 或者平台安全控制组件逻辑,禁止创建 hostnetwork 的容器组;
  • 启用了 AppArmor,并在 AppArmor  配置 deny unix addr=@**  也可以避免受到本漏洞的影响;
  • 应用容器以非 root 用户运行;
  • 升级 containerd 和 docker 到指定版本。
    • containerd 在版本 1.3.9 和 1.4.3 中修复了此问题
    • docker 在今天发布的 v19.03.14 版本,升级了 containerd 到 1.3.9 来解决该问题

修复代码:Merge pull request from GHSA-36xw-fx78-c5r4 (见底部参考链接 4 )

Reference:
1. 编号 CVE-2020-15257安全漏洞:
https://github.com/containerd/containerd/security/advisories/GHSA-36xw-fx78-c5r4
2. CVSS v3 指标:
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2020-15257&vector=AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N&version=3.1&source=GitHub,%20Inc.
3. https://research.nccgroup.com/2020/11/30/technical-advisory-containerd-containerd-shim-api-exposed-to-host-network-containers-cve-2020-15257/
4. https://github.com/containerd/containerd/commit/ea765aba0d05254012b0b9e595e995c09186427f