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

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

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

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

CVE-2022-0185技术总结

的整数下溢出导致该漏洞legacy_parse_param。这个函数将接收到的配置填充到缓冲区中ctx - > legacy_data这取决于缓冲区的大小ctx - > data_size(在下面的代码片段中命名为size)稍后执行内存复制。

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

if (len > PAGE_SIZE - 2 - size) return 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: Option '%s' contains逗号"，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(param->key);Memcpy (ctx->legacy_data + size，参数->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团队“Crusaders of Rust”发现的。不久之后，另一位研究人员发表了另一篇文章开发和技术报告。这些发布使得该漏洞很可能在野外被利用。

如何检测CVE-2022-0185?

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

易受攻击的vanilla内核版本是5.1到5.16.1。在已知的Kubernetes引擎中，供应商可能会应用特定的内核补丁。查看固定引擎节点版本下面。

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

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

Amazon EKS、Azure AKS和Google GKE是目前使用的最流行的Kubernetes引擎。这些引擎自动化了容器化应用程序的部署、扩展和管理。

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

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

	的—升级EKS AMI至发布v20220123。描述了使用新的AMI升级自管理节点堆栈的说明在这里。
	部—升级节点镜像到version2022.01.24。可以找到升级AKS节点映像的说明在这里。更多信息可在这个AKS问题。
	GKE—目前没有版本的GKE包含此问题的修复程序。虽然已经创建了固定版本的Google容器优化操作系统，即-因为- 85 - 13310 - 1366 - 24，因为- 89 - 16108 - 604 - 3，因为- 93 - 16623 - 102 - 4，这些操作系统还不能在任何GKE通道中使用。我们强烈建议应用下面“缓解”一节中概述的缓解方法。当一个固定的版本在GKE中可用时，我们将更新这篇博文，敬请关注。

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

建议采用软件升级的方式解决该漏洞。

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

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

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

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

Sysctl -w kernel。Unprivileged_userns_clone = 0

保持最新的安全研究

关注JFrog安全研究团队的最新发现和技术更新安全研究博客文章并在推特上@JFrogSecurity。