汽車SOME/IP模糊測試的常規(guī)設計步驟

01

關于SOME/IP和Fuzzing

近年來，汽車行業(yè)對于連接車輛的更多數(shù)據(jù)通信的需求不斷增加。更高的數(shù)據(jù)交換量要求底層通信協(xié)議具備更高的帶寬，這對車輛中廣泛使用的現(xiàn)有通信協(xié)議如CAN、LIN、FlexRay等構成了挑戰(zhàn)。現(xiàn)有協(xié)議的限制使得需要采用新的通信協(xié)議來支持汽車行業(yè)的新趨勢，而汽車以太網則是其中有前途的解決方案之一。

SOME/IP是一種輕量級協(xié)議，用于簡化進程/設備間的通信，支持過程調用和事件通知。由于其簡單和高效的特點，SOME/IP被越來越多的汽車設備采用。隨著SOME/IP的出現(xiàn)，SOME/IP應用程序的漏洞檢測變得至關重要。

02

SOME/IP協(xié)議概述

汽車以太網上的眾多上層協(xié)議中，SOME/IP 是一種專門針對汽車的協(xié)議，通過 UDP 協(xié)議棧提供基于服務的通信，使不同車輛組件之間進行基于服務的通信成為可能，例如在信息娛樂系統(tǒng)和發(fā)動機控制單元之間的通信。SOME/IP 的關鍵特點之一是其高效地使用單播和組播通信。這使得在組件之間發(fā)送控制消息時，網絡不會被不必要的流量擁塞。除此之外，SOME/IP 協(xié)議還包括遠程過程調用（RPC）、服務發(fā)現(xiàn)（SD）、服務事件的發(fā)布/訂閱以及 UDP 消息的分段等功能 。這些功能是通過數(shù)據(jù)序列化實現(xiàn)的，其中 SOME/IP 消息頭被預置到消息的有效載荷前面。消息頭包含以下字段：

1.MessageID：標識應用層中的 RPC 調用或事件，其中包含 2 個子字段 ServiceID 和 MethodID；

2.Length：指示從 RequestID 到 SOME/IP 消息結尾的字節(jié)數(shù)；

3.RequestID：區(qū)分用于同一事件的并行使用的數(shù)據(jù)包，其中包含 2 個子字段 ClientID 和 SessionID；

4.Protocol Version：標識使用的 SOME/IP 頭部格式；

5.Interface Version ：使用的 SOME/IP 協(xié)議的主要版本

6.Message Type ：用于區(qū)分 SOME/IP 協(xié)議中的不同消息類型

7.Return Code ：指示請求是否已成功處理。

SOME/IP協(xié)議消息頭格式 圖1

03

? 灰盒模糊測試

在過去的十年中，模糊測試已經展示了在漏洞檢測方面的潛力，并被用于發(fā)現(xiàn)開源和閉源軟件中的數(shù)千個漏洞。此外，研究人員也提出了新的模糊測試技術來模糊不同的協(xié)議實現(xiàn)，如FTP或RTSP。然而，與常規(guī)以太網上運行的FTP或其他協(xié)議不同，汽車以太網上的SOME/IP和其他汽車以太網協(xié)議通常是簡單直接的。這是因為運行這些協(xié)議的設備的計算能力通常是有限的。一方面，協(xié)議設計的簡單性意味著模糊測試器不需要為協(xié)議維護狀態(tài)機模型，如AFLnet。另一方面，計算能力的限制意味著我們需要尋求在并行運行多個模糊測試器以提高模糊測試效率。

灰盒模糊測試是一種廣泛用于檢測真實世界程序漏洞的方法。近年來，像AFL、libFuzzer等灰盒模糊測試工具已經幫助發(fā)現(xiàn)了數(shù)千個漏洞?；液心：郎y試的基本思想是應用一些預定義的生成和變異策略來產生輸入，然后通過觀察受監(jiān)視的執(zhí)行過程中的安全問題來發(fā)現(xiàn)錯誤。

