几天前 消息发布 细节已经披露 脆弱性 发现 在机制执行中 资源限制 cgroup v1 在 Linux 内核中，该内核已在 CVE-2022-0492 下编目。
发现此漏洞e 可用于退出隔离容器 并详细说明该问题自 Linux 内核 2.6.24 以来一直存在。
在博客文章中提到 该漏洞是由于 release_agent 文件处理程序中的逻辑错误， 所以当驱动程序以完全权限运行时没有执行正确的检查。
文件 release_agent 用于定义内核执行的程序 当一个进程以 cgroup 结束时。 该程序以 root 身份运行，具有根名称空间中的所有“功能”。 只有管理员应该有权访问 release_agent 配置，但实际上，检查仅限于授予 root 用户访问权限，这并不排除从容器或非管理员 root 用户 (CAP_SYS_ADMIN) 更改配置.
此前， 此功能不会被视为漏洞，但是随着用户标识符命名空间（用户命名空间）的出现，情况发生了变化，它允许您在不与主环境的 root 用户重叠的容器中创建单独的 root 用户。
因此， 对于攻击，在拥有自己的 root 用户的容器中就足够了 在单独的用户 ID 空间中插入您的 release_agent 处理程序，一旦该过程完成，它将以父环境的所有权限运行。
默认情况下，cgroupfs 挂载在只读容器中，但在写入模式下使用 CAP_SYS_ADMIN 权限重新挂载此 pseudofs 或通过使用停止共享的系统调用创建具有单独用户命名空间的嵌套容器没有问题，其中 CAP_SYS_ADMIN 权限可用于创建的容器。
攻击 可以通过在隔离容器中拥有 root 权限来完成 或者通过在没有 no_new_privs 标志的情况下运行容器，该标志禁止获得额外的权限。
系统必须启用对命名空间的支持 用户（在 Ubuntu 和 Fedora 上默认启用，但在 Debian 和 RHEL 上未启用）并有权访问根 v1 cgroup（例如，Docker 在 RDMA 根 cgroup 中运行容器）。 使用 CAP_SYS_ADMIN 权限也可能进行攻击，在这种情况下，不需要支持用户命名空间和访问 cgroup v1 的根层次结构。
除了突破隔离的容器外，该漏洞还允许由没有“能力”的root用户或任何具有CAP_DAC_OVERRIDE权限的用户启动的进程（攻击需要访问由拥有的/sys/fs/cgroup/*/release_agent文件root) 以获取对系统所有“功能”的访问权限。
除了容器之外，该漏洞还可能允许没有功能的根主机进程或具有 CAP_DAC_OVERRIDE 功能的非根主机进程将权限升级为完整功能。 这可能允许攻击者绕过某些服务使用的强化措施，这些服务会删除功能以尝试在发生危害时限制影响。
Unit 42 建议用户升级到固定内核版本。 对于那些运行容器，启用 Seccomp 并确保 AppArmor 或 SELinux 已启用。 Prisma Cloud 用户可以参考“Prisma Cloud 保护”部分来查看 Prisma Cloud 提供的缓解措施。
请注意，当使用 Seccomp、AppArmor 或 SELinux 保护机制进行额外的容器隔离时，无法利用该漏洞，因为 Seccomp 会阻止 unshare() 系统调用，并且 AppArmor 和 SELinux 不允许以写入模式挂载 cgroupfs。
最后，值得一提的是，它已在内核版本 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.
最后 如果您有兴趣了解更多有关它的信息，您可以在中查看详细信息 以下链接。