Symlink-Exchange 攻击 - runc-（CVE-2021-30465）

摘要

红帽已了解到在 runc 中存在一个漏洞，当一个攻击者在可以部署容器的情况下，可能会利用这个漏洞从容器逃逸到主机系统。这个安全问题已被记录为 CVE-2021-30465，它的安全影响级别被定为 Important（重要）。当 SELinux 在强制（enforcing）模式下运行时，这个漏洞的影响会降低。

以下红帽产品版本会受到这个漏洞的直接影响：

• Red Hat Enterprise Linux 8

• Red Hat OpenShift Container Platform 4.x

• Red Hat Enterprise Linux 7

• Red Hat OpenShift Container Platform 3.x

此外，在 Red Hat Enterprise Linux 平台上支持的任何红帽产品都有可能会受到影响。这包括从 RHEL 频道获取软件包的产品。  在相关的生产环境中，请确保底层的 Red Hat Enterprise Linux runc 或 docker 软件包是最新的。

请参照下面的诊断部分的内容，检查您的系统当前是否存在这些安全漏洞。

技术概述

在 runc 中发现了一个安全漏洞，利用这个漏洞，可以突破容器的限制以获得所在主机文件系统的访问权限。

此漏洞会影响 Red Hat Enterprise Linux（RHEL）8 中的 runc 及其所有依赖它的容器工具程序。OpenShift Container Platform（OCP）4.x 也会受到这个漏洞的影响，因为它会通过 cri-o 使用 runc。

此漏洞也会影响通过 Extras 频道提供的 Red Hat Enterprise Linux 7 中可用的 docker 和 runc 软件包。OpenShift Container Platform（OCP）3.x 依赖于这些来自 Red Hat Enterprise Linux 7 Extras 的软件包，它也会受到这个安全漏洞的影响。

缓解方案

如果 SELinux 处于使用 container-selinux 策略的强制模式，则可以降低该漏洞的安全影响。默认情况下，container-selinux 策略会在 RHEL 7 和 8，以及 OpenShift Container Platform 3.x 和 4.x 上安装并启用。

强烈建议运行受影响版本的 RHEL 的客户，在相关的勘误可用后立即从 RHEL 8 频道和 RHEL 7 Extras 频道应用 RPM 更新。  

强烈建议运行受影响版本的 OpenShift Container Platform 的客户，在勘误可用后立即进行升级。

对于使用 OpenShift Online 或 OpenShift Dedicated 的客户，所有集群中的每个主机都已启用了 SELinux 强制模式。因此，我们预期 OSO/OSD 受到此问题的影响会较小，并会在即将到来的维护时段内提供安全补丁。

技术细节

runc 软件包容易受到一个被称为 symlink exchange 的安全攻击，攻击者可以通过请求一个看似无害的容器配置，将主机文件系统绑定到容器中。

runc 软件包可以被单独使用来运行容器，但它通常也会被其他软件包使用来运行容器。在 RHEL 8 中，container-tools 模块软件包（podman）需要使用 runc，因此会因为对 runc 的依赖而容易受到攻击。  OCP 4 通过 cri-o 软件包使用了 runc，因此也容易受到攻击。在 RHEL-7 中，docker 软件包嵌入了 runc，因此会受到此问题的影响。OCP 3 在其默认配置中使用 docker 软件包，因此也会受到此问题的影响。OCP 3 也可以被配置为使用 cri-o 而不是 docker，这种情况也会受此问题的影响。

在一个容器启动，且 runc 在内部挂载一个与另外一个容器（在这个容器中执行 symlink-exchange 攻击）共享的卷时，通过利用一个 TOCTTOU（time-of-check-to-time-of-use）漏洞使用一个符合链接（symlink）替换挂载目标，从而诱骗 runc 在容器中挂载容器根文件系统之外的系统。

但是，仅此一点还无法对安全造成影响，因为这发生在一个挂载命名空间内部，这个挂载命名空间会将 “MS_SLAVE” 用于 “/”（这意味着该挂载不会出现在主机上，它只是容器命名空间内部的一个“主机端挂载”）。要利用此漏洞，需要在配置中有其他的挂载条目，这些条目使用已挂载的主机路径作为后续挂载的源。

产品影响

OpenShift Container Platform

在 OpenShift Container Platform 中，要成功利用这个安全漏洞，可以在卷中创建一个符号链接，这个符号链接指向顶级目录（常用的目录），该目录作为卷的源（例如，"/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir"），然后使用该符号链接作为一个挂载目标。 