下面是一個典型的灰盒模糊測試工具的工作流程：

1. 定義輸入生成和變異策略：模糊測試工具應用一組預定義的輸入生成和變異策略來生成輸入，這些輸入會被提供給目標程序。這些策略可以包括翻轉、替換、添加/減去位、字節(jié)或塊，或者基于輸入結構生成輸入。

2. 目標程序的插裝：目標程序通常會插入特定的代碼段，以在模糊測試期間提供覆蓋反饋。這些反饋有助于根據(jù)特定文件輸入評估程序執(zhí)行。

3. 監(jiān)控執(zhí)行：模糊測試工具會監(jiān)控執(zhí)行過程，以確定是否觀察到任何安全違規(guī)。可以使用AddressSanitizer、MemorySanitizer等工具來幫助識別這些違規(guī)。例如內存使用后釋放、緩沖區(qū)溢出等安全違規(guī)通常表示實現(xiàn)缺陷，這可能會導致漏洞，如內存損壞、信息泄露等。

4. 發(fā)現(xiàn)漏洞：如果觸發(fā)了違規(guī)，相應的文件輸入將被用作漏洞的證明。

5. 增加覆蓋率：如果模糊測試工具發(fā)現(xiàn)當前輸入有助于增加覆蓋率，則會用于后續(xù)變異。

6. fork-exec模型：由于執(zhí)行會被重復多次且由模糊測試工具進行控制，因此可采用fork-exec模型來減少加載目標程序公共序言代碼段的開銷，并提高整體模糊測試性能。

灰盒模糊測試流程 圖2

04

如何有效Fuzzing SOME/IP

在現(xiàn)有的方法中，每個模糊測試器實例將管理和運行唯一的測試目標實例。然而，如果測試目標需要某些獨特的資源（例如端口，鎖定文件等）才能執(zhí)行，則測試目標只能在每個設備上運行一個實例。在SOME/IP中，服務器應用程序通常在每個設備上運行一個實例，這使得進行并行模糊測試變得具有挑戰(zhàn)性。

針對這些挑戰(zhàn)，我們介紹一個針對SOME/IP應用程序的灰盒模糊測試工具-Ori。Ori具有兩個關鍵創(chuàng)新點：附加模糊測試模式和結構變異。附加模糊測試模式使Ori能夠高效地測試服務器程序，而結構變異使Ori能夠有效地生成有效的SOME/IP數(shù)據(jù)包以到達目標程序的深層路徑。通過評估表明，Ori可以準確高效地檢測SOME/IP應用程序中的漏洞。

SOME/IP模糊測試的常規(guī)設計步驟

1. 選擇fuzz工具：根據(jù)需要，選擇一個適合的fuzz工具進行SOME/IP模糊測試，如AFL、libFuzzer或Ori等。

2. 選擇目標程序：選擇需要進行SOME/IP模糊測試的目標程序，確保其符合SOME/IP協(xié)議規(guī)范，并且能夠接受并處理來自模糊測試的數(shù)據(jù)包。

3. 準備seed文件：生成或準備一個符合SOME/IP協(xié)議規(guī)范的數(shù)據(jù)包作為初始化的樣本文件。

4. 配置fuzz工具參數(shù)：根據(jù)需要，配置fuzz工具的參數(shù)，如超時時間、內存限制、CPU核心數(shù)等。

5. 啟動模糊測試：將seed文件作為輸入文件，啟動fuzz工具進行模糊測試。fuzz工具將在seed文件的基礎上生成大量隨機變異的數(shù)據(jù)包，并將其發(fā)送到目標程序進行測試。

6. 分析測試結果：當模糊測試結束后，需要對測試結果進行分析，包括生成的數(shù)據(jù)包數(shù)量、覆蓋率、崩潰數(shù)等指標。通過分析測試結果，可以發(fā)現(xiàn)目標程序的漏洞，從而進行修復。

用Ori實現(xiàn)SOME/IP變異包方法

