GLSA-202401-31：containerd：多个漏洞

high Nessus 插件 ID 189846

语言：

描述

远程主机会受到 GLSA-202401-31 中所述漏洞的影响（containerd：多个漏洞）

- containerd 是容器运行时。在 1.4.8 和 1.5.4 之前的 containerd 版本中发现一个错误，在这些版本中，提取特别构建的容器映像会更改主机文件系统中现有文件的 Unix 文件权限。文件权限变更可拒绝文件预期所有者的访问、扩大对其他文件的访问权限，或设置 setuid、setgid 和 sticky 等扩展位。此错误不会直接允许在没有其他合作进程的情况下读取、修改或执行文件。此错误已在 containerd 1.5.4 和 1.4.8 中修复。作为变通方案，确保用户只从受信任的来源提取图像。SELinux 和 AppArmor 等 Linux 安全模块 (LSM) 可通过防止 containerd 与特定文件交互的策略和配置文件，来限制可能受此错误影响的文件。(CVE-2021-32760)

- containerd 是一个强调简易性、稳定性和可移植性的开源容器运行时。
在 containerd 中发现一个错误，其中容器根目录和某些插件的限制权限不足，非特权 Linux 用户可利用此漏洞，遍历目录内容并执行程序。当容器包含的可执行程序具有扩展权限位（如 setuid）时，非特权 Linux 用户可发现并执行这些程序。当主机上的非特权 Linux 用户与容器内文件所有者或群组的 UID 冲突时，主机上的非特权 Linux 用户可发现、读取和修改这些文件。此漏洞已在 containerd 1.4.11 和 containerd 1.5.7 中修复。用户应在这些版本发布后进行相应更新，并可通过重新启动容器或更新目录权限来缓解此漏洞。无法更新的用户应限制受信任的用户访问主机的权限。更新绑定目录的容器的目录权限。(CVE-2021-41103)

- containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

- containerd 指容器运行时，可用作 Linux 和 Windows 的后台程序。在 containerd 1.6.1、 1.5.10 和 1.14.12 之前版本中发现一个错误，其中在 Linux 上通过 containerd 的 CRI 实现启动的容器可以使用特制的映像配置访问主机上任意文件和目录的只读副本。这可能会绕过对容器设置的任何基于策略的实施（包括 Kubernetes Pod 安全策略）并暴露潜在的敏感信息。
Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现。此错误已在 containerd 1.6.1、1.5.10和 1.4.12 中修复。用户应更新到这些版本以解决该问题。
(CVE-2022-23648)

- Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

- containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，即在“ExecSync”API 调用期间，容器内的程序可导致 containerd 后台程序无限制地消耗内存。这可能导致 containerd 消耗计算机上的所有可用内存，从而拒绝为其他合法工作负载提供服务。Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现；运行探测或通过 exec 设施执行进程时，可使用“ExecSync”。此错误已在 containerd 1.6.6 和 1.5.13 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的图像和命令。 (CVE-2022-31030)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。