挂载的源是攻击者控制的目录，因此从其进行后续挂载的源目录就成为攻击者控制的目录。攻击者可以首先在其控制的恶意源目录中放置一个到 “/” 的符号链接，其中包括一个卷的名称，然后容器中的后续挂载会将 “/” 绑定挂载到容器中。

如果 SELinux 处于使用 container-selinux 策略的强制模式，则可以降低该漏洞的安全影响。默认情况下，container-selinux 策略会在 OpenShift Container Platform 3.x 和 4.x 上安装并启用。

服务影响

OpenShift Online/Dedicated

在 OpenShift Dedicated（OSD）中，每个客户都有一个或多个专用集群，并且不共享这些集群。 因此，这个安全漏洞只会暴露在一个客户的内部。

OpenShift Online 和 OpenShift Dedicated 用户在所有群集的每个主机上都以强制模式启用了SELinux，从而减少了此安全漏洞的影响（详情请参阅以下 FAQ 部分）。

只有在攻击者可以部署容器时，才能利用此漏洞。在 OSD 中，只有经过身份验证和授权的用户才能在 OSD 中部署容器。  红帽建议仅部署受信任的容器（例如，验证它们来自受信任的来源，Health Index 的状态为良好[6]）

Red Hat Developer Sandbox

存在这个安全漏洞的软件包作为一个其他软件包的依赖软件包存在于 Red Hat Developer Sandbox 中。但实际上它并不需要并且没有被使用，因此服务不会受到这个安全漏洞的影响。在即将到来的维护窗口期间，不需要的软件包会被删除。

Red Hat OpenShift API Management

存在这个安全漏洞的软件包存在于 Red Hat OpenShift API Management 中。只有受管服务的管理员才能部署容器，这些容器会在部署之前经过验证和且被信任。因此该服务不会受到影响，风险很低。在即将到来的维护窗口期间，存在这个安全漏洞的软件包会被升级。 

受影响产品的更新

我们强烈建议，所有运行受影响版本的红帽产品的用户，在相关勘误可用后尽快进行更新。用户应立即应用可用的更新或根据需要启用缓解措施。  

[1] 公告/更新链接将在更新发布后添加。

[2] 什么是 Red Hat Enterprise Linux Extended Update Support (EUS) 订阅?

[3] 什么是 Advanced mission critical Update Support (AUS)?

[4] 什么是 Red Hat Enterprise Linux SAP Solutions 订阅?

[5] 访问此修补程序需要一个有效的延长生命周期支持（ELS）订阅。  如果您的帐户并没有包括有效的 ELS 订阅，请联系红帽销售部门或您的销售代表以获取更多信息。

[6] 使用 Red Hat Enterprise Linux 基本镜像的产品容器。基本镜像将被更新以包含针对此漏洞的修复程序，请确保容器是最新的。Container Health Index（Red Hat Container Catalog 的一部分）可以用来检查红帽容器的安全状态。

[7] 从 RHEL 频道获取软件包的产品。  在相关的生产环境中，请确保底层的 Red Hat Enterprise Linux runc 或 docker 软件包是最新的

诊断

一个安全漏洞检测脚本已被开发，用来检查您的系统当前是否存在相关的安全漏洞。您可以下载 GPG 签名来验证脚本的真实性。红帽客户门户网站上提供了有关如何使用GPG签名进行验证的说明。

常问问题解答

问：使用 SELinux 是否可以缓解此漏洞的影响？

答：虽然在 SELinux 处于强制模式下时仍可以利用此漏洞，但其影响会大大降低。攻击者可以将主机文件系统挂载到容器进程中，但容器进程会带有一个 SELinux 标签。SELinux 会阻止用户访问标签不允许访问的文件或进程。但是，仍然有可能利用此漏洞对主机操作系统的保密性、完整性或可用性产生某些影响。

问：利用此漏洞的可能性有多大？

答：如果您允许不受信任的用户在您的环境中运行容器，或者允许受信任的用户在环境中部署不受信任的容器，那么就很有可能会受到此问题的影响。

致谢

红帽感谢上游的 Open Containers Security Team 报告了此问题。上游机构感谢 Etienne Champetier 发现了此漏洞。

参考信息

• https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r
• 如何使用 GPG 来验证产品安全中的签名内容