Ori是一種基于變異的覆蓋引導灰盒模糊測試的工具，它通過在目標程序中插入代碼來收集執(zhí)行反饋以幫助模糊測試。是否可借助Ori的兩個關鍵特性進行SOME/IP協(xié)議的變異包實現(xiàn)？

第一個特性是附加模式

當我們使用Ori進行fuzzing時，fuzzer會附加到被測試的進程上。換句話說，我們首先啟動被測試的進程，然后運行fuzzer與被測試的進程進行通信并執(zhí)行fuzzing。這與以前的fuzzer情況不同，以前的fuzzer負責啟動被測試的進程和管理被測試進程的生命周期。

整個過程可以分為兩個步驟：fuzzing設置步驟和多附加fuzzing步驟。

1）在fuzzing設置步驟中，儀表化的目標程序將在特定條件下分叉出一個fuzzing服務器。fuzzing服務器是從儀表化的原始進程分叉出來的，并將循環(huán)等待傳入的fuzzing請求。

2）成功設置后，我們可以運行一個或多個前端fuzzer。前端fuzzer將與fuzzing服務器通信，并發(fā)送附加請求。一旦fuzzing服務器接收到請求，它將分叉出一個fuzzing目標進程，該進程與前端fuzzer一起執(zhí)行所有剩余的fuzzing流程。

總的來說，附加模式消除了加載特定SOME/IP實現(xiàn)的前導代碼段的多余執(zhí)行。通過這個特性，Ori通過專注于實際協(xié)議邏輯來提高整體性能，并提供了調用多個fuzzing實例進行并行fuzzing的能力。

第二個特性是Ori支持種子輸入的兩個變異級別

SOME/IP協(xié)議的數(shù)據(jù)包包含兩個部分：正文和頭部。相應地，Ori使用不同的變異算子來處理不同的部分。通過變異數(shù)據(jù)包的正文部分，Ori可以測試SOME/IP服務器的核心邏輯。通過變異數(shù)據(jù)包的頭部部分，Ori可以測試SOME/IP協(xié)議的實現(xiàn)。

對于數(shù)據(jù)包的正文部分，Ori使用類似于AFL的樸素隨機變異算子，如位/字節(jié)翻轉、替換/添加/刪除隨機塊等。對于數(shù)據(jù)包的頭部部分，Ori首先識別頭部的不同字段，然后根據(jù)字段的類型應用變異。值得注意的是，Ori不會變異ServiceID、ClientID、Protocol Version和Interface Version字段。這是因為變異這些字段不會有助于覆蓋測試目標的關鍵邏輯。例如，如果突變數(shù)據(jù)包的ServiceID字段，并且無法匹配測試目標提供的服務，則數(shù)據(jù)包將立即被拒絕，測試目標的更深層邏輯將不會被執(zhí)行。了解此特點之后，Ori可以生成可以到達目標程序的深層邏輯的數(shù)據(jù)包，并且可以同時測試協(xié)議框架和應用程序。

Ori的架構圖3

05

Fuzzing SOME/IP的流程設計

Ori包括一個前端fuzzer和后端目標，兩者之間詳細的fuzz流程如圖4所示，其中包含兩個階段：準備階段和測試階段。

1）準備階段

在進行SOME/IP模糊測試之前，我們需要進行準備階段，以確保測試目標的可用性和測試環(huán)境的穩(wěn)定性。以下是詳細的步驟：

1. 啟動目標服務器程序并進入forkserver狀態(tài)：首先，我們需要啟動目標服務器程序，并將其設置為forkserver模式。這樣，目標程序可以與fuzzer進行通信，并接收來自fuzzer的測試數(shù)據(jù)。

2. 啟動fuzzer：接下來，我們需要啟動fuzzer，以準備開始模糊測試。在啟動fuzzer之前，我們需要設置fuzzing環(huán)境，如共享內存、輸出目錄等。

3. 檢查目標程序的forkserver狀態(tài)：fuzzer將嘗試聯(lián)系目標程序，以檢查其是否已準備好與fuzzer通信。如果目標程序已經處于forkserver狀態(tài)，則它將通知fuzzer，并準備接收來自fuzzer的測試數(shù)據(jù)。

