cgroup漏洞集
2022-03-07 16:44:12 
阿炯
Linux 内核出现新的 cgroups 漏洞，可提升用户权限
2022年3月上旬消息，Linux 内核出现了一个新的 cgroups 漏洞，代号为 CVE-2022-0492 ，该漏洞可能被滥用以逃避容器，以便在容器主机上执行任意命令。
漏洞出自被称为 cgroups 控制组的 Linux 内核功能，cgroups 允许将进程组织成分层组，从而可以限制和监视 CPU、内存等资源的使用情况、磁盘 I/O 和网络。
但由于 cgroups 内部缺少对 release_agent 文件的验证，未能正确检查设置 release_agent 文件的进程是否具有管理权限，攻击者可以利用该 cgroups v1 release_agent 功能来提升权限并意外绕过命名空间隔离。
也就是说，如果这个 release_agent 文件被攻击者掌握，那么该 Linux 内核可以被强制调用，在 release_agent 中配置具有最高权限的任意二进制文件——这意味着攻击者可以完全接管机器。值得注意的是，只有具有“root”权限的进程才能写入文件，这意味着该漏洞仅允许 root 进程提升权限。
该漏洞号为 CVSS 评分为7.0，影响 cgroups v1 release_agent 功能中的提权例子，该脚本在 cgroup 中的任何进程终止后执行。这个漏洞是最近发现的最简单的 Linux 提权手段之一，Linux 内核错误地将特权操作暴露给非特权用户。
cgroups的手册页对其功能的解释如下：当特定 cgroup 变空时是否调用 release_agent 程序，由相应 cgroup 目录下 notify_on_release 文件中的值决定。如果此文件包含值 0，则不会调用 release_agent 程序。如果它包含值 1，则调用 release_agent 程序。此文件在根 cgroup 中的默认值为 0。
具体来说，该漏洞是由于缺少验证来检查设置 release_agent 文件的进程是否具有管理权限，从而使其能被成功地利用。换句话说，如果这个 release_agent 文件被攻击者覆盖，内核可以被强制调用在发布代理中配置的具有最高权限的任意二进制文件，这种情况可以完全地接管机器。然而，值得注意的是，只有具有 root 权限的进程才能写入文件，这意味着该漏洞仅允许 root 进程提权。乍一看觉得只有root权限才能利用该漏洞，是不是就可以高枕无忧了？事实上，很多人都是用root权限来运行docker容器，在这种情况下，该漏洞就显得非常地危险。
尽管运行AppArmor或SELinux的容器受到保护，但建议用户尽快升级安全补丁，因为它可能被其他恶意主机进程滥用以提升权限。这远不是 release_agent 第一次作为攻击媒介出现。2017 年 7 月，谷歌研究员展示了一个“快速而肮脏”的概念验证 (PoC) 漏洞利用该功能突破特权 Kubernetes 和 Docker 容器。该漏洞 CVE-2022-0492 标志着另一个可用于容器逃逸的 Linux 漏洞，幸运的是，遵循最佳实践的环境受到了保护，不受此漏洞的影响。
2022年3月上旬消息，Linux 内核出现了一个新的 cgroups 漏洞，代号为 CVE-2022-0492 ，该漏洞可能被滥用以逃避容器，以便在容器主机上执行任意命令。
漏洞出自被称为 cgroups 控制组的 Linux 内核功能，cgroups 允许将进程组织成分层组，从而可以限制和监视 CPU、内存等资源的使用情况、磁盘 I/O 和网络。
但由于 cgroups 内部缺少对 release_agent 文件的验证，未能正确检查设置 release_agent 文件的进程是否具有管理权限，攻击者可以利用该 cgroups v1 release_agent 功能来提升权限并意外绕过命名空间隔离。
也就是说，如果这个 release_agent 文件被攻击者掌握，那么该 Linux 内核可以被强制调用，在 release_agent 中配置具有最高权限的任意二进制文件——这意味着攻击者可以完全接管机器。值得注意的是，只有具有“root”权限的进程才能写入文件，这意味着该漏洞仅允许 root 进程提升权限。
该漏洞号为 CVSS 评分为7.0，影响 cgroups v1 release_agent 功能中的提权例子，该脚本在 cgroup 中的任何进程终止后执行。这个漏洞是最近发现的最简单的 Linux 提权手段之一，Linux 内核错误地将特权操作暴露给非特权用户。
cgroups的手册页对其功能的解释如下：当特定 cgroup 变空时是否调用 release_agent 程序，由相应 cgroup 目录下 notify_on_release 文件中的值决定。如果此文件包含值 0，则不会调用 release_agent 程序。如果它包含值 1，则调用 release_agent 程序。此文件在根 cgroup 中的默认值为 0。
具体来说，该漏洞是由于缺少验证来检查设置 release_agent 文件的进程是否具有管理权限，从而使其能被成功地利用。换句话说，如果这个 release_agent 文件被攻击者覆盖，内核可以被强制调用在发布代理中配置的具有最高权限的任意二进制文件，这种情况可以完全地接管机器。然而，值得注意的是，只有具有 root 权限的进程才能写入文件，这意味着该漏洞仅允许 root 进程提权。乍一看觉得只有root权限才能利用该漏洞，是不是就可以高枕无忧了？事实上，很多人都是用root权限来运行docker容器，在这种情况下，该漏洞就显得非常地危险。
尽管运行AppArmor或SELinux的容器受到保护，但建议用户尽快升级安全补丁，因为它可能被其他恶意主机进程滥用以提升权限。这远不是 release_agent 第一次作为攻击媒介出现。2017 年 7 月，谷歌研究员展示了一个“快速而肮脏”的概念验证 (PoC) 漏洞利用该功能突破特权 Kubernetes 和 Docker 容器。该漏洞 CVE-2022-0492 标志着另一个可用于容器逃逸的 Linux 漏洞，幸运的是，遵循最佳实践的环境受到了保护，不受此漏洞的影响。