DaoCloud道客博客近日，社区发现了 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 标准实现的。
攻击原理
- containerd-shim 所使用的 Unix 虚拟域套接字，是绑定在了主机的网络命名空间上的。此时，当一个恶意容器同样处于主机的网络命名空间中，恶意容器内的 root 用户，可以通过譬如 netstat -xl 或者 /proc/net/unix 来扫描，找到 containerd-shim 的套接字，然后就可以链接 containerd-shim 的 API 执行命令。
- 当 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 )
未经允许不得转载：DaoCloud道客博客 » 关于 containerd 安全漏洞的声明公告
