Argo发布fuzzing报告｜使用OSS-Fuzz实行安全自动化

Argo 的持续 Fuzzing 集成

作者：Yuan Tang（Akuity）、Adam Korczynski 和 David Korczynski（Ada Logics）、Jann Fischer（Red Hat）、Henrik Blixt（Intuit）

安全是 Argo 项目的重中之重。为了提高安全性，来自 Akuity、Red Hat 和 Intuit 的 Argo 维护人员最近与 Ada Logics 合作，参与了一个由 CNCF（云原生计算基金会）委托的项目，为 Argo 项目建立 Fuzzing（模糊测试）。总而言之，这个项目建立了一个持续的 fuzzing 基础设施，现在作为项目循环工作的一部分运行。共开发了 41 个 fuzzer，发现了 10 个缺陷。所有发现的 bug 都已修复（除了在项目结束时发现的两个问题），并可在最新的项目补丁集中获得。在这篇博客文章中，我们将概述这项目的过程和结果，而完整的细节可以在Argo fuzzing 报告[1]中获得。

Fuzzing 是一种通用技术，用于自动识别可靠性和安全问题。它通常被安全研究人员用来发现系统中的漏洞，该技术已成功应用于各种 CNCF 项目，如 Kubernetes、Envoy、Helm、Linkerd2-proxy 和 Fluent-bit。fuzzing 的一般方法是使用遗传算法（genetic algorithm）与复杂的程序分析和软件仪器技术相结合，以生成在目标软件中实现高水平代码覆盖的输入。在 Argo 的环境中，这样做的目的是识别引发各种系统故障的输入，例如崩溃、恐慌、内存溢出问题和挂起。

OSS-Fuzz 的典型流程和集成

Ada logic 建立了一个 fuzzing 基础设施，并在 Argo 生态系统的各个子项目中实现了大量覆盖的 fuzzer。这是对 Argo 进行模糊测试的第一步，因为我们之前没有任何的模糊测试。这次合作的目标之一是创建一个有意义的和可持续的 fuzzing 基础设施，Argo 项目的维护者和贡献者可以使用它来观察结果，并将其应用到开发生命周期和发布过程中。

Fuzzer 集成

作为这次合作的一部分，Ada logic 一共开发了 41 个 fuzzer。Argo 项目的重点是 Argo Workflows、Argo CD、Argo Events、Argo Rollouts 和 GitOps Engine。通过 OSS-fuzz 将模糊器测试持续运行，并报告了 10 个错误。在项目结束时，除了在最后几天发现的两个问题外，所有的问题都被修复了。fuzzer 发现的 bug 分为以下几组：

• 4 个 nil-dereference
• 1 个切片超出范围
• 3 个索引超出范围
• 1 个接口转换问题
• 1 个内存不足

这些问题的细节和根本原因分析都列在 Argo fuzzing 报告的“Issues found”部分。

在该项目中开发的所有 fuzzer 都加到CNCF-Fuzzing 库[2]。然后指示 OSS-fuzz 从那里获取 fuzzer，并根据五个仓库中的每个最新的主分支构建它们。

大多数 fuzzer 每周至少跑 3-4 次。这种频率可以帮助 Argo 捕获新代码或修改代码中的问题，以及长时间未被修改的代码部分。这些模糊器（fuzzer）每天都要重新构建，以从每个项目中获得最新的更新，并测试任何最近可能阻碍模糊器运行的破坏性更改。失败的构建将报告给维护人员。

问题由 OSS-fuzz 报告。当发现问题时，Argo 的维护者会收到一封包含详细报告链接的电子邮件。该报告包括诸如堆栈跟踪、触发崩溃的模糊器的名称以及导致崩溃的确切测试用例等细节。这个测试用例可以用于在本地重现问题。所有在 OSS-fuzz 上的发现都有 90 天的宽限期，之后才会公开。如果一个问题在 90 天内得到修复，OSS-fuzz 会对此进行验证，并自动关闭该问题并公开它。

fuzzer 报告的问题可以在这里[3]公开获得，OSS-Fuzz 设置可以在这里[4]获得，Argo fuzzer 可以在CNCF-Fuzzing 仓库[5]中获得。

下一步

展望未来，我们将继续改进现有的 fuzzer 的覆盖范围，包括来自 Argo 生态系统的额外区域和子项目。当贡献者提交 PR 时，为新代码编写 fuzzer 将包含在检查表中，以帮助贡献者和维护人员在其他熟悉的测试过程之外，养成编写 fuzzer 的习惯。

Fuzzing 将在 Go 1.18 中得到原生支持，这有可能简化 fuzzer 的维护工作。OSS-Fuzz 基础架构已经支持在 Go 1.18 中为原生 fuzzing 引擎编写的 fuzzer，因此，我们计划过渡到使用这种类型的设置。

此外，当前的模糊器位于 CNCF-fuzzing 库。Argo 的维护者将讨论是否应该将这些模糊器转移到上游的子项目中。如果我们为 Go 1.18 的原生 fuzzing 引擎重写 fuzzer，fuzzer 可以放置在测试代码附近，类似于 Argo 的 Go 单元测试的处理方式。

鸣谢

我们要感谢 Ada logic 为 Argo 生态系统建立了 fuzzing 基础设施，并实现了一个广泛的 fuzzing 套件。在发现代码库中的 bug 方面，这项工作已经得到了回报。

我们还要感谢 CNCF 委托这项目。

最后和同样重要的是，我们要感谢 Argo 的维护者和贡献者，他们帮助解决了所有确定的问题。

参考资料

[1]Argo fuzzing 报告: https://github.com/argoproj/argoproj/blob/dd7cae43d81c5a11f21ff4ea0a4afadcae4799c7/docs/audit_fuzzer_adalogics_2022.pdf

[2]CNCF-Fuzzing 库: https://github.com/cncf/cncf-fuzzing

[3]fuzzer报告的问题: https://bugs.chromium.org/p/oss-fuzz/issues/list?q=argo

[4]OSS-Fuzz设置: https://github.com/google/oss-fuzz/tree/6b6196001560b3ab5d5ac33e73cc958ac2530c30/projects/argo

[5]Argo fuzzer: https://github.com/cncf/cncf-fuzzing/tree/789eea5ef9aff72fab52e9cb9070552baa3cd261/projects/argo