Mozilla一直在模糊Firefox及其底層組件，它已被證明是識別質量和安全漏洞的最有效方法之一。通常，研究人員會在不同級別上應用模糊測試：瀏覽器作為一個整體進行模糊測試，但也需要花費大量時間來對孤立的代碼（例如使用libFuzzer）或整個組件（例如使用單獨的外殼的JS引擎）進行模糊測試。在此文中，研究人員將只負責解釋瀏覽器模糊漏洞，并詳細介紹他們已經尋找到的方法。

　　構建工具

　　為了盡可能有效，研究人員使用了多種漏洞檢測方法。這些包括清除器，如AddressSanitizer（帶有LeakSanitizer）、ThreadSanitizer和UndefinedBehaviorSanitizer，以及使用調試構建來啟用斷言和其他運行時檢查。研究人員還使用了像rr和Valgrind這樣的調試器。這些工具中的每一個都提供了不同的視角來幫助發現特定的漏洞類型，但許多工具彼此不兼容，或者需要使用自己的自定義版本才能發揮作用或提供最佳結果。除了提供調試和漏洞檢測外，一些工具如果沒有構建工具就無法工作，例如代碼覆蓋率和libFuzzer。每個操作系統和體系結構組合都需要一個獨特的構建，并且可能只支持這些工具的一個子集。

　　最后，每個變體都有多個活動變體，包括發行版，Beta版、nightly版本和延長支持版本（Extended Support Release, 簡稱“ESR”），Firefox CI Taskcluster實例會定期構建每個實例。所謂nightly版本，通常是開發者自己維護的一個版本。白天的時候開發者們將各自的修改提交到一個中心代碼庫，然后在晚上做一次編譯得到的版本。一般來說nightly版本會包含最新的漏洞修改和新增功能，所以適合那些關注某個漏洞，或者是特別喜歡最新版本的用戶使用。但是因為沒有經過充分的測試，可能會有很多不穩定的地方。

　　下載版本

　　Taskcluster使得查找和下載最新版本進行測試變得很容易。研究人員在上面討論了由不同的儀表類型創建的變體的數量，研究人員需要對它們進行自動化模糊處理。由于構建、工件、體系結構、操作系統以及每個軟件包的大量組合，因此下載是一項艱巨的任務。

　　為了幫助降低構建管理的復雜性，研究人員開發了一個稱為fuzzfetch的工具。Fuzzfetch可以很容易地指定所需的構建參數，并將下載并解壓縮該構建。

　　如何生成測試用例

　　因為這篇博文的目的是解釋整個流程，因此研究人員不會花太多時間來解釋模糊測試，結合使用公共可用的和定制的模糊測試器來生成測試用例。

　　如何執行，報告和擴展

　　對于以瀏覽器為目標的模糊測試器， Grizzly管理和運行測試用例并監控結果，創建適配器可以使研究人員輕松地在Grizzly中運行現有的模糊測試器。Grizzly是一種應用程序框架，專門解決編寫成千上萬用戶訪問服務器時候產生的各種漏洞。

　　為了充分利用任何給定設備上的可用資源，研究人員并行運行多個Grizzly實例。

　　對于每個模糊測試器，研究人員都創建了容器來封裝運行它所需的配置。這些都存在于Orion monorepo中。　什么是 Monorepo?Monorepo 其實不是一個新的概念，在軟件工程領域，它已經有著十多年的歷史了。概念上很好理解，就是把多個項目放在一個倉庫里面，相對立的是傳統的 MultiRepo 模式，即每個項目對應一個單獨的倉庫來分散管理。每個模糊測試器都有一個配置，根據該模糊測試器的優先級來配置具體的部署和資源分配。Taskcluster持續部署這些配置以分配工作并管理模糊測試節點。

　　Grizzly Target處理諸如掛起、崩潰和其他漏洞等漏洞的檢測。Target是Grizzly和瀏覽器之間的接口。檢測到的漏洞會自動打包并上報給FuzzManager服務器。FuzzManager服務器提供了自動化和篩選結果的UI。

　　其他更有針對性的模糊測試器使用JS shell和基于libFuzzer的目標使用模糊接口。許多第三方庫在OSS-Fuzz中也被模糊化了，這些不在本文的討論范圍之內。

　　模糊測試結果

