隨著物聯(lián)網(wǎng)設備的普及，嵌入式安全攻擊也隨之增加。從歷史上看，嵌入式系統(tǒng)工程師忽略了設備層的安全性，盡管嵌入式設備的許多領域都容易受到錯誤的影響。串行端口、無線電接口，甚至編程/調試接口都可能被黑客利用。模糊測試是工程師發(fā)現(xiàn)嵌入式設備弱點的重要場所，應考慮用于強化物聯(lián)網(wǎng)設備接口。

什么是模糊測試？

模糊測試就像神話中的百萬只猴子隨機打字寫莎士比亞。在實踐中，小說作品需要許多隨機組合來產(chǎn)生一個簡單的短語，但對于嵌入式系統(tǒng)，我們只需要從一個已知的好句子中更改幾個字母。

許多商業(yè)和開源工具可用于實施模糊攻擊。這些工具生成隨機字節(jié)串，也稱為模糊向量或攻擊向量，并將它們提交到正在測試的接口，跟蹤可能表示錯誤的結果行為。

模糊測試是一個數(shù)字游戲，但我們不能嘗試無限數(shù)量的可能輸入。相反，我們專注于通過最大化模糊向量提交率、模糊向量的有效性和錯誤檢測算法來優(yōu)化測試時間。

模糊測試概念

由于許多模糊測試工具都是為測試 PC 應用程序而設計的，因此如果您將嵌入式代碼作為本地編譯的 PC 應用程序運行，則更容易適應它們。在 PC 上運行嵌入式代碼會產(chǎn)生巨大的性能優(yōu)勢，但也有兩個缺點。首先，PC 微處理器的反應與嵌入式微控制器不同。其次，我們必須重新編寫任何涉及硬件的代碼。然而，在實踐中，在 PC 上運行的優(yōu)勢大于劣勢。真正的障礙是移植代碼以在 PC 上本地編譯的困難。

我們?nèi)绾沃滥：蛄亢螘r觸發(fā)錯誤？崩潰很容易發(fā)現(xiàn)，但很難識別導致重置的模糊向量。內(nèi)存溢出錯誤或雜散指針寫入（對黑客最有價值的錯誤類型）幾乎不可能從系統(tǒng)外部辨別出來，因為它們通常不會導致崩潰或重置。

許多現(xiàn)代編譯器，例如 GCC 和 Clang，都有一個稱為內(nèi)存清理的功能。這將內(nèi)存塊標記為干凈或臟，具體取決于它們是否正在使用，并標記任何訪問臟內(nèi)存的嘗試。但是，內(nèi)存清理會消耗閃存、RAM 和 CPU 周期，使其難以在嵌入式設備上運行。因此，相反，我們可以測試代碼子集，構建具有更多資源的設備版本，或者使用 PC。

測試的有效性可以通過執(zhí)行的代碼量來評估。在這里，編譯器也可以通過使用面包屑子例程調用來跟蹤內(nèi)存使用情況。代碼覆蓋率庫為每個代碼路徑維護一個使用值表，在面包屑執(zhí)行時遞增它們。

然而，對于嵌入式模糊測試來說，代碼覆蓋率數(shù)字很難解釋，因為大部分代碼對于模糊向量來說是不可訪問的；例如，獨立于接口運行的外圍設備的設備驅動程序。因此，很難為嵌入式系統(tǒng)定義“完整的代碼覆蓋率”——也許只有 20% 的嵌入式代碼是可訪問的。代碼覆蓋還消耗大量閃存、RAM 和 CPU 周期，并且需要專門的硬件或 PC 目標才能運行。

錯誤報告

當模糊測試發(fā)現(xiàn)導致不良行為的向量時，我們需要詳細信息。錯誤發(fā)生在哪里？調用堆棧的狀態(tài)是什么？錯誤的具體類型是什么？所有這些信息都有助于分類并最終修復錯誤。

錯誤分類在模糊測試中至關重要。新的 fuzz 項目經(jīng)常會發(fā)現(xiàn)很多 bug，我們需要一種自動的方法來確定它們的嚴重性。此外，模糊錯誤往往會阻止錯誤，因為它們通常會在代碼路徑中進一步掩蓋其他錯誤。我們需要快速解決模糊測試期間出現(xiàn)的問題。

