Linux 内核中 cgroups v2022 资源限制机制实现中的漏洞 (CVE-0492-1) 的详细信息已被披露，该漏洞可用于逃逸隔离容器。 该问题自 Linux 内核 2.6.24 起就存在，并在内核版本 5.16.12、5.15.26、5.10.97、5.4.177、4.19.229、4.14.266 和 4.9.301 中得到修复。 您可以在以下页面关注发行版中软件包更新的发布：Debian、SUSE、Ubuntu、RHEL、Fedora、Gentoo、Arch Linux。
该漏洞是由于release_agent 文件处理程序中的逻辑错误造成的，该错误在以完全权限运行处理程序时无法执行正确的检查。 release_agent 文件用于定义当 cgroup 中的进程终止时内核要执行的程序。 该程序以 root 身份运行，并具有 root 命名空间中的所有“功能”。 假设只有管理员有权访问release_agent设置，但实际上检查仅限于向root用户授予访问权限，这并不排除从容器或没有管理员权限的root用户更改设置（CAP_SYS_ADMIN） ）。
以前，这样的功能不会被视为漏洞，但随着用户命名空间（user namespace）的出现，情况发生了变化，它允许您在容器中创建单独的 root 用户，这些用户与容器的 root 用户不重叠。主要环境。 因此，对于攻击来说，将release_agent处理程序连接到一个容器中就足够了，该容器在单独的用户ID空间中拥有自己的root用户，完成该过程后，将以主环境的完全权限执行。
默认情况下，cgroupfs 以只读模式挂载在容器中，但如果您具有 CAP_SYS_ADMIN 权限，或者通过使用 unshare 系统调用创建具有单独用户命名空间的嵌套容器，则以写入模式重新挂载此 pseudofs 没有问题，其中创建的容器具有 CAP_SYS_ADMIN 权限。
如果您在隔离容器中拥有 root 权限，或者在没有 no_new_privs 标志（禁止获取其他权限）的情况下运行容器，则可以进行攻击。 系统必须启用对用户命名空间的支持（在 Ubuntu 和 Fedora 中默认启用，但在 Debian 和 RHEL 中未激活）并有权访问根 cgroup v1（例如，Docker 在根 RDMA cgroup 中运行容器）。 如果您具有 CAP_SYS_ADMIN 权限，也可能发生攻击，在这种情况下，不需要支持用户命名空间和访问 cgroup v1 根层次结构。
除了逃离隔离容器之外，该漏洞还允许由没有“能力”的 root 用户或任何具有 CAP_DAC_OVERRIDE 权限的用户启动进程（攻击需要访问文件 /sys/fs/cgroup/*/release_agent，该文件是由 root 拥有）以获得对所有系统“功能”的访问权限。
值得注意的是，当使用 Seccomp、AppArmor 或 SELinux 保护机制对容器进行额外隔离时，该漏洞无法被利用，因为 Seccomp 会阻止对 unshare() 系统调用的访问，并且 AppArmor 和 SELinux 不允许以写入模式挂载 cgroupfs。
来源： opennet.ru