4. 啟動主fuzzing循環(huán)：如果目標程序已準備好與fuzzer通信，則fuzzer將啟動主fuzzing循環(huán)。在主循環(huán)中，fuzzer將生成大量隨機變異的數(shù)據(jù)包，并將其發(fā)送到目標程序進行測試。如果目標程序崩潰或產生其他異常行為，則表明存在漏洞，需要進行修復。

5. 結束fuzzing：當fuzzing循環(huán)結束時，fuzzer將生成測試報告，包括生成的數(shù)據(jù)包數(shù)量、覆蓋率、崩潰數(shù)等指標。通過分析測試結果，我們可以發(fā)現(xiàn)目標程序的漏洞，并進行修復。

2）測試階段

Fuzzer將生成數(shù)據(jù)包來測試目標服務器并處理測試結果。首先，fuzzer將向forkserver發(fā)送一個請求，要求它fork一個新實例進行測試。這個測試實例從forkserver邏輯被插入的點開始執(zhí)行，因此測試實例可以跳過與測試無關的邏輯執(zhí)行。測試實例開始執(zhí)行后，它會通知fuzzer繼續(xù)執(zhí)行。然后，fuzzer將使用結構變異生成一個新的SOME/IP數(shù)據(jù)包，并將其發(fā)送到測試實例。變異的數(shù)據(jù)包頭部有助于測試數(shù)據(jù)包解析組件，而變異的數(shù)據(jù)包主體有助于測試服務器的業(yè)務邏輯。在測試實例執(zhí)行完成后，forkserver將收集其退出狀態(tài)和執(zhí)行覆蓋信息，并將收集到的數(shù)據(jù)向fuzzer報告。

在處理測試結果時，Ori與其他基于覆蓋率的灰盒fuzzer類似。如果數(shù)據(jù)包導致測試實例崩潰，fuzzer將保留它以供將來分析。如果數(shù)據(jù)包可以增加代碼覆蓋率，fuzzer將保留它作為生成新測試用例的種子。這標志著一輪測試的結束。如果用戶不停止fuzzer或目標服務器，則整個過程將繼續(xù)進行下一輪測試。

Ori詳細fuzz流程 圖4

06

Fuzzing SOME/IP的具體實現(xiàn)與評估結果

1. 實現(xiàn)邏輯

Ori是一個工具，由兩個主要組件組成：代碼儀器和模糊器。代碼儀器構建在AFL的LLVM模式之上，使用定制的LLVM傳遞對目標程序進行儀器化。盡管儀器化繼承了afl-clang-fast的邏輯來收集代碼覆蓋信息，但其forkserver注入部分被修改以適應模糊的額外模式邏輯。這個修改涉及約200行C++代碼。Ori的模糊器使用約400行Python代碼實現(xiàn)，并依賴于Scapy庫來執(zhí)行結構變異。

2. 驗證評估

1）評估目標

目前，唯一的開源SOME/IP協(xié)議框架是GENIVI/vsomeip 。

> GENIVI/vsomeip是一個基于C++語言的開源SOME/IP協(xié)議實現(xiàn)框架，主要用于汽車電子領域的通信。SOME/IP是一種輕量級的通信協(xié)議，可以在汽車電子中實現(xiàn)多種通信方式，如消息傳遞、遠程過程調用和發(fā)布/訂閱等。該框架實現(xiàn)了SOME/IP協(xié)議的所有特性，包括服務注冊、發(fā)現(xiàn)、發(fā)布、訂閱和取消訂閱等。它提供了一個高度可擴展和易于使用的API，可幫助開發(fā)人員輕松實現(xiàn)復雜的汽車電子應用程序。GENIVI/vsomeip框架還包括一組工具，如vsomeip-sd、vsomeip-jsonconfig和vsomeip-log等，用于簡化SOME/IP應用程序的開發(fā)和測試。此外，GENIVI/vsomeip框架也可以與其他GENIVI項目進行集成，如DBus和CommonAPI等。