　　對不同的目標大規模運行多個模糊器會產生大量的數據，這些崩潰不適合直接輸入到漏洞跟蹤系統，比如Bugzilla。FuzzManager客戶端庫可以過濾崩潰變化和重復結果，然后再離開模糊測試節點。唯一結果將報告給FuzzManager服務器。通過FuzzManager的web界面，可以創建簽名，將報表分組到存儲桶中，幫助客戶端檢測重復的結果。

　　模糊測試器通常會生成長達數百甚至數千行的測試用例。FuzzManager存儲桶將自動進行掃描，以在Taskcluster中進行隊列減少任務。這些還原任務使用Grizzly Reduce和Lithium來應用不同的還原策略，通常會刪除大多數不必要的數據。每個存儲桶都將持續進行處理，直到成功完成還原操作為止。然后，工程師可以對最小化的測試用例進行最終檢查，并將其附加到漏洞報告中。最終結果通常用作Firefox測試套件中的崩潰測試。測試過程請點此查看。還定期測量模糊器的代碼覆蓋率，再次使用FuzzManager收集代碼覆蓋率數據并生成覆蓋率報告。

　　漏洞報告

　　由于研究人員的目標是創建可操作的漏洞報告，以盡快修復漏洞，同時最小化開發人員的開銷。

　　研究人員通過以下方式做到這一點：

　　崩潰信息，例如日志和堆棧跟蹤；

　　建設和環境信息；

　　減少測試用例；

　　Pernosco會話；

　　回歸范圍（通過Bugmon分割）；

　　通過Bugmon進行驗證；

　　Grizzly Replay是形成Bugmon和Grizzly Reduce的基本執行引擎的工具，它使收集rr痕跡提交到Pernosco變得容易。它使重新運行瀏覽器測試用例在自動化和手動使用方面都很容易。

　　如前所述，研究人員也一直在使用Pernosco。Pernosco是一個為rr跟蹤提供web界面的工具，使開發人員無需直接訪問執行環境就可以使用它們。這是一個由同名公司開發的工具，可以極大地幫助調試大規模并行應用程序。當測試用例太不可靠而無法減少或附加到漏洞報告時，它也非常有用。創建一個rr跟蹤并上傳它可以使不再使用的漏洞報告具有可操作性。

　　Grizzly和Pernosco的合并帶來了一個額外的好處，那就是使不常見的、難以重現的漏洞變得可行。一個非常不一致的漏洞的測試用例可以運行數百或數千次，直到在rr下發生所需的崩潰為止。跟蹤被自動收集并準備提交給Pernosco并由開發人員修復，而不是因為它不可操作而被忽略。

　　要對新特性進行適當的評估，可以通過fuzzing@mozilla.com或通過Matrix聯系。一旦開始對組件進行模糊測試，研究人員將主要通過Bugzilla進行通信。如前所述，研究人員努力解決可修復的漏洞。

　　Bugmon用于自動將回歸范圍平分為兩部分，并盡快通知適當的人員，并在將漏洞標記為“已修復”后進行驗證。關閉漏洞會自動將其從FuzzManager中刪除，因此，如果在代碼庫中找到類似的漏洞，則可以再次對其進行識別。

　　模糊測試期間發現的一些漏洞將阻止研究人員有效地模糊功能或構建變體，這些被稱為模糊阻止程序，它們以幾種不同的形式出現。從產品的角度來看，這些漏洞看起來似乎是無害的，但是它們可以阻止模糊測試程序針對重要的代碼路徑，甚至完全阻止模糊測試目標。適當地對這些漏洞進行優先級排序并快速將其修復是非常有用的。

　　PrefPicker管理用于模糊測試的Firefox首選項集。在首選項之后添加功能時，請考慮將其添加到PrefPicker模糊模板中，以便在模糊過程中啟用它。對PrefPicker模糊模板的定期審核可以幫助確保不遺漏區域，并盡可能有效地利用資源。

　　與其他領域一樣，衡量是評估成功的關鍵部分。研究人員利用Bugzilla的meta bug功能來幫助跟蹤由模糊器識別的漏洞。研究人員努力使每個模糊器和每個模糊的新組件都有一個meta bug。

　　例如，Domino的meta bug列出了該工具標識的所有漏洞（超過1100個）。使使用此Bugzilla數據，研究人員可以顯示多年來各種模糊測試的影響。

模糊測中有許多組件， 這些組件在不斷發展，以適應調試工具、執行環境和瀏覽器內部的變化。開發人員總是在添加、刪除和更新瀏覽器功能。