CVE-2022-0185 Linux内核漏洞对Kubernetes | JFrog的影响

上周，一个严重的漏洞被识别为CVE-2022-0185被披露，影响Linux内核5.1到5.16.1版本。的安全漏洞是Filesystem Context模块中的整数下流，允许本地攻击者在内核上下文中运行任意代码，从而导致特权升级、容器环境转义或拒绝服务。

该漏洞是在谷歌的KCTF漏洞赏金计划——一个基于Kubernetes的CTF，鼓励研究人员在所有GKE(谷歌Kubernetes引擎)依赖项中发现新的可利用的漏洞，这些漏洞可能导致Kubernetes底层节点的妥协。这自然包括Linux内核特权升级漏洞，如CVE-2022-0185，研究人员因此获得了31337美元的奖励。

在这篇博客文章中，我们对这个新发现的Linux内核漏洞进行了简短的技术概述，并描述了最近增加了被利用可能性的开发情况。我们还分享了安全漏洞如何影响最常用的Kubernetes引擎(包括Amazon EKS、Azure AKS和谷歌GKE)的自我管理部署的详细信息。

CVE-2022-0185技术摘要

该漏洞是由整数下溢造成的legacy_parse_param．这个函数将接收到的配置填充到缓冲区中ctx - > legacy_data并依赖于缓冲区大小ctx - > data_size(在下面的代码段中命名为size)稍后执行内存复制。

不幸的是，当size为4095或更大时，可以写入的最大字节的计算可能会溢出，这将导致限制绕过以及随后的巨大复制大小。

if (len > PAGE_SIZE - 2 - size)返回invalf(fc， "VFS: Legacy: Cumulative options too large");if (strchr(param->key， '，') || (param->type == fs_value_is_string && memchr(param->string， '，'， param->size))返回invalf(fc， "VFS: Legacy:选项'%s'包含逗号"，param->key);if (!ctx->legacy_data) {ctx->legacy_data = kmalloc(PAGE_SIZE, GFP_KERNEL);if (!ctx->legacy_data) return - enomem;｝

在第551行可以看到大小4095或更大，计算PAGE_SIZE - 2大小会产生巨大的正值吗页大小是4 kb。然后会有一个越界写(在第566行):

Ctx ->legacy_data[size++] = '，';Len = strlen(参数->key);(ctx->legacy_data + size, param->key, len);Size += len;如果(param - >类型= = fs_value_is_string) {ctx - > legacy_data[大小 ++] = '=';

这种越界写入可用于任意代码执行。虽然确切的利用方法超出了本博客的范围，但我们强烈推荐技术那样欲知详情。

CVE-2022-0185漏洞可利用程度如何?

此漏洞的利用链包括特权系统调用，例如fsopen ()，要求攻击者拥有CAP_SYS_ADMIN利用此漏洞的能力(在任何名称空间中)。例如，当容器以特权模式执行时，将授予此功能。幸运的是，Docker和其他容器化解决方案在默认情况下禁用了此设置，除非使用——特权标志或通过在安全上下文Kubernetes中Pod的CustomResourceDefinition (CRD)部分。

尽管存在CAP_SYS_ADMIN这种能力似乎是攻击者难以利用的先决条件，攻击者可以在任何用户名称空间中实现它，包括在无特权容器中。这是一个改变游戏规则的漏洞，使其有可能在常见的Kubernetes环境中被利用。在此攻击场景下，攻击者可以实现CAP_SYS_ADMIN功能，通过调用共享客户容器的功能，以输入该功能可用的新名称空间。而在Docker环境中，此操作在默认情况下被seccomp在Kubernetes部署中，过滤器默认是禁用的。

几天前，有人利用了这个漏洞发表，包括广泛的技术那样CTF“Rust十字军”团队发现了这个漏洞。不久之后，另一位研究人员发表了另一篇文章开发和技术报告．这些出版物使此漏洞很可能在野外被利用。

如何检测CVE-2022-0185?

要检测此漏洞，应检查Linux内核版本和配置。

易受攻击的香草内核版本为5.1到5.16.1。在已知的Kubernetes引擎中，供应商可能会应用特定的内核补丁。请参见引擎固定节点版本下面．

只有当“用户名称空间”(CONFIG_USER_NS)特性在内核中被启用。请注意，要利用此漏洞进行容器转义，还有其他先决条件。看到可利用性上面的部分。

如何修复自管理Kubernetes上的CVE-2022-0185 ?

Amazon EKS, Azure AKS和谷歌GKE是目前最受欢迎的Kubernetes引擎。这些引擎可以自动部署、扩展和管理容器化应用程序。

由于被破坏的容器与主机(节点)之间的横向移动，此容器破坏漏洞可能导致大规模破坏。对于那些拥有自己平台的公司来说尤其如此自我管理Kubernetes引擎。

对于自我管理的环境，环境管理员需要手动更新底层引擎节点映像。以下是修复CVE-2022-0185的相关引擎图像:

	的—升级EKS AMI为releasev20220123．描述了使用新的AMI升级自管理节点堆栈的说明在这里．
	部—升级节点镜像到版本号2022.01.24．可以找到升级AKS节点映像的说明在这里．详情见AKS的问题．
	GKE-目前没有GKE的版本包含此问题的修复程序。而谷歌容器优化操作系统的固定版本已经创建，即-因为- 85 - 13310 - 1366 - 24，因为- 89 - 16108 - 604 - 3，因为- 93 - 16623 - 102 - 4，这些操作系统尚未在任何GKE渠道提供。我们强烈建议应用下面“缓解”一节中概述的缓解方法。当GKE有固定版本时，我们会更新这篇博客，敬请期待。

如何在Kubernetes之外修复CVE-2022-0185 ?

建议通过软件升级解决该漏洞。

许多主要的Linux发行版都发布了一个固定的内核。参见相关升级说明Ubuntu，Debian或红色的帽子．

对于在托管发行版之外运行的用户，该漏洞已在版本5.16.2的普通Linux内核中修复。建议对该版本执行内核更新，或者应用漏洞补丁到您的内核源代码并重新构建内核。

CVE-2022-0185的缓解措施是什么?

如果无法升级或修补内核，那么将特权容器的数量缩小到尽可能小的程度就非常重要。同样作为非特权容器的缓解措施，建议使用以下命令禁用Linux非特权用户名称空间:

Sysctl -w内核。Unprivileged_userns_clone = 0

保持最新的安全研究

在我们的JFrog安全研究团队中跟踪最新的发现和技术更新安全研究博客文章并在推特上@JFrogSecurity．

CVE-2022-0185 Linux内核漏洞对主流Kubernetes引擎的影响