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/