嵌入式客戶端不像 PC 那樣愿意透露他們的信息。通常，崩潰只會導致設備重置并重新啟動。雖然這在現(xiàn)場是需要的，但它會擦除設備的狀態(tài)，從而難以了解是否發(fā)生了崩潰、發(fā)生的地點或原因，或者所采用的代碼路徑。工程師必須找到一致的再現(xiàn)向量，然后使用調試器跟蹤不良行為并找到錯誤。

在模糊測試中，一個測試可能會為幾個錯誤產(chǎn)生數(shù)千個崩潰向量，給人一種錯誤系統(tǒng)的錯誤印象。快速確定哪些向量與相同的潛在錯誤相關聯(lián)非常重要。對于嵌入式設備，崩潰本身的位置對于錯誤通常是唯一的，通常不需要找到完整的調用堆棧跟蹤。

連續(xù)模糊測試

由于模糊測試的隨機性，長時間運行它們會增加他們發(fā)現(xiàn)問題的機會。但是，任何項目計劃都不能吸收開發(fā)結束時冗長的模糊測試周期造成的延遲。

在實踐中，模糊測試將在發(fā)布過程之后在其自己的分支上開始。任何新發(fā)現(xiàn)的錯誤都將在本地分支中修復，以便測試可以繼續(xù)，而新錯誤不會阻止額外的錯誤發(fā)現(xiàn)。作為發(fā)布周期的一部分，從模糊測試先前版本中發(fā)現(xiàn)的錯誤將被評估以包含在新版本中。最后，應該將發(fā)現(xiàn)錯誤的模糊向量添加到正常的質量保證過程中，以驗證修復并確保這些錯誤不會無意中重新引入代碼中。

我們應該在不同場景下對設備進行模糊測試；例如，如果聯(lián)網(wǎng)，設備對連接請求的響應會有所不同。在每個可能的場景上運行模糊測試是不切實際的，但我們可以為每個可能狀態(tài)的值包括模糊測試。例如，對每種不同的設備類型運行模糊測試，同時保持其他變量相同。然后為一個設備類型的另一個變量（例如網(wǎng)絡連接狀態(tài)）運行不同的值。

模糊測試架構

兩種突出的模糊測試架構是定向模糊測試，其中模糊向量由工程師在測試前指定，以及覆蓋引導模糊測試，其中模糊工具從一組初始測試向量開始，并根據(jù)數(shù)據(jù)包的滲透程度自動改變它們編碼。

此外，并非所有代碼都可以在 PC 上運行，并且為嵌入式應用程序開發(fā) PC 模擬器可能是不切實際的，具體取決于所測試的內(nèi)容。

以下是四種模糊測試架構的總結：

嵌入式硬件上的直接接口測試——在嵌入式設備上運行正常的生產(chǎn)映像，并通過接口注入模糊數(shù)據(jù)包

數(shù)據(jù)包（堆棧）注入測試——直接調用傳入的數(shù)據(jù)包例程，而無需通過無線運行接口

使用模擬器進行定向模糊測試——使用基于 PC 的模擬技術開發(fā)和測試嵌入式代碼

使用模擬器進行覆蓋引導的模糊測試（如下所示的 Libfuzz）

多個模糊測試器

在使用調試接口鎖定和安全啟動鎖定嵌入式設備后，我們需要考慮對設備接口進行模糊測試。用于保護 Web 服務器的許多相同工具和概念可以適用于嵌入式設備。

為工作使用正確的工具。Coverage-guided fuzzing 對于連續(xù)模糊測試是必要的，但如果您的代碼僅在嵌入式硬件上執(zhí)行，那么定向模糊器可能是提供一定程度的模糊測試覆蓋率的不錯選擇。

最后，您應該在盡可能多的場景中使用多個模糊測試器，因為每個測試器都會對設備進行略微不同的測試，從而最大限度地提高覆蓋率，從而提高嵌入式設備的安全性。

審核編輯：郭婷