Ada Logics：CRI-O整体安全审计项目

作者：David Korczynski + Adam Korczynski

文章之前由 Ada Logics 安全研究与安全工程 David Korczynski 和安全工程与安全自动化 Adam Korczynski 在 Ada Logics 博客[1]上发表

Ada Logics Ltd. 最近对CRI-O[2]进行了全面的安全审计。CRI-O 是 Kubernetes 容器运行时接口[3]的一种实现，在 Kubernetes 集群中用作核心组件，在每个节点上编排容器。这使得它成为一个重要的软件包，因为 CRI-O 中的问题会产生深远的影响，因为它是许多 Kubernetes 集群的关键部分。

该审计项目的主要安全发现是一个严重的拒绝服务问题。对于任何有能力在 Kubernetes 集群上创建 pod 的人来说，这是一种节点级的拒绝服务攻击。本质上，如果一个人可以在给定的 Kubernetes 集群中的一个节点上创建一个 pod，那么他就可以通过内存耗尽的方式造成拒绝服务攻击。这是针对依赖 CRI-O 运行时的节点，有趣的是，该漏洞也存在于另一个流行的容器运行时 Containerd[4]中。

我们要感谢 CRI-O 维护者的合作。这项工作得到了 CNCF[5]的资助，并得到了 OSTIF[6]的协助。除了我们的工作，Chainguard[7]也参与了软件安全供应链审计。我们要感谢所有的合作者。

在这篇博客文章中，我们将给出一个项目的概述，完整的细节可以在 CRI-O 仓库的报告中找到。

审计和结果摘要

该审计项目的目标是对 CRI-O 的安全态势进行广泛分析，分为以下任务：

1. CRI-O 的威胁模型形式化
2. 代码的安全审计
3. CRI-O 的模糊测试集成，包括通过OSS-Fuzz[8]的持续模糊测试集成
4. 审查文件和测试

这项工作的主要安全发现是一个单一的高严重性问题。也发现了一些小问题，但是，我们从完成这次审计的角度来看，CRI-O 是一个编写良好的项目，具有高水平的安全保证。

通过部署方式的集群拒绝服务

严重性最高的发现是通过耗尽节点资源的方式对给定集群进行拒绝服务攻击。攻击是通过创建 pod 的方式进行的，这意味着任何可以创建 pod 的用户都可以在用于创建 pod 的给定节点上造成拒绝服务。此漏洞的 CVE 是 CVE-2022-1708，Github 安全公告可在此处找到：https://github.com/cri-o/cri-o/security/advisories/GHSA-fcm2-6c3h-pg6j

有趣的是，拒绝服务攻击也发生在其他容器运行时接口实现中，最显著的是 Containerd。具体来说，耗尽 CRI-O 中的内存的攻击可以用来耗尽 Containerd 的内存。containerd 问题的 CVE 是 CVE-2022-31030，关于 containerd 的 Github 安全公告可在此处找到：https://github.com/containerd/containerd/security/advisories/GHSA-5ffw-gxpp-mxpf

在 Kubernetes 的世界中，对于 CRI-O 和 Containerd 来说，这个问题可以通过没有任何用户交互的部署方式导致节点的拒绝服务，如果集群使用这些容器运行时接口实现中的任何一个，就会有效地启用集群 DOS。强烈建议打补丁。

CRI-O 的持续模糊测试集成

我们针对 CRI-O 基础设施集成了一个广泛的模糊测试套件。这方面的主要挑战是建立基础设施，使 CRI-O 的模糊测试能够工作，这是很困难的，因为 CRI-O 是一个互连的系统，依赖于许多组件，例如系统上的二进制文件，主要通过 Kubelet 进行通信，kubelet 限制发送到 CRI-O 的数据，并且还使用相当复杂的测试框架，涉及许多许多模拟。

总的来说，我们针对 CRI-O 代码、containers/image[9]和 containers/storage[10]仓库实现了 14 个模糊测试器，并将该项目集成到 OSS-Fuzz。模糊测试器可从 https://github.com/cncf/cncf-fuzzing/tree/main/projects/cri-o获得，OSS-Fuzz的集成是在https://github.com/google/oss-fuzz/tree/master/projects/cri-o。

模糊测试的主要焦点是针对 gRPC 处理程序。这主要是由 fuzz_server[11]完成，它是一个相当大的模糊测试器，包含 900 行代码。这个模糊测试器启动一个 gRPC 服务器，并向该服务器发送随机消息序列。通过这种方式，模糊测试器在 CRI-O 的整个代码中具有显著的影响力。

参考

• 完整 PDF 报告：https://github.com/cri-o/cri-o/blob/main/security/2022_security_audit_adalogics.pdf
• CRI-O 安全公告：https://github.com/cri-o/cri-o/security/advisories/GHSA-fcm2-6c3h-pg6j
• Containerd 安全公告：https://github.com/containerd/containerd/security/advisories/GHSA-5ffw-gxpp-mxpf
• OSTIF 公告：https://ostif.org/our-audit-of-cri-o-is-complete-high-severity-issues-found-and-fixed/

参考资料

[1]

Ada Logics 博客: https://adalogics.com/blog/cri-o-security-engagement

[2]

CRI-O: https://github.com/cri-o/cri-o

[3]

Kubernetes 容器运行时接口: https://github.com/kubernetes/cri-api

[4]

Containerd: https://containerd.io/

[5]

CNCF: https://www.cncf.io/

[6]

OSTIF: https://ostif.org/

[7]

Chainguard: https://www.chainguard.dev/

[8]

OSS-Fuzz: https://google.github.io/oss-fuzz/

[9]

containers/image: https://github.com/containers/image

[10]

containers/storage: https://github.com/containers/storage

[11]

fuzz_server: https://github.com/cncf/cncf-fuzzing/blob/main/projects/cri-o/fuzz_server.go

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。