因此，以下描述的測試目標基于GENIVI/vsomeip示例程序的修改版本，所有當前的實驗都基于該程序。該程序是一個SOME/IP服務器，接受客戶端的消息并發(fā)送回"Hello "加上消息內容作為反饋。我們在示例程序中添加了一個崩潰點，以便如果客戶端發(fā)送以小寫字母'a'開頭的消息，程序將崩潰。示例程序的修改如圖5所示，代碼行6-14。

GENIVI/vsomeip修改程序示例 圖5

2）可附加模式模糊測試

附加模式模糊測試允許多個模糊器實例并行模糊測試，而不會受到端口占用的限制。此外，Ori在初始化主要上下文后插入forkserver邏輯，從而允許測試實例跳過服務器設置過程，顯著提高了測試速度。實驗結果表明，Ori比現(xiàn)有工具具有更快的執(zhí)行速度，每個測試用例只需要1-2秒，而沒有延遲forkserver插入的AFL至少需要4秒。這些結果表明，Ori是一個高效、靈活和可擴展的模糊測試工具。

Ori相比于現(xiàn)有的工具，具有更快的執(zhí)行速度和更高的有效性。結構變異的應用使得Ori可以在復雜的協(xié)議中生成正確的有效載荷和報頭，并顯著提高了Ori的有效性。Ori是一個非常有用的工具，可以在軟件開發(fā)中提高測試的效率和質量。

3）結構變異有效性高

結構變異可以幫助Ori在生成復雜數(shù)據(jù)包頭時，提高其有效性，使其可以測試目標服務器。通過比較，我們可以看出AFL幾乎無法生成像SOME/IP數(shù)據(jù)包頭這樣復雜的結構，因此即使它可以生成正確的有效載荷，也無法成功將數(shù)據(jù)包傳遞到測試目標，這限制了AFL在這種場景下的有效性。而Ori使用結構變異的方法可以生成符合SOME/IP協(xié)議要求的數(shù)據(jù)包頭，提高了其有效性和可用性。

這種實驗結果可以啟示我們，在實際應用中，如果需要對復雜的數(shù)據(jù)結構進行測試，可以考慮使用結構變異的方法來生成測試用例，以提高測試的有效性。此外，結構變異的應用范圍不僅限于模糊測試，還可以用于其他領域，例如軟件漏洞挖掘和惡意軟件分析等。因此，結構變異作為一種有效的技術手段，可以在軟件測試和安全領域中發(fā)揮重要作用。

木衛(wèi)四威脅分析平臺S3一直在不斷探索智能汽車協(xié)議異常檢測的方法，通過不斷迭代和擴展S3的智能分析能力，實現(xiàn)更加精準的檢測。其中，通過Fuzzing技術可以有效發(fā)現(xiàn)協(xié)議實現(xiàn)中未知的異常行為。以SOME/IP協(xié)議為例，S3可以通過Fuzzing來探索協(xié)議的特征結構，例如SOME/IP數(shù)據(jù)包頭、有效負載等，從而更好地理解協(xié)議的行為和發(fā)現(xiàn)潛在的漏洞。通過不斷改進和優(yōu)化Fuzzing技術，S3可以在協(xié)議異常檢測方面實現(xiàn)更加準確和高效的表現(xiàn)。

參考文獻

1. A Greybox Fuzzer for SOME/IP Protocols in Automotive Ethernet：

[https://ieeexplore.ieee.org/abstract/document/9359273/]

2.Genevivsome/ip.[Online].Available: [https://github.com/]GENIVI/vsomeip

3. SOME/IP Protocol Specification, [https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_PRS_SOMEIPProtocol.pdf]11/AUTOSAR_PRS_SOMEIPProtocol.pdf), AUTOSAR Std.,Rev. R19-11, Nov. 2019.

4.LLVM,“l(fā)ibFuzzer,”2015.[Online].Available: [https://llvm.org/docs/LibFuzzer.html]

編輯：黃飛

?