Mozilla一直在掩盖Firefox及其底层组件，事实证明它是识别质量和安全漏洞的最有效方法之一。通常，研究人员在不同级别应用模糊测试：浏览器作为一个整体进行模糊测试，但也花费了大量时间对孤立代码（例如使用libFuzzer）或整个组件（例如使用单独shell的JS引擎）进行模糊测试。)进行模糊测试。在本文中，研究人员将仅负责解释浏览器混淆漏洞并详细说明他们发现的方法。为了构建尽可能有效的工具，研究人员使用了多种漏洞检测方法。其中包括AddressSanitizer（带有LeakSanitizer）、ThreadSanitizer和UndefinedBehaviorSanitizer等清理器，以及使用调试构建来启用断言和其他运行时检查。研究人员还使用了rr和Valgrind等调试器。这些工具中的每一个都提供了不同的视角来帮助发现特定类型的漏洞，但许多工具彼此不兼容或需要它们自己的定制版本才能运行或提供最佳结果。除了提供调试和漏洞检测外，有些工具在没有构建工具的情况下无法工作，例如代码覆盖率和libFuzzer。每个操作系统和架构组合都需要一个独特的构建，并且可能只支持这些工具的一个子集。最后，每个变体都有多个活动变体，包括Release、Beta、nightly和ExtendedSupportReleases（“ESR”），每个变体都由FirefoxCITaskcluster实例定期构建。所谓nightly版本，通常是开发者自己维护的版本。白天，开发人员将他们的更改提交到中央代码存储库，然后在晚上做一个编译版本。一般来说，夜间版本会包含最新的bug修复和新特性，因此适合关注某个bug，或者特别喜欢最新版本的用户。但是因为没有经过全面测试，可能存在很多不稳定性。下载版本Taskcluster使查找和下载最新版本以进行测试变得容易。研究人员在上面讨论了研究人员需要自动化混淆的不同仪表类型创建的变体数量。由于构建、工件、体系结构、操作系统和每个包的大量组合，下载是一项艰巨的任务。为了帮助降低构建管理的复杂性，研究人员开发了一种名为fuzzfetch的工具。Fuzzfetch可以轻松指定所需的构建参数，并将下载并解压缩该构建。如何生成测试用例由于这篇博文的目的是解释整个过程，研究人员不会花太多时间解释模糊测试，使用公开可用和自定义模糊器的组合来生成测试用例。如何执行、报告和扩展对于以浏览器为目标的模糊器，Grizzly管理和运行测试用例并监控结果。创建适配器可以让研究人员轻松地在Grizzly中运行现有的模糊器。Grizzly是一个应用程序框架，旨在解决在编写成千上万的用户访问服务器时出现的各种漏洞。为了充分利用任何给定设备上的可用资源，研究人员并行运行多个Grizzly实例。对于每个模糊器，研究人员都创建了容器来封装运行它所需的配置。这些都存在于Orionmonorepo中。 Monorepo是什么？Monorepo并不是一个新概念。在软件工程领域，已有十多年的历史。概念很好理解，就是把多个项目放在一个仓库里。与之相反的是传统的MultiRepo模式，即每个项目对应一个单独的仓库，进行分散管理。每个模糊器都有一个配置，可以根据该模糊器的优先级配置特定的部署和资源分配。Taskcluster不断部署这些配置来分配工作和管理模糊测试节点。GrizzlyTarget处理挂起、崩溃和其他错误等漏洞的检测。Target是Grizzly和浏览器之间的接口。检测到的漏洞会自动打包并报告给FuzzManager服务器。FuzzManager服务器提供了一个用于自动化和过滤结果的UI。其他更有针对性的模糊器使用JSshell，而基于libFuzzer的目标使用模糊测试接口。许多第三方库也在OSS-Fuzz中进行了模糊测试，这些超出了本文的范围。模糊测试结果在不同目标上大规模运行多个模糊器会产生大量数据，这些崩溃不适合直接输入到Bugzilla等错误跟踪系统中。FuzzManager客户端库可以在离开模糊测试节点之前过滤崩溃变化和重复结果。独特的结果将报告给FuzzManager服务器。通过FuzzManager的Web界面，可以创建签名、将报告分组到桶中并帮助客户端检测重复结果。模糊器通常会生成数百甚至数千行长的测试用例。FuzzManager桶将自动扫描Taskcluster中的队列减少任务。这些恢复任务使用GrizzlyReduce和Lithium来应用不同的恢复策略，通常会删除大部分不必要的数据。将继续处理每个存储桶，直到恢复操作成功完成。然后，工程师可以对最小化的测试用例进行最终检查，并将它们附加到漏洞报告中。最终结果通常用作Firefox测试套件中的崩溃测试。请点击这里查看测试过程。模糊器的代码覆盖率也会定期测量，再次使用FuzzManager收集代码覆盖率数据并生成覆盖率报告。漏洞报告由于研究人员的目标是创建可操作的漏洞报告，以尽快修复漏洞，同时最大限度地减少开发人员的开销。研究人员通过以下方式做到这一点：崩溃信息，例如日志和堆栈跟踪；构建和环境信息；减少测试用例；Pernosco会议；回归范围（通过Bugmon拆分）；通过Bugmon验证；GrizzlyReduce的基本执行引擎工具，可以轻松收集rr跟踪以提交给Pernosco。它使重新运行浏览器测试用例变得容易，以供自动和手动使用。如前所述，研究人员也一直在使用Pernosco。Pernosco是一个为rrtraces提供web界面的工具，使开发人员能够在不直接访问执行环境的情况下使用它们。这是同名公司开发的工具，可以极大地帮助调试大规模并行应用程序。当测试用例太不可靠而无法减少或附加到漏洞报告时，它也非常有用。创建rr跟踪并上传它可以生成不再使用的可操作错误报告。Grizzly和Pernosco的结合还有一个额外的好处，那就是让不常见的、难以重现的漏洞变得可行。一个非常不一致的漏洞的测试用例可以运行数百或数千次，直到在rr下发生所需的崩溃。跟踪会自动收集并准备好提交给Pernosco并由开发人员修复，而不是因为它不可操作而被忽略。要正确评估新功能，您可以联系fuzzing@mozilla.com或通过Matrix。一旦开始对组件进行模糊测试，研究人员将主要通过Bugzilla进行交流。如前所述，研究人员努力解决可修复的漏洞。Bugmon用于自动平分回归范围并尽快通知合适的人，并在错误标记为“已修复”后进行验证。关闭漏洞会自动将其从FuzzManager中删除，因此如果在代码库中发现类似的漏洞，可以再次识别它。在模糊测试期间发现的一些漏洞会阻止研究人员有效地模糊函数或构建变体，这些被称为模糊测试阻止程序，它们有几种不同的形式。从生产的角度来看，这些漏洞可能看起来是无害的，但它们可以阻止模糊器以重要的代码路径为目标，甚至可以完全阻止模糊测试目标。正确确定这些漏洞的优先级并快速修复它们非常有用。PrefPicker管理用于模糊测试的Firefox首选项集。在首选项后添加功能时，请考虑将其添加到PrefPicker模糊模板以在模糊期间启用它。定期审核PrefPicker模糊模板有助于确保没有遗漏任何区域并尽可能高效地使用资源。与其他领域一样，测量是评估成功的关键部分。研究人员利用Bugzilla的元错误功能来帮助追踪模糊器识别的漏洞。研究人员努力为每个模糊器和每个被模糊化的新组件都有一个元错误。例如，Domino的元错误列出了该工具识别的所有漏洞（超过1100个）。使用此Bugzilla数据，研究人员能够显示多年来各种模糊测试的影响。模糊测试中有许多组件在不断发展以适应调试工具、执行环境和浏览器内部结构的变化。开发人员总是在添加、删除和更新浏览器功能。本文翻译自：https://blog.mozilla.org/attack-and-defense/2021/05/20/browser-fuzzing-at-mozilla/如有转载请注明出处。
