10

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

 3 years ago
source link: http://blog.daocloud.io/%e5%85%b3%e4%ba%8e-containerd-%e5%ae%89%e5%85%a8%e6%bc%8f%e6%b4%9e%e7%9a%84%e5%a3%b0%e6%98%8e%e5%85%ac%e5%91%8a/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

漏洞介绍与影响

当容器内的进程用 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 版本对该漏洞进行修复。

 漏洞原理

该漏洞原理详见后文。

DaoCloud Enterprise 平台的安全预案

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

640?wx_fmt=png

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

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

640?wx_fmt=png

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

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

重视安全是企业的生命线

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  标准实现的。

640?wx_fmt=png

 攻击原理

  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-c5r42. 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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK