Kubernetes所使用的其中一个Go代码库中存在漏洞，该漏洞可能会导致CRI-O和Podman容器引擎的拒绝服务攻击。

该漏洞（CVE-2021-20291）会影响一个名为 "containers/storage "的Go语言代码库。据发现该漏洞的Unit 42团队的安全研究员Aviv Sasson介绍，该漏洞可以通过在注册表内放置一个恶意镜像来触发；当该镜像被恶意攻击者从注册表中调出时，就可以进行DoS攻击。

Sasson在周三的一篇文章中说:"通过这个漏洞，恶意攻击者可能会攻击包括Kubernetes和OpenShift在内的任何一个依赖有漏洞的容器引擎的基础设施"

CRI-O和Podman都是容器引擎，类似于Docker，主要用于在云端执行操作和管理容器。CRI-O和Podman使用”containers/storage”来处理容器镜像的存储和下载。

研究人员称，当该漏洞被触发时，CRI-O就无法拉取新的镜像、启动任何新的容器（即使它们已经被拉取到本地）、检索本地镜像列表或停止容器运行。

同样，Podman也将无法拉取新的镜像，检索正在运行的pods，启动新的容器（即使它们已经被拉取到本地），检索现有的镜像或终止所有的容器。

这个漏洞影响可能非常广泛。Sasson解释说:"从Kubernetes v1.20开始，Docker就已经被废弃使用，现在唯一支持的容器引擎是CRI-O和 Containerd，这就导致了很多集群使用CRI-O。在实际的攻击场景中，攻击者可能会将一个恶意镜像拉到多个不同的节点上，使所有节点崩溃，破坏集群。而除了重新启动节点外，目前没有任何解决问题的方法。"

容器武器化

当容器引擎从注册表中提取一个镜像时，它首先会下载清单，其中会含有关于如何构建映像的说明。其中一部分是组成容器文件系统的层列表，容器引擎会读取该列表，然后下载并解压每个层。

Sasson解释说："攻击者可以向注册表中上传一个可以利用该漏洞的恶意层，然后上传一个使用众多层的镜像，包括恶意层，并借此创建一个新的恶意镜像。然后，当受害者从注册表中提取镜像时，它将会在该过程中下载恶意层，从而完成该漏洞的利用。"

一旦容器引擎开始下载恶意层，最终的结果就是发生死锁。

Sasson解释说："在这种情况下，进程会获取到锁，并且这个锁永远都不会被释放，这将导致DoS发生，因为此时其他线程和进程都会停止执行并永远等待锁被释放。"

他列出了该漏洞被触发时发生的步骤。

例程1--从注册表下载恶意层。

例程1 - 从注册表中下载恶意层.进程1 获取锁。

例程2 - 使用xz二进制解压下载的层，并将输出写入到stdout。

例程3 - 等待xz退出并读取stdout中的所有数据。当条件满足时，它会关闭一个名为chdone的通道。

例程1 - 使用 xz 的输出作为输入，并尝试解压缩数据。由于文件不是 tar 存档文件，untar 会出现"invalid tar header "报错，并且不会从 xz 的标准输出中读取其余数据。由于数据永远不会被读取，例程3现在是死锁，也就永远不会关闭chdone。

例程1 - 等待例程3关闭chdone，也是死锁。

一旦例程1被死锁，容器引擎就无法执行任何新的请求，因为如果要执行新的请求，它需要获取步骤2的锁，而这个锁永远都不会被释放。

containers/storage的1.28.1版本、CRI-O的v1.20.2版本和Podman的3.1.0版本都发布了该bug的补丁。管理员应尽快更新。

容器安全成为了焦点

云容器仍然是网络攻击者的攻击的重点。例如，4月早些时候就发现了一个有组织的、进行广泛攻击的密码窃取活动，其攻击目标是配置错误的开放的Docker Daemon API端口。每天都可以观察到数千次与该活动相关的攻击。

研究人员表示，同样是在4月份，在微软的云容器技术Azure Functions中发现存在一个漏洞，该漏洞允许攻击者直接写入文件。这是一个权限升级漏洞，最终可能让攻击者实现容器逃逸。

而在最近的一次实验室测试中，一个简单的Docker容器蜜罐在24小时内发生了四次不同的网络攻击，这是一个很直接的例子，可以说明为什么云基础设施需要强大的安全性。

本文翻译自：https://threatpost.com/security-bug-brick-kubernetes-clusters/165413/如若转载，请注明原文地址