張 弛, 司徒凌云, 王林章

1計(jì)算機(jī)軟件新技術(shù)國家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué)) 南京 中國 210023

2南京大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)系 南京 中國 210023

1 引言

物聯(lián)網(wǎng)(Internet of Things, IoT)是由各種擁有唯一標(biāo)識的計(jì)算設(shè)備、機(jī)械或數(shù)字對象、人與物通過通信技術(shù)建立連接, 實(shí)現(xiàn)自主的人、機(jī)、物之間的數(shù)據(jù)傳輸與信息交換的系統(tǒng)[1]。隨著設(shè)備硬件的發(fā)展與以5G[2]、NB-IoT[3]為代表的通信技術(shù)的進(jìn)步, 眾多物聯(lián)網(wǎng)設(shè)備如移動(dòng)終端、路由器、交換機(jī)、網(wǎng)絡(luò)監(jiān)控?cái)z像頭、智能家電、智能汽車、智能門鎖、智能電表等被接入到網(wǎng)絡(luò)空間, 廣泛部署、應(yīng)用在智能交 通、智能醫(yī)療、智能電網(wǎng)等安全攸關(guān)的領(lǐng)域。根據(jù)GSMA預(yù)計(jì), 到2025年, 全球物聯(lián)網(wǎng)設(shè)備數(shù)目將高達(dá)25.3億[4]。

固件(firmware)是運(yùn)行在物聯(lián)網(wǎng)設(shè)備上的核心軟件之一。IEEE標(biāo)準(zhǔn)12207-2008將固件定義為“硬件設(shè)備和以只讀軟件形式存儲(chǔ)于硬件設(shè)備中的計(jì)算機(jī)指令和數(shù)據(jù)的結(jié)合”[5]。大部分嵌入式設(shè)備中的軟件都是以二進(jìn)制形式存儲(chǔ)在只讀存儲(chǔ)器、可編程只讀存儲(chǔ)器、可擦可編程只讀存儲(chǔ)器、帶電可擦可編程只讀存儲(chǔ)器、閃存等永久存儲(chǔ)設(shè)備中, 因此該類軟件一般稱為固件。

固件按照其是否內(nèi)置操作系統(tǒng)、以及內(nèi)置操作系統(tǒng)的類型可分如表1所示的三類: (1)單片固件, 通常采取單個(gè)二進(jìn)制鏡像的形式, 無需底層操作系統(tǒng), 直接基于底層硬件驅(qū)動(dòng)完成所有功能, 或者只包含部分系統(tǒng)的庫; (2)基于Linux的固件, 以Linux作為底層的系統(tǒng), 基于Linux進(jìn)行開發(fā); (3)基于RTOS的固件。RTOS(real-time operating system)是指實(shí)時(shí)處理數(shù)據(jù)、沒有緩沖延遲的操作系統(tǒng)[6]。在嵌入式應(yīng)用中使用RTOS可以使程序最大化利用有限的計(jì)算資源、簡化應(yīng)用程序設(shè)計(jì)、提高開發(fā)人員效率。RTOS受到了越來越多編程人員的重視, 涌現(xiàn)出一批優(yōu)秀的嵌入式實(shí)時(shí)操作系統(tǒng)如 VxWorks[7]、QNX[8]、FreeRTOS[9]、RTEMS[10]等, 其中FreeRTOS因其開源免費(fèi)、小巧簡單等特點(diǎn)受到了學(xué)術(shù)界和產(chǎn)業(yè)界的廣泛采用。

固件是設(shè)備上電后最先執(zhí)行的代碼, 主要負(fù)責(zé)系統(tǒng)硬件的初始化、加載操作系統(tǒng)、獲取最終控制權(quán)、并為上層軟件有效使用硬件設(shè)備提供調(diào)用接口。早期的計(jì)算機(jī)上的固件叫作基本輸入輸出系統(tǒng)(Basic Input Output System, BIOS), 由于其開發(fā)效率低, 功能擴(kuò)展性差以及更新機(jī)制不完善等缺點(diǎn), 已經(jīng)逐漸被支持圖形界面和鼠標(biāo)操作的統(tǒng)一可擴(kuò)展固件接口 (Unified Extensible Firmware Interface, UEFI)所取代。嵌入式設(shè)備由于存儲(chǔ)空間小, 實(shí)現(xiàn)功能與計(jì)算機(jī)相比較更為單一, 因此嵌入式設(shè)備上的固件通常是指嵌入式設(shè)備中的整個(gè)軟件系統(tǒng), 即包含操作系統(tǒng)、第三方庫、應(yīng)用程序等。上電之后固件負(fù)責(zé)硬件平臺(tái)的初始化和之后的嵌入式設(shè)備的功能實(shí)現(xiàn)。

固件中存在缺陷是造成物聯(lián)網(wǎng)設(shè)備遭受安全攻擊的根本原因之一。一方面, 固件主要由C語言實(shí)現(xiàn), 盡管C語言為程序員提供了多種機(jī)制和API(應(yīng)用程序接口)確保安全, 但也需要程序員做出關(guān)鍵決定, 如輸入合法性檢查、越界檢查等等。程序員對代碼安全性認(rèn)識不足導(dǎo)致編程實(shí)踐中存在疏忽、失誤以致程序的關(guān)鍵部分存在缺陷, 在連接互聯(lián)網(wǎng)運(yùn)行的場景下, 這樣的缺陷成為安全漏洞, 容易被黑客利用并攻擊; 另一方面, 固件的執(zhí)行權(quán)限高于操作系統(tǒng), 能實(shí)現(xiàn)對所有硬件設(shè)備的直接控制, 同時(shí)也是操作系統(tǒng)安全機(jī)制的盲區(qū)所在, 始于固件的攻擊能夠直接或間接地影響上層操作系統(tǒng)或應(yīng)用軟件的安全機(jī)制。另外, 越來越多的由早期版本固件驅(qū)動(dòng)的嵌入式設(shè)備也接入物聯(lián)網(wǎng), 早期固件缺乏對聯(lián)網(wǎng)環(huán)境下的安全考慮, 帶來了安全威脅。

基于固件缺陷的安全攻擊事故頻發(fā)。典型的, 2018年, 思科Talos安全研究團(tuán)隊(duì)發(fā)現(xiàn)攻擊者利用惡意程序VPNFilter感染了全球54個(gè)國家的超過50萬臺(tái)路由器[11]; 2016年, 攻擊者利用物聯(lián)網(wǎng)設(shè)備對美國域名服務(wù)器管理服務(wù)供應(yīng)商Dyn發(fā)起分布式拒絕服務(wù)(DDoS)攻擊, 制造了有史以來規(guī)模最大的DDoS攻擊[12]。

有效的固件缺陷檢測是保障物聯(lián)網(wǎng)設(shè)備安全的關(guān)鍵。在聯(lián)網(wǎng)環(huán)境下, 日益增長的嵌入式設(shè)備數(shù)目, 日益復(fù)雜的固件系統(tǒng)規(guī)模, 以及嵌入式設(shè)備低功耗環(huán)境下保護(hù)機(jī)制的缺失, 使得固件安全問題日益凸顯, 檢測固件中的缺陷成為了近年來的研究熱點(diǎn)。

表1 固件分類及其特點(diǎn) Table 1 Firmware Classification and its Characteristics

固件處于計(jì)算系統(tǒng)的核心地位, 自身的安全缺陷往往隱藏較深, 需要滿足特定的條件才能被觸發(fā), 加之, 物聯(lián)網(wǎng)設(shè)備具有多樣、異構(gòu)等特性, 這使得檢測固件缺陷變得極其困難?，F(xiàn)有的缺陷檢測技術(shù)主要包括靜態(tài)分析[40-44]、符號執(zhí)行[49-53]、模糊測試[28,56-58,63-71]、程序驗(yàn)證[29,75-76]以及機(jī)器學(xué)習(xí)[79-88], 然而現(xiàn)階段基于上述技術(shù)的缺陷檢測方法與工具在

應(yīng)用到物聯(lián)網(wǎng)固件時(shí)依舊面臨挑戰(zhàn):

(1) 無法獲取源碼且代碼類型復(fù)雜。廠商為了保證設(shè)備安全通常不會(huì)公開固件源碼; 且為了完成設(shè)備的各項(xiàng)功能, 固件通?；祀s有匯編、Java、JavaScript等不同類型代碼, 阻礙了反編譯的進(jìn)行;

(2) 不同類型的固件差別較大。現(xiàn)有的固件根據(jù)所使用的系統(tǒng)可以分為單片固件、基于Linux的固件和基于RTOS的固件, 不同類型固件代碼架構(gòu)差異較大; 且運(yùn)行在不同硬件上的固件處理器架構(gòu)和內(nèi)存架構(gòu)差異較大, 極大阻礙了固件測試工具的可擴(kuò)展性;

(3) 測試用例難以構(gòu)建。固件由于其功能嚴(yán)重依賴外部輸入和中斷, 外設(shè)類型極其豐富及內(nèi)部狀態(tài)復(fù)雜, 因此難以構(gòu)造統(tǒng)一的輸入來滿足眾多外設(shè), 也難以構(gòu)造極端的測試場景去探索更深的路徑。

(4) 依賴資源及技術(shù)不足。固件運(yùn)行的硬件資源有限, 因此較難在物聯(lián)網(wǎng)設(shè)備中直接運(yùn)行測試軟件; 且物聯(lián)網(wǎng)設(shè)備通常很少向第三方提供完備的測試接口, 無法獲取足夠的固件運(yùn)行時(shí)信息; 固件的反匯編技術(shù)仍然存在不足, 當(dāng)固件中存在混淆機(jī)制時(shí)難以獲取源碼; 模擬器能力有限導(dǎo)致大量固件無法進(jìn)行模糊測試。

本文總結(jié)了典型的固件安全缺陷類型; 分析了各類固件缺陷的機(jī)理; 綜述了現(xiàn)有固件安全缺陷檢測技術(shù)與工具, 分析了其優(yōu)勢與不足, 為進(jìn)一步的固件缺陷檢測技術(shù)研究提供了指導(dǎo)。

文章其余部分結(jié)構(gòu)如下: 第二節(jié)介紹典型的固件缺陷類型以及產(chǎn)生機(jī)理, 包括內(nèi)存損壞、命令注入、程序邏輯缺陷、并發(fā)問題等實(shí)現(xiàn)缺陷, 配置缺陷以及定制缺陷; 第三節(jié)從靜態(tài)分析、符號執(zhí)行、模糊測試、程序驗(yàn)證和基于機(jī)器學(xué)習(xí)五個(gè)技術(shù)角度對現(xiàn)有固件缺陷檢測方法進(jìn)行了分析與比較; 然后, 討論了未來的研究方向; 最后, 總結(jié)全文。

2 固件缺陷及其機(jī)理分析

Zhao等人[13]和Jing等人[14]在研究中將物聯(lián)網(wǎng)安全分為了圖1所示的應(yīng)用層、網(wǎng)絡(luò)層和感知層三層架構(gòu), 對每一層可能出現(xiàn)的問題和受到的攻擊進(jìn)行了綜述。由于不同物聯(lián)網(wǎng)系統(tǒng)的設(shè)計(jì)不同, 這三個(gè)部分所在的位置也不同, 在功能簡單的物聯(lián)網(wǎng)設(shè)備中, 感知層、應(yīng)用層和網(wǎng)絡(luò)層可能都位于物聯(lián)網(wǎng)設(shè)備的固件中; 在成體系的大型物聯(lián)網(wǎng)系統(tǒng)中, 物聯(lián)網(wǎng)設(shè)備的固件中可能僅保留感知層和網(wǎng)絡(luò)層的部分實(shí)現(xiàn)。

本文針對物聯(lián)網(wǎng)設(shè)備的固件中存在的缺陷進(jìn)行了研究。通常, 錯(cuò)誤指代碼中對編程語言規(guī)范的違反; 缺陷指固件設(shè)計(jì)與代碼實(shí)現(xiàn)上的不足; 漏洞指可以被攻擊人員利用的缺陷。本文將使用缺陷來指代固件代碼實(shí)現(xiàn)和設(shè)計(jì)上的不足, 以及可被攻擊者利用的漏洞。固件中的缺陷可以分為三個(gè)大類, 分別為實(shí)現(xiàn)缺陷、配置缺陷和定制缺陷。

圖1 物聯(lián)網(wǎng)安全架構(gòu) Figure 1 IoT Security architecture

圖2 三種缺陷之間的關(guān)系 Figure 2 Relationship between three types of defects

實(shí)現(xiàn)缺陷指開發(fā)人員在開發(fā)過程中引入的源碼上的不足, 實(shí)現(xiàn)缺陷由程序開發(fā)人員造成; 配置缺陷指部署人員在部署過程中編寫配置文件時(shí)引入的缺陷, 配置缺陷由程序部署人員造成; 定制缺陷指用戶為使固件滿足特定需求或者環(huán)境而對固件進(jìn)行了某些修改, 這一過程中引入的缺陷, 定制缺陷由程序使用人員造成。其中, 實(shí)現(xiàn)缺陷又包含內(nèi)存損壞缺陷、命令注入缺陷、程序邏輯缺陷、并發(fā)問題缺陷, 配置缺陷包含功能配置參數(shù)缺陷、性能配置參數(shù)缺陷、權(quán)限配置參數(shù)缺陷。本章將對這幾類缺陷的機(jī)理進(jìn)行分析。

2.1 實(shí)現(xiàn)缺陷

2.1.1 內(nèi)存損壞類缺陷

內(nèi)存損壞類缺陷指不正確的內(nèi)存訪問導(dǎo)致堆、棧內(nèi)存發(fā)生錯(cuò)誤[15]。大部分固件程序本質(zhì)上來說就是用C語言寫成的程序, 只不過底層部分會(huì)需要一些匯編指令和硬件直接交互, 因此固件中的內(nèi)存損壞類缺陷同普通桌面軟件中的內(nèi)存損壞類缺陷沒有區(qū)別, 而這些缺陷也同樣有可能導(dǎo)致被攻擊者利用 的漏洞。具體來說可以有以下幾類: 1)堆溢出漏洞; 2)棧溢出漏洞; 3)內(nèi)存泄漏漏洞; 4)數(shù)組越界讀寫漏洞; 5)use-after-free漏洞; 6)double-free漏洞; 7)空指針解引用; 8)格式字符串漏洞。

內(nèi)存損壞缺陷在缺陷檢測中較為常見, 固件中的內(nèi)存損壞缺陷可能會(huì)引起固件程序掛起、崩潰、重啟、敏感信息泄露、拒絕服務(wù)攻擊、緩沖區(qū)溢出攻擊等行為, 而且內(nèi)存相關(guān)缺陷大多由于外部輸入引起, 攻擊者可以通過構(gòu)造特定的輸入來觸發(fā)漏洞以達(dá)到特定目的。

例如, 在ASUS路由器中的棧溢出漏洞會(huì)造成遠(yuǎn)程代碼執(zhí)行(CVE-2017-12754)[16]; FreeRTOS的函數(shù)棧中由于不正確的錯(cuò)誤處理邏輯導(dǎo)致了double free(CVE-2018-16528)和 uninitialized pointer free (CVE-2018-16522)[17]; Netgear的無線驅(qū)動(dòng)中包含有一個(gè)堆溢出漏洞(CVE-2006-6125), 攻擊者可以通過構(gòu)造一個(gè)特定的802.11管理片段來觸發(fā)這個(gè)漏洞[18]。

2.1.2 命令注入缺陷

命令注入缺陷指由于缺少對用戶輸入進(jìn)行完備的檢查導(dǎo)致惡意用戶可以通過構(gòu)造輸入來運(yùn)行非預(yù)期的命令[19], 與普通桌面軟件相比, 固件直接操作硬件, 擁有更高的權(quán)限, 因此命令注入缺陷的危害也更大。包含系統(tǒng)的固件大都支持運(yùn)行命令行, 但這也給固件留下了安全隱患, 當(dāng)固件沒有對用戶輸入的命令行指令進(jìn)行檢查時(shí), 攻擊者將可以構(gòu)造特定的指令來完成某些動(dòng)作, 達(dá)到自己的目的, 如攻擊者可以使用查詢來查看嵌入式設(shè)備上的數(shù)據(jù)庫或者獲取嵌入式設(shè)備中的文件, 以造成敏感信息泄露; 可以使用刪除指令來刪除設(shè)備上的重要信息, 使系統(tǒng)無法繼續(xù)運(yùn)行。

例如, 在D-Link設(shè)備DIR-823G中存在一個(gè)命令注入缺陷(CVE-2019-7298), 當(dāng)攻擊者發(fā)送一個(gè)定制的HNAP1請求時(shí)可以觸發(fā)這一缺陷[20], 缺陷的觸發(fā)形成漏洞, 使攻擊者可以運(yùn)行任意的系統(tǒng)命令; D-Link DCS網(wǎng)絡(luò)攝像機(jī)中沒有對IP地址進(jìn)行檢查, 可以通過/common/info.cgi獲取網(wǎng)絡(luò)攝像機(jī)的配置文件, 無需任何驗(yàn)證就可讀取其中的敏感信息(CVE-2018-18441)[21]。

2.1.3 程序邏輯缺陷

程序邏輯缺陷是指程序不嚴(yán)謹(jǐn)?shù)倪壿嬎粝碌娜毕? 使軟件無法正常運(yùn)行或給了不法分子可乘之機(jī)[22]。如系統(tǒng)權(quán)限等級設(shè)計(jì)不嚴(yán)謹(jǐn), 就會(huì)使系統(tǒng)的底層置于危險(xiǎn)之中; 系統(tǒng)或者傳輸過程中沒有加密或者加密算法過于簡單, 就會(huì)使系統(tǒng)有被破解的風(fēng)險(xiǎn); 在代碼中硬編碼賬號、密碼等信息, 使系統(tǒng)容易被不法分子侵入, 且大部分廠商為了方便用戶使用, 通常會(huì)為設(shè)備設(shè)置相同的出廠用戶名和密碼, 如果用戶未對其進(jìn)行修改, 則會(huì)有遭遇攻擊的風(fēng)險(xiǎn); 防御措施不完善就容易遭受各種攻擊如拒絕服務(wù)攻擊等。

例如, Hikvision的大量設(shè)備在配置文件中硬編碼了某些密碼, 這使得不法分子可以通過這些密碼來獲取一定的權(quán)限[23]; Netgear FVG318在TCP通信中使用了錯(cuò)誤的校驗(yàn)和, 使設(shè)備容易受到拒絕服務(wù)攻擊(CVE-2006-4143)[24]; NETGEAR WGT624無線路由器設(shè)備中在配置文件中使用明文記錄了敏感信息, 使攻擊者可以獲取密碼并取得權(quán)限[25]。

2.1.4 并發(fā)問題缺陷

并發(fā)問題缺陷指對多線程運(yùn)行的固件設(shè)計(jì)不合理導(dǎo)致固件運(yùn)行時(shí)產(chǎn)生數(shù)據(jù)競爭、死鎖等行為[26]。隨著硬件的發(fā)展, 嵌入式設(shè)備不僅僅局限于單個(gè)任務(wù)的運(yùn)行, 通常會(huì)被設(shè)計(jì)多個(gè)任務(wù)同時(shí)運(yùn)行, 便會(huì)產(chǎn)生并發(fā)問題缺陷, 而這種缺陷無論是工程人員自己編寫的調(diào)度系統(tǒng)還是使用現(xiàn)成的RTOS進(jìn)行調(diào)度都有可能發(fā)生。為嵌入式軟件提供多任務(wù)調(diào)度是RTOS最基本的功能, 通過RTOS提供的API可以將函數(shù)程序分成獨(dú)立的任務(wù), 并為他們提供了多種調(diào)度方式, 此外還提供了任務(wù)中斷、任務(wù)間通信等功能。RTOS提供的多任務(wù)調(diào)度簡單易懂, 但使用不當(dāng)也會(huì)造成許多問題, 例如死鎖、數(shù)據(jù)競爭等[27]。許多學(xué)者對RTOS上的任務(wù)調(diào)度可能產(chǎn)生的問題進(jìn)行了研究, 提出了檢測和預(yù)防的方法[28-29]。

2.2 配置缺陷

在大型軟件領(lǐng)域常見的配置錯(cuò)誤在固件中也經(jīng)常發(fā)生, 隨著開發(fā)人員對代碼的可移植性和可重用性的追求, 產(chǎn)生了大量的配置文件來適配不同的硬件、架構(gòu)和系統(tǒng), 使得廠商在不同平臺(tái)上的代碼無需進(jìn)行太多修改。廣泛使用的FreeRTOS便是可移植的一個(gè)案例, FreeRTOS作為一個(gè)可移植、可配置的輕量級操作系統(tǒng), 在提供了大量便利的同時(shí)也帶來了許多問題, 尤其是其配置問題。

具體的, FreeRTOS支持35種微處理架構(gòu), 但針對于每一種架構(gòu)都需要對FreeRTOS進(jìn)行一系列的配置。用戶在使用FreeRTOS時(shí)也需要根據(jù)自己的應(yīng)用來進(jìn)行相應(yīng)的配置以符合自己的要求。AWS為FreeRTOS編寫了許多例如TCP/IP、UDP、IO等函數(shù)棧, 這些函數(shù)棧的使用需要用戶根據(jù)需要進(jìn)行配置; 開發(fā)人員在進(jìn)行開發(fā)時(shí)通常會(huì)復(fù)制他人的配置文件并自己根據(jù)需要做一些修改, 但相當(dāng)一部分開發(fā)人員在進(jìn)行配置時(shí)并沒有很好的理解這些配置的真正含義, 往往一個(gè)不起眼的不當(dāng)配置就可能引起 致命的缺陷, 這些缺陷有可能會(huì)造成系統(tǒng)崩潰、掛起或者其他無法預(yù)知的故障。

典型的, 安全公司辛培力安(Zimperium)對FreeRTOS系統(tǒng)及其TCP/IP相關(guān)的函數(shù)棧進(jìn)行分析, 發(fā)現(xiàn)了大量同配置相關(guān)的缺陷, 并獲得了CVE編號如CVE-2018-16528等[17], 這些缺陷可能會(huì)造成信息泄露、遠(yuǎn)程代碼執(zhí)行。

配置缺陷可以分為功能配置參數(shù)缺陷、性能配置參數(shù)缺陷、權(quán)限配置參數(shù)缺陷。固件上的配置缺陷目前學(xué)術(shù)界研究缺失, 但大型軟件系統(tǒng)和云系統(tǒng)中都有較多研究, 這些研究對固件配置缺陷檢測或許會(huì)有啟發(fā)。

2.2.1 功能配置參數(shù)缺陷

功能配置參數(shù)缺陷指的是由于部署人員的粗心或?qū)ε渲庙?xiàng)的不了解而產(chǎn)生的諸如配置值不當(dāng)、類型不匹配、配置項(xiàng)缺失等問題[30]。

配置值不當(dāng)包括不正確的文件路徑、配置值錯(cuò)誤的拼寫等。D-Link DIR-822設(shè)備中的配置文件中有多個(gè)錯(cuò)誤的配置且缺乏安全檢查(CVE-2018- 19990)[31], 這些錯(cuò)誤可能會(huì)影響設(shè)備的內(nèi)存管理; 類型不匹配指錯(cuò)誤的配置值類型, 如給int型的配置項(xiàng)設(shè)置了一個(gè)字符串類型的值; 配置項(xiàng)的缺失是指沒有對某一項(xiàng)配置賦予值, 如CVE-2019-10132[32]。這類錯(cuò)誤通常只有當(dāng)程序運(yùn)行到需要這一配置項(xiàng)時(shí)才會(huì)發(fā)現(xiàn), 因此潛藏較深。

2.2.2 性能配置參數(shù)缺陷

性能配置參數(shù)缺陷指性能相關(guān)配置項(xiàng)的值發(fā)生錯(cuò)誤導(dǎo)致無法提供系統(tǒng)預(yù)期的性能, 或者使固件各部分無法很好兼容[30], 性能配置參數(shù)同硬件有較大聯(lián)系。這類缺陷通常不會(huì)直接引起系統(tǒng)掛起、崩潰等異常行為, 但是無法提供系統(tǒng)預(yù)期的性能, 無法滿足用戶的需求。如在配置文件中為固件分配了較小的內(nèi)存空間, 這樣就無法提供預(yù)期的性能。

例如, 在CVE-2019-2041中, 由于沒有對NFC進(jìn)行合理配置而是使用了默認(rèn)值, 導(dǎo)致了NFC無法區(qū)分個(gè)人設(shè)備[33]。

2.2.3 權(quán)限配置參數(shù)缺陷

權(quán)限配置參數(shù)缺陷允許用戶做出超越自身權(quán)限的行為, 如果該用戶被攻擊, 則系統(tǒng)會(huì)遭受更大的損失。

例如, ABB VSN300 WiFi Logger Card中沒有正確限制不同客戶的權(quán)限, 致使攻擊者可以訪問到關(guān)鍵信息(CVE-2017-7916)[34]; Dasan H660RM設(shè)備上的BOA服務(wù)器配置將敏感數(shù)據(jù)放在了錯(cuò)誤的位置, 低權(quán)限的用戶可以隨意對這些文件進(jìn)行查看(CVE-2019-9976)[35]。

陳偉等人[36]、Xu等人[37]、李福亮等人[38]已對普通軟件領(lǐng)域和互聯(lián)網(wǎng)領(lǐng)域的配置缺陷產(chǎn)生原因、影響、測試手段、修復(fù)手段等做了大量的調(diào)研工作。Yin等人[30]的工作對現(xiàn)實(shí)生活中的軟件進(jìn)行了研究, 對配置缺陷進(jìn)行了分類, 總結(jié)了配置缺陷產(chǎn)生的原因及影響, 且說明了配置缺陷在軟件缺陷中占了非常大的比例。

2.3 定制缺陷

定制缺陷是指用戶根據(jù)自己和環(huán)境需要對固件進(jìn)行一定的修改, 但是這種修改使固件產(chǎn)生了不可預(yù)期的錯(cuò)誤。這一錯(cuò)誤的發(fā)生可能是由于用戶對固件源碼的不熟悉、固件對不同環(huán)境的適配性不好等, 定制缺陷可造成實(shí)現(xiàn)缺陷和配置缺陷, 這一缺陷的檢測無需對整個(gè)固件進(jìn)行測試, 可以將測試重點(diǎn)放在被修改及相關(guān)部分。

雖然固件中的缺陷分為不同的種類, 但是這些缺陷之間通常會(huì)有一定的依賴關(guān)系, 一種缺陷的發(fā)生有可能會(huì)導(dǎo)致其他缺陷的發(fā)生。實(shí)現(xiàn)缺陷可以視為最基本的缺陷, 其來源有多種, 但主要來源還是開發(fā)人員在編寫過程中的粗心大意; 配置缺陷主要由部署人員引入, 配置值的本質(zhì)就是程序中的變量, 變量的輸入來自于配置編寫人員, 如果配置值編寫不當(dāng), 而代碼中沒有對配置值進(jìn)行檢查, 也會(huì)引出實(shí)現(xiàn)缺陷; 定制缺陷由用戶自己引入, 用戶在定制過程中可能會(huì)對配置或者代碼進(jìn)行一定的修改, 因此定制缺陷會(huì)造成實(shí)現(xiàn)缺陷和配置缺陷。

3 固件安全缺陷檢測技術(shù)

有效的檢測上述固件安全缺陷是保障物聯(lián)網(wǎng)設(shè)備安全的關(guān)鍵。自動(dòng)化的固件安全缺陷檢測一方面可以實(shí)現(xiàn)在固件發(fā)布之前發(fā)現(xiàn)缺陷, 有效避免大量損失; 另一方面可以實(shí)現(xiàn)短時(shí)間內(nèi)的大量固件分析, 節(jié)省了開發(fā)人員時(shí)間以及相關(guān)財(cái)力物力。

目前主流的自動(dòng)化缺陷檢測技術(shù)可以分為五類, 分別是靜態(tài)分析、符號執(zhí)行、模糊測試、程序驗(yàn)證、機(jī)器學(xué)習(xí), 不同的技術(shù)有不同的應(yīng)用場景和優(yōu)勢, 幾種檢測方法之間還可以進(jìn)行結(jié)合, 相輔相成。下面將對這五類檢測方法進(jìn)行介紹。

3.1 靜態(tài)分析技術(shù)

靜態(tài)分析是指在不運(yùn)行固件系統(tǒng)的情況下, 基于固件代碼制品(如源碼、抽象語法樹、中間表示等)對其進(jìn)行分析, 通過與典型固件缺陷模式的匹配, 達(dá)到檢測潛在安全缺陷的目的[39]。

PIE[40]將固件通信協(xié)議中用于解析外部輸入生成內(nèi)部數(shù)據(jù)結(jié)構(gòu)、根據(jù)輸入選擇執(zhí)行路徑的代碼稱為PARC3(PArser-like Routines and Complex Control-flow Code), 并總結(jié)了這部分代碼的兩個(gè)特征: (1)擁有大量循環(huán)來處理輸入; (2)擁有許多依賴輸入的條件分支。PIE基于這兩個(gè)特征, 借助了簡單的機(jī)器學(xué)習(xí)方法可以高效的發(fā)現(xiàn)未知固件中的PARC3。固件中的通信協(xié)議是固件與外界交流的接口, 這部分代碼通常復(fù)雜但缺少文檔, 而且為了提高性能、減少固件規(guī)模, 協(xié)議中許多安全措施都被省略, 通信協(xié)議中對外部輸入的檢查是固件安全的第一道屏障。

由于固件代碼量日益增多, 基于靜態(tài)分析技術(shù)對固件進(jìn)行缺陷分析面臨可擴(kuò)展性問題。為了緩解這一問題, DTaint[41]提出了對固件進(jìn)行污點(diǎn)分析, 可以減少分析的代碼量, 提高分析效率。DTaint不需要固件源碼, 使用固件可執(zhí)行文件作為輸入, 將其轉(zhuǎn)化為中間表示后進(jìn)行分析。支持指針分析和間接調(diào)用分析, 加入了對不同架構(gòu)的支持, 提高了可擴(kuò)展性。但由于不同系統(tǒng)類型的固件差別較大, DTaint目前只支持基于Linux的固件。

單純的靜態(tài)分析無法獲取準(zhǔn)確的污點(diǎn)傳播情況, 容易造成大量的誤報(bào), 可擴(kuò)展性較差。Saluki[42]通過“運(yùn)行”代碼片段來提高污點(diǎn)分析的精度, Saluki實(shí)現(xiàn)了定制的解釋器μflux來“運(yùn)行”從二進(jìn)制文件中提取的IR, 而不需要運(yùn)行時(shí)環(huán)境支撐, 可以獲取準(zhǔn)確的路徑敏感和上下文敏感數(shù)據(jù)傳播信息。Saluki支持ARM、x86和x86-64架構(gòu)的二進(jìn)制可執(zhí)行文件, 可以兼顧普通桌面軟件和固件。Saluki還實(shí)現(xiàn)了可定制化的安全準(zhǔn)則, 使污點(diǎn)分析支持更多的漏洞類型。

基于Linux的固件往往由多個(gè)組件構(gòu)成, 每個(gè)組件都是一個(gè)可執(zhí)行文件, 許多分析對每個(gè)可執(zhí)行文件單獨(dú)進(jìn)行污點(diǎn)分析, 容易造成大量誤報(bào)。KARONTE[43]在對固件進(jìn)行分析時(shí)考慮了固件不同組件之間的交互和數(shù)據(jù)流動(dòng), 大大降低了污點(diǎn)分析的誤報(bào)。

BootStomp[44]針對手機(jī)中引導(dǎo)程序提出了靜態(tài)分析方法, 結(jié)合基于符號執(zhí)行的多標(biāo)簽污點(diǎn)分析方法, 可以發(fā)現(xiàn)引導(dǎo)程序中使用被攻擊者控制的存儲(chǔ)導(dǎo)致的內(nèi)存損壞缺陷和引導(dǎo)程序解鎖, 大大降低了純靜態(tài)污點(diǎn)分析工作的誤報(bào)。

目前, 基于靜態(tài)分析技術(shù)對固件配置進(jìn)行分析的研究較少, 大多工作都集中于對PC桌面軟件、移動(dòng)應(yīng)用軟件配置的分析。如Rabkin等人[45]的研究工作提出了一種從Java代碼中靜態(tài)提取配置項(xiàng)并發(fā)現(xiàn)其可能選項(xiàng)的方法。通過考察配置讀取函數(shù)的返回值、配置值傳遞路徑來推斷配置的類型、約束和取值范圍, 工作的重點(diǎn)在于發(fā)現(xiàn)配置項(xiàng)在代碼中的使用位置和別名, 沒有進(jìn)行數(shù)據(jù)流分析, 因此誤差會(huì)較大。

Xu等人[46]設(shè)計(jì)了一個(gè)針對MySQL、Aphace等商業(yè)軟件的配置錯(cuò)誤進(jìn)行檢測的工具SPEX。SPEX以軟件源代碼和簡單注釋為輸入, 通過檢查配置值是否符合配置約束來判斷是否正確。該工作存在一定的局限。首先, SPEX只能檢測單個(gè)程序上的配置是否正確, 但現(xiàn)實(shí)生活中許多系統(tǒng)不局限于單個(gè)系統(tǒng); 其次, 可以推斷的約束有限。

Rabkin等人[47]通過靜態(tài)分析將程序的每一行源代碼映射到可能相關(guān)的配置項(xiàng), 以此幫助用戶快速發(fā)現(xiàn)源代碼錯(cuò)誤的原因。

由于固件的代碼量逐漸增多、日益復(fù)雜等特征, 只對固件進(jìn)行純靜態(tài)分析往往無法取得很好的效果, 而且由于不同廠商、架構(gòu)、系統(tǒng)的固件差別較大, 較為精確的靜態(tài)分析的可擴(kuò)展性也較弱。通過靜態(tài)分析對配置缺陷進(jìn)行檢測通常是通過數(shù)據(jù)流分析來發(fā)現(xiàn)代碼中的約束, 檢查配置值是否違反約束, 這一方法對功能配置參數(shù)缺陷具有較好的檢測效果, 如果可以構(gòu)建較為準(zhǔn)確的數(shù)據(jù)流分析, 則通過靜態(tài)分析來發(fā)現(xiàn)固件的功能配置缺陷則具有一定的可行性, 但是難點(diǎn)在于固件的許多配置同硬件相關(guān), 這些配置往往無法通過上下文代碼去推斷。

3.2 符號執(zhí)行技術(shù)

符號執(zhí)行技術(shù)最早源于20世紀(jì)70年代中期, 基本思想是用符號化變量代替實(shí)際輸入, 驅(qū)動(dòng)程序模擬執(zhí)行, 收集執(zhí)行路徑約束集合, 調(diào)用求解器求解約束產(chǎn)生測試輸入, 進(jìn)而探索程序空間, 用于發(fā)現(xiàn)程序缺陷[48]。符號執(zhí)行使用符號值表示具體的變量, 相比模糊測試可以更加容易通過復(fù)雜的判斷, 在普通軟件測試中有廣泛的應(yīng)用。

3.2.1 特定架構(gòu)的分析

Davidson等人[49]提出了基于符號執(zhí)行引擎KLEE的符號執(zhí)行工具FIE, 實(shí)現(xiàn)了對基于MSP430系列微控制器的固件程序有效缺陷檢測。面向小型固件程序(代碼少于100行), FIE使用狀態(tài)修剪技術(shù)來避免路徑爆炸, 使用記憶模糊技術(shù)提高符號執(zhí)行的效率, 同時(shí)加入了對中斷和外部輸入的支持, 可以分析程序所有的路徑。FIE是符號執(zhí)行方法在固件測試中較早的研究, 但其只能針對特定的架構(gòu), 且可處理代碼行數(shù)較少, 誤報(bào)較多。Hernandez等人[50]基于FIE, 通過加入對Intel 8051 MCU的支持, 實(shí)現(xiàn)了針對USB固件的符號執(zhí)行分析框架FirmUSB。FirmUSB結(jié)合靜態(tài)分析和符號執(zhí)行, 通過充當(dāng)語義查詢引擎, 檢查設(shè)備固件以確定其生成潛在惡意行為的能力。此外, FirmUSB通過將二進(jìn)制固件轉(zhuǎn)化為中間表示進(jìn)行分析, 不需要固件源碼。

3.2.2 特定缺陷的分析

和FirmUSB一樣, 許多分析工具并不是針對違反編程規(guī)范的錯(cuò)誤, 而是面向某一類惡意行為, 使用符號執(zhí)行進(jìn)行語義分析來查找符合某種模式的缺陷。典型的, Oleksandr等人[51]提出一種基于KLEE的符號執(zhí)行工具, 用來分析BIOS中SMM中斷處理程序的危險(xiǎn)內(nèi)存引用。方法是使用S2E通過SMM中斷處理程序探索執(zhí)行路徑, 并發(fā)現(xiàn)中斷處理程序試圖訪問SMM代碼保護(hù)區(qū)域SMRAM之外的內(nèi)存的路徑。

表2 靜態(tài)分析工具比較 Table 2 Comparison of Static Analysis Tools

Yan等人[52]提出利用符號執(zhí)行技術(shù)來查找二進(jìn)制固件中身份驗(yàn)證繞過缺陷, 并實(shí)現(xiàn)了分析框架Firmalice。Firmalice利用一種新型的身份驗(yàn)證旁路功能, 基于攻擊者確定執(zhí)行特權(quán)操作所需輸入的能力, 如果攻擊者只需通過分析固件就可以獲得必要的輸入來驅(qū)動(dòng)固件執(zhí)行特權(quán)操作, 則說明認(rèn)證機(jī)制可以被忽略或繞過。另外, 模型允許推斷復(fù)雜的后門程序。Firmalice的符號執(zhí)行部分參考了KLEE, 并使用程序切片技術(shù)增強(qiáng)其可擴(kuò)展性。

3.2.3 通用分析框架

為了支持更多固件代碼的處理, Corteggiani等人[53]基于KLEE開發(fā)了針對固件代碼的符號執(zhí)行框架Inception, 此工作一定程度上消除了平臺(tái)的差異。Inception的主要目標(biāo)是利用高級源代碼的語義信息在符號執(zhí)行期間檢測缺陷, 同時(shí)支持低級匯編代碼和與硬件外圍設(shè)備的頻繁交互。常見的符號執(zhí)行環(huán)境通常運(yùn)行與體系結(jié)構(gòu)無關(guān)的代碼表示, 這些代碼可以從源代碼派生而不丟失語義信息; 或者依賴于體系結(jié)構(gòu)的二進(jìn)制代碼可以提升為中間表示, 該表示至少可以部分執(zhí)行到符號虛擬機(jī)中, 但已丟失源代碼語義信息。這兩種情況差別很大, 不容易共存。Inception通過創(chuàng)建一致的統(tǒng)一表示來解決共存問題。

基于符號執(zhí)行的分析是現(xiàn)在進(jìn)行固件安全缺陷檢測的主要方法之一, 大部分基于KLEE, 側(cè)重點(diǎn)各有不同?，F(xiàn)有的工具如FIE、FirmUSB等通常針對自己的研究目標(biāo)引入了對特定硬件架構(gòu)的支持, Inception的工作則一定程度上消除了平臺(tái)的差異, 極大的提高了工具的可擴(kuò)展性, 且他們都加入了對外設(shè)輸入和中斷的支持, 采用了一定的方法來避免路徑爆炸和提高符號執(zhí)行效率。但現(xiàn)有符號執(zhí)行方法大多需要源碼, 只有FirmUSB、Firmalice等個(gè)別工具可以直接以二進(jìn)制固件作為輸入, 因此未來的工作還需要研究如何以二進(jìn)制固件直接作為輸入進(jìn)行分析并支持更多架構(gòu)。具體如表3所示。

3.3 模糊測試技術(shù)

模糊測試技術(shù)最早出現(xiàn)于1990年, Miller使用模糊測試來發(fā)現(xiàn)UNIX系統(tǒng)中的漏洞[54]。模糊測試技術(shù)通過在真實(shí)環(huán)境或者虛擬環(huán)境中運(yùn)行程序, 向運(yùn)行程序發(fā)送大量有效或無效的輸入, 并觀察程序在運(yùn)行過程中的行為特征, 與典型缺陷行為特征相匹配以達(dá)到檢測的目的[55]。按照固件運(yùn)行的環(huán)境, 現(xiàn)有模糊測試技術(shù)可以分為基于真實(shí)設(shè)備以及基于模擬執(zhí)行環(huán)境的模糊測試。

3.3.1 基于真實(shí)設(shè)備環(huán)境的模糊測試

由于真實(shí)硬件設(shè)備提供的調(diào)試接口有限, 因此基于真實(shí)設(shè)備的模糊測試通過觀察系統(tǒng)運(yùn)行日志或者系統(tǒng)輸出來判斷是否存在缺陷。Sara等人[28]提出了一種運(yùn)行時(shí)驗(yàn)證工具來檢測FreeRTOS中的并發(fā)缺陷。他們的工具基于Tracealyzers所提取的FreeRTOS運(yùn)行日志來進(jìn)行分析, 查看任務(wù)的運(yùn)行時(shí)間來檢測其是否符合并發(fā)缺陷的特征。此工具可檢測死鎖(Deadlock Bug)、饑餓漏洞(Starvation Bug)和掛起漏洞(Suspension Bug)。

表3 符號執(zhí)行工具比較 Table 3 Comparison of Symbolic Execution Tools

RPFuzzer[56]是一個(gè)用于檢測路由協(xié)議缺陷的框架, 通過向真實(shí)設(shè)備發(fā)送大量數(shù)據(jù)包, 監(jiān)控CPU使用與查看系統(tǒng)日志, 進(jìn)而檢測設(shè)備重啟與拒絕服務(wù)漏洞。RPFuzzer的測試用例生成分為兩個(gè)階段, 第一階段基于手動(dòng)分析和自動(dòng)生成; 第二階段基于第一階段的測試用例和歷史漏洞數(shù)據(jù)進(jìn)行變異。RPFuzzer可以針對路由器支持的多種協(xié)議進(jìn)行測試。

IoTFuzzer[57]發(fā)現(xiàn)IoT終端設(shè)備往往伴隨著一個(gè)與之交互的移動(dòng)應(yīng)用程序, 于是基于移動(dòng)應(yīng)用程序與真實(shí)終端設(shè)備開發(fā)了一個(gè)檢測固件程序中內(nèi)存損壞缺陷的黑盒模糊測試工具。可以通過對移動(dòng)應(yīng)用程序進(jìn)行分析來推導(dǎo)未知協(xié)議中需要變異的字段, 生成有效的模糊測試用例, 并且克服了網(wǎng)絡(luò)通信中的加密問題, IoTFuzzer使用心跳機(jī)制檢測設(shè)備是否發(fā)生異常。

Li等人[58]針對RTSP協(xié)議的缺陷挖掘提出了利用RTSP協(xié)議狀態(tài)間的約束關(guān)系和轉(zhuǎn)移關(guān)系構(gòu)造協(xié)議狀態(tài)圖, 基于狀態(tài)圖來消除測試用例中的冗余。

Yuan等人[59]提出一個(gè)不需要源代碼的在線黑盒測試工具CODE來對使用最為頻繁的配置進(jìn)行缺陷檢測。CODE通過對運(yùn)行時(shí)的應(yīng)用程序進(jìn)行觀測, 提取重復(fù)的、可預(yù)測的事件序列形成配置的訪問規(guī)則, 當(dāng)訪問配置時(shí)違反了規(guī)則, 則表明當(dāng)前配置可能發(fā)生錯(cuò)誤。

Su和Attariyan等人[60]通過在Linux內(nèi)核級對與配置相關(guān)的動(dòng)作的輸入和輸出進(jìn)行跟蹤, 推斷出配置錯(cuò)誤發(fā)生的因果關(guān)系, 并實(shí)現(xiàn)了工具AutoBash。AutoBash將配置活動(dòng)分割為可以改變系統(tǒng)狀態(tài)的動(dòng)作, 通過斷言來測試系統(tǒng)正確性。

Attariyan等人[61]通過對二進(jìn)制文件進(jìn)行插樁, 在程序運(yùn)行時(shí)通過控制流和數(shù)據(jù)流獲取依賴關(guān)系, 通過依賴關(guān)系將異常行為定位到特定的配置項(xiàng)中, 實(shí)現(xiàn)了名為ConfAid的動(dòng)態(tài)配置缺陷檢測工具。這一工作是AutoBash的延申。

Zhang等人[62]提出了一個(gè)靜態(tài)分析和動(dòng)態(tài)分析相結(jié)合來診斷單個(gè)配置缺陷的工具ConfDiagnoser。ConfDiagnoser以Java程序和配置項(xiàng)作為輸入, 收集程序運(yùn)行時(shí)特征, 并在數(shù)據(jù)庫中進(jìn)行匹配以發(fā)現(xiàn)缺陷。ConfDiagnoser存在四個(gè)局限性: 工具只關(guān)注key-value形式的配置; 對配置缺陷的診斷僅限于一個(gè)配置項(xiàng)的缺陷; 不支持非確定性的缺陷; 有效性取決于數(shù)據(jù)庫中存在相似且正確的程序執(zhí)行。

3.3.2 基于模擬執(zhí)行環(huán)境的模糊測試

Zaddach等人[63]提出了一個(gè)框架Avatar, 通過將仿真器的執(zhí)行與實(shí)際硬件協(xié)調(diào)在一起, 實(shí)現(xiàn)了對嵌入式設(shè)備的復(fù)雜動(dòng)態(tài)分析。Avatar充當(dāng)物理設(shè)備和模擬器之間的協(xié)調(diào)引擎, 在模擬器內(nèi)部執(zhí)行固件指令, 同時(shí)將輸入輸出操作引導(dǎo)到物理硬件, 利用真正的硬件來處理輸入輸出操作。Avatar彌補(bǔ)了模擬器對外設(shè)模擬能力不足的局限, 但是仍離不開具體的硬件。Avatar的后繼版本Avatar2[64]則是第一個(gè)面向多目標(biāo)編程的通用框架, 可以用來協(xié)調(diào)連接不同的二進(jìn)制分析框架、調(diào)試器、仿真器和實(shí)際物理硬件, 使不同工具之間實(shí)現(xiàn)互操作性。

Chen等人[65]實(shí)現(xiàn)了第一個(gè)對基于Linux的商用物聯(lián)網(wǎng)設(shè)備固件在模擬器中進(jìn)行仿真、自動(dòng)化分析的系統(tǒng)FIRMADYNE, 此工作可以仿真Linux系統(tǒng), 并完全脫離硬件進(jìn)行仿真。FIRMADYNE使用binwalk進(jìn)行解包, 并在QEMU中仿真運(yùn)行。在FIRMADYNE上可以方便地?cái)U(kuò)展各種動(dòng)態(tài)分析方法。FIRMADYNE在很大程度上實(shí)現(xiàn)了脫離硬件的仿真, 但是受限于QEMU的能力有限, 可以成功運(yùn)行的固件很少, 且只能針對基于Linux的固件。Firm-AFL[66]基于FIRMADYNE實(shí)現(xiàn)了對基于Linux的物聯(lián)網(wǎng)固件的高性能灰盒模糊測試, 這是第一個(gè)針對固件的灰盒模糊測試系統(tǒng), 而且提高了固件模擬執(zhí)行的效率。

Avatar和FIRMADYNE是當(dāng)前研究較多的兩個(gè)框架, 但如果脫離硬件, 都無法很好處理外設(shè)輸入, 這成為在模擬環(huán)境中測試的一個(gè)難點(diǎn), P2IM[67]基于外設(shè)接口抽象建模設(shè)計(jì)了一個(gè)擺脫硬件依賴的MCU固件模糊測試框架, 解決了模糊測試對真實(shí)硬件的依賴和模擬器對外設(shè)模擬能力有限的問題。但是當(dāng)P2IM遇到固件通過直接內(nèi)存訪問(Direct Memory Access, DMA)來獲取外設(shè)輸入時(shí), 通常無法識別并返回?zé)o效的值, 導(dǎo)致固件運(yùn)行崩潰。后續(xù)的工作DICE[68]通過識別固件中的DMA輸入輸出通道并動(dòng)態(tài)創(chuàng)建輸入緩沖區(qū)來解決這一問題, 與P2IM相比大大提高了測試的代碼覆蓋率。Laelaps[69]使用符號執(zhí)行來生成外設(shè)輸入, 擺脫了模擬器對外設(shè)處理能力有限的問題。Laelaps針對ARM Cortex-M設(shè)備, 將Microcontroller固件運(yùn)行在QEMU中, 使用符號執(zhí)行來生成滿足要求的外設(shè)輸入。

P2IM、DICE和Lealaps基于對固件的分析來生成外設(shè)輸入, 一定程度上解決了模擬器對外設(shè)模擬能力有限的問題, 但支持的外設(shè)類型和輸入輸出類型有限。HALucinator[70]通過替換固件硬件抽象層(HardwareAbstraction Layers, HAL)使其不依賴于具體硬件, 并可以成功在QEMU中運(yùn)行, 最終還結(jié)合了AFL實(shí)現(xiàn)了對固件的模糊測試。

戴忠華等人[71]提出一種基于靜態(tài)分析和動(dòng)態(tài)調(diào)試的固件缺陷分析利用框架。使用QEMU搭建環(huán)境, 首先利用靜態(tài)污點(diǎn)分析繪制污點(diǎn)數(shù)據(jù)傳播圖, 從而輔助動(dòng)態(tài)調(diào)試, 快速定位缺陷。最后使用sulley工具進(jìn)行模糊測試。這一工作對人工的依賴較大, 仍無法完全自動(dòng)化。傳統(tǒng)的模糊測試通常會(huì)生成大量的測試用例, 但是測試用例之間經(jīng)常會(huì)發(fā)生冗余, 降低測試效率。

Xu等人[72]提出了一種在軟件發(fā)布之前通過模擬運(yùn)行來檢測潛在配置缺陷的方法, 并實(shí)現(xiàn)了配置缺陷檢測軟件PCHECK。PCHECK以IR作為輸入, 并以配置接口規(guī)范和系統(tǒng)初始化階段的注釋作為輔助輸入用來識別配置項(xiàng)。

模糊測試方法比較如表4所示, 可以發(fā)現(xiàn)現(xiàn)有的模糊測試工具大多是通過觀測系統(tǒng)崩潰來檢測是否存在缺陷。然而, Muench等人[73]通過實(shí)驗(yàn)發(fā)現(xiàn), 不同的固件針對內(nèi)存相關(guān)缺陷的表現(xiàn)并不相同。許多固件在遇到內(nèi)存相關(guān)缺陷時(shí)系統(tǒng)沒有任何明顯表現(xiàn), 可以繼續(xù)運(yùn)行, 這對缺陷檢測提出了新的挑戰(zhàn)。作者提出對內(nèi)存的使用進(jìn)行監(jiān)測來判斷是否存在缺陷, 但是這一方法目前只能在模擬器中進(jìn)行。此外, 現(xiàn)實(shí)中大量其他實(shí)現(xiàn)缺陷的表現(xiàn)也不相同?；趯?shí)際執(zhí)行環(huán)境的模糊測試由于硬件資源有限、調(diào)試接口不完備, 可以獲取的固件運(yùn)行信息較少, 可以檢測到的缺陷有限。基于模擬執(zhí)行環(huán)境的方法可以方便地觀察固件運(yùn)行時(shí)的狀態(tài)、構(gòu)造極端運(yùn)行環(huán)境、提高測試的代碼覆蓋率, 但模擬執(zhí)行仍受限于模擬器的能力有限, 現(xiàn)有的模擬器只能運(yùn)行部分固件, 可擴(kuò)展性較差。尤其是對于中斷和外部輸入的處理能力有限, 未來的工作可以用其他方法來彌補(bǔ)模擬器的不足, 如使用符號執(zhí)行根據(jù)路徑約束來推斷外設(shè)輸入、通過模糊測試來隨機(jī)生成外設(shè)輸入、通過一定的反饋機(jī)制來引導(dǎo)生成外設(shè)輸入等?，F(xiàn)有的針對配置缺陷的檢測方法則是傳統(tǒng)的動(dòng)態(tài)測試, 這些方法在固件上實(shí)施具有理論可行性, 難點(diǎn)仍在于固件的有效執(zhí)行和執(zhí)行時(shí)信息的獲取。

表4 模糊測試工具比較 Table 4 Comparison of Dynamic Testing Tools

3.4 程序驗(yàn)證技術(shù)

程序驗(yàn)證技術(shù)是指以數(shù)學(xué)和邏輯為基礎(chǔ), 對系統(tǒng)進(jìn)行說明、設(shè)計(jì)和驗(yàn)證, 通過形式規(guī)約來描述系統(tǒng)的行為或者系統(tǒng)應(yīng)該滿足的性質(zhì), 采用形式化驗(yàn)證來驗(yàn)證系統(tǒng)是否滿足需求和具備這些性質(zhì), 即是否滿足規(guī)約[74]。

Prakash Chandrasekaran等人[29]提出了一種在多核處理器上運(yùn)行FreeRTOS的調(diào)度方案, 并通過Spin建模語言進(jìn)行建模驗(yàn)證了他們的方案可以避免數(shù)據(jù)競爭和死鎖。這一工作為固件程序的并發(fā)問題缺陷檢測提供了解決方法。

Xie[75]以反編譯技術(shù)為基礎(chǔ), 通過Kripke結(jié)構(gòu)描述模型進(jìn)行建模來對固件進(jìn)行模型檢驗(yàn)。Zhang等人[76]提出了基于行為時(shí)序邏輯(temporal logical of actions, TLA)的軟硬件協(xié)同驗(yàn)證固件缺陷分析技術(shù), 將硬件工作流程和軟件對硬件的調(diào)用相結(jié)合分析來發(fā)現(xiàn)計(jì)算機(jī)開機(jī)過程中存在的缺陷。

Huang等人[77]提出了一種對大型云系統(tǒng)進(jìn)行配置驗(yàn)證的框架ConfValley。其核心是一種簡單的聲明性的配置驗(yàn)證語言CPL, 該語言將核心驗(yàn)證邏輯與實(shí)現(xiàn)細(xì)節(jié)分離, 允許緊湊地描述規(guī)范并獨(dú)立于基礎(chǔ)配置表示, 好處是驗(yàn)證代碼變得可維護(hù)、模塊化、可并行化, 并且適用于各種配置源。

現(xiàn)有對固件程序進(jìn)行形式化驗(yàn)證的工作較少, 但是已有的工作已經(jīng)證明了形式化驗(yàn)證在保證固件安全方面的有效性。FreeRTOS作為輕量級的嵌入式操作系統(tǒng), 為固件提供調(diào)度是其基本功能之一, 使用Spin建模語言對其進(jìn)行程序驗(yàn)證為使用建模語言對固件程序的多線程調(diào)度進(jìn)行程序驗(yàn)證提供了可能; 大型云系統(tǒng)中的配置主要用來設(shè)置云系統(tǒng)運(yùn)行環(huán)境和協(xié)調(diào)各個(gè)組件, 這點(diǎn)和固件具有一定的相似之處, 固件中的配置也主要用來設(shè)置底層硬件相關(guān)信息、協(xié)調(diào)外設(shè)的使用, 因此ConfValley對固件配置的驗(yàn)證有一定的借鑒作用。

3.5 基于機(jī)器學(xué)習(xí)的方法

現(xiàn)有的基于機(jī)器學(xué)習(xí)的方法大多通過靜態(tài)分析或者動(dòng)態(tài)執(zhí)行來提取程序特征, 使用一些機(jī)器學(xué)習(xí)算法來學(xué)習(xí)已有的缺陷特征, 并在程序中查找已知缺陷[78]?，F(xiàn)有的基于機(jī)器學(xué)習(xí)的固件缺陷檢測方法以目標(biāo)匹配對象劃分可以分為三類, 分別為上下文無關(guān)的函數(shù)匹配、上下文敏感的函數(shù)匹配和二進(jìn)制固件文件匹配。

3.5.1 上下文無關(guān)的函數(shù)匹配

Feng等人[79]提出一個(gè)基于控制流程圖(CFG)的缺陷搜索引擎Genius。作者提出將CFG轉(zhuǎn)換為高級數(shù)字特征向量, 降低了CFG匹配的開銷, 解決了現(xiàn)有跨平臺(tái)缺陷搜索技術(shù)的可擴(kuò)展性問題, 進(jìn)一步提高了搜索的準(zhǔn)確性。與現(xiàn)有的缺陷搜索方法相比, Genius具有以下兩個(gè)好處: 首先, 所學(xué)習(xí)的特征對于跨體系結(jié)構(gòu)的變化趨向于比原始CFG特征變化更小; 其次, Genius顯著提高了缺陷搜索效率。

在之后的研究中Feng等人[80]還提出了一種基于從原始二進(jìn)制碼中提取的條件公式作為高級語義特征進(jìn)行代碼搜索的方法, 并根據(jù)此實(shí)現(xiàn)了工具XMATCH。使用條件公式可以明確地捕獲兩種缺陷: 1)錯(cuò)誤的數(shù)據(jù)依賴; 2)缺失或無效的條件檢查。使用條件公式進(jìn)行代碼搜索具有兩個(gè)優(yōu)點(diǎn): 1)顯著提高了搜索的準(zhǔn)確性, 在二進(jìn)制代碼級別上消除了特定平臺(tái)的差異; 2)為分析人員提供可以解釋的證據(jù), 以審查搜索結(jié)果并確定易受攻擊的功能。除了根據(jù)二進(jìn)制代碼中不同的上下文語義來搜索安全缺陷外, 還進(jìn)一步使分析人員能夠通過生成的可解釋診斷報(bào)告來檢查搜索結(jié)果, 以便確定目標(biāo)程序中顯示的缺陷代碼。

Xu等人[81]對神經(jīng)網(wǎng)絡(luò)進(jìn)行了修改, 使其可以將從固件中提取的屬性控制流圖(attributed control flow graph, ACFG)轉(zhuǎn)化為數(shù)字特征向量-嵌入向量(embedding vectors), 這一方法大大縮減了嵌入向量的生成時(shí)間和模型的訓(xùn)練時(shí)間。作者基于這一方法構(gòu)建了工具Gemini。

Gao等人[82]提出了基于語義學(xué)習(xí)的代碼相似性計(jì)算工具VulSeeker, 作者從固件中提取標(biāo)記了的語義流圖(Labeled Semantic Flow Graph, LSFG), 該圖同時(shí)包含數(shù)據(jù)流圖和控制流圖, 將圖中的邊標(biāo)記為0和1分別來表示控制流和數(shù)據(jù)流, 作者使用從LSFG中提取的基本塊特征作為數(shù)字向量, 以此數(shù)字向量為輸入通過語義感知的DNN模型計(jì)算, 得出函數(shù)的嵌入向量, 通過計(jì)算兩個(gè)函數(shù)的嵌入向量的余弦距離來計(jì)算相似性。與Gemini相比, VulSeeker在top-10和top-50的相似結(jié)果中分別多發(fā)現(xiàn)了50%和13.89%的缺陷。之后作者擴(kuò)展形成新的工作VulSeeker-Pro[83], 通過仿真執(zhí)行候選函數(shù)來對獲得語義簽名表示的動(dòng)態(tài)執(zhí)行軌跡, 計(jì)算候選函數(shù)同缺陷函數(shù)的Jaccard相似度來對候選函數(shù)重新排序, 提高識別的精度。

常青等人[84]針對現(xiàn)有跨平臺(tái)缺陷檢測方法準(zhǔn)確率低的問題, 提出基于神經(jīng)網(wǎng)絡(luò)和局部調(diào)用結(jié)構(gòu)匹配的2階段跨平臺(tái)固件缺陷關(guān)聯(lián)方法。以函數(shù)為最小關(guān)聯(lián)單元, 對函數(shù)調(diào)用圖、函數(shù)內(nèi)控制流圖、函數(shù)基本信息進(jìn)行特征選擇和數(shù)值化處理, 并采用神經(jīng)網(wǎng)絡(luò)計(jì)算待匹配函數(shù)對的相似程度, 在此基礎(chǔ)上采用結(jié)構(gòu)化匹配方法進(jìn)一步提高匹配精度。

3.5.2 上下文敏感的函數(shù)匹配

前面的工作大多針對固件中的單個(gè)函數(shù)來進(jìn)行匹配, 但往往缺陷會(huì)跨多個(gè)函數(shù)出現(xiàn), 這種情況下上述工作將難以應(yīng)對。David等人[85]提出了基于Angr的靜態(tài)分析工具FirmUP, 用于程序在過程間層面進(jìn)行缺陷相似性匹配。作者的方法是將其他的過程作為程序執(zhí)行的環(huán)境, 將過程分解為比基本塊更小的Strands-based representation, 將其中的寄存器名和地址偏移一致化, 以函數(shù)為單位制成一張表, 以表中相同的代碼片段的數(shù)量作為相似度來進(jìn)行匹配。匹配使用了back-and-forth games算法。

3.5.3 二進(jìn)制固件文件匹配

Andrei等人[86]的工作收集了大量的固件程序, 設(shè)計(jì)了分布式的架構(gòu)對其進(jìn)行解包和簡單的靜態(tài)分析, 并實(shí)現(xiàn)了一個(gè)引擎來比較和確定數(shù)據(jù)集中所有對象之間的相似性, 可以快速地將已知易受攻擊的設(shè)備的缺陷“傳播”到以前不知道受到相同缺陷影響的其他系統(tǒng)。

Chen等人[87]發(fā)現(xiàn)固件代碼在不同編譯環(huán)境、優(yōu)化選項(xiàng)下編譯出來的二進(jìn)制碼并不完全相同, 但代碼中通常會(huì)包含一些具有“編譯不變性”的字符串, 如調(diào)試字符串、標(biāo)語字符串等, 如果兩個(gè)文件中的可讀字符串內(nèi)容和順序基本一致, 則很大可能這兩個(gè)文件是同源的。作者利用深度學(xué)習(xí)來編碼可讀字符串, 對編碼字符串生成局部敏感Hash從而實(shí)現(xiàn)快速檢索, 將搜索的時(shí)間復(fù)雜度將為了O(lgN), 大大縮短了搜索時(shí)間。

同一廠商生產(chǎn)的固件通常會(huì)包含一些相同的文件, 容易受到同一缺陷的干擾。Zou等人[88]通過向物聯(lián)網(wǎng)設(shè)備發(fā)送報(bào)文來獲取物聯(lián)網(wǎng)設(shè)備返回的協(xié)議標(biāo)語信息, 用自然語言處理方法來進(jìn)行處理, 最后獲取設(shè)備分類, 以發(fā)現(xiàn)是否同有缺陷的設(shè)備為同一廠商。

3.5.4 基于模板的配置缺陷檢測

Zhang等人[89]根據(jù)配置項(xiàng)與執(zhí)行環(huán)境之間的相互作用和配置項(xiàng)之間的相關(guān)性來檢測配置缺陷, 從一組給定的配置中利用數(shù)據(jù)挖掘技術(shù)學(xué)習(xí)配置規(guī)則, 以此規(guī)則來檢測其他配置的正確性, 并實(shí)現(xiàn)了自動(dòng)化測試工具EnCore。

基于機(jī)器學(xué)習(xí)的方法可以用來檢測固件中的已知缺陷, 且可以跨越不同平臺(tái)進(jìn)行檢測。目前的機(jī)器學(xué)習(xí)方法大多是以靜態(tài)分析方法的延伸出現(xiàn), 只有文獻(xiàn)[86]中的工作是直接對固件解包出來的文件進(jìn)行機(jī)器學(xué)習(xí)匹配, 文獻(xiàn)[88]利用物聯(lián)網(wǎng)設(shè)備的輸出信息對其分類, 其他的方法建立的模型必須基于靜態(tài)分析得出的結(jié)果, 因此效果的好壞很大程度上依賴于程序特征的提取和相應(yīng)的機(jī)器學(xué)習(xí)模型的選擇。基于機(jī)器學(xué)習(xí)的方法與靜態(tài)分析方法的區(qū)別在于側(cè)重點(diǎn)不同, 基于機(jī)器學(xué)習(xí)的方法使用簡單的靜態(tài)分析方法得出程序特征, 使用的靜態(tài)分析方法不足以獨(dú)立發(fā)現(xiàn)其中的缺陷。使用的機(jī)器學(xué)習(xí)模型需要學(xué)習(xí)過程和判斷過程, 如何更好的抽取程序特征和如何對固件程序選取有效的特征和選擇高效的匹配方法是這類方法的主要研究問題。現(xiàn)有的方法使用了不同的精度, 文獻(xiàn)[86]精度最差, 但是勝在數(shù)據(jù)集夠多; 上下文無關(guān)的匹配方法使用了不同的程序特征和學(xué)習(xí)模型, 致力于提高匹配的精度, 且VulSeeker-Pro[83]還使用了額外的方法來提高精度, 但是都無法匹配跨函數(shù)缺陷; FirmUP[85]使用了上下文敏感的方法, 進(jìn)一步提上了匹配的精度。這些方法所使用的靜態(tài)分析方法忽略了靜態(tài)分析在固件上進(jìn)行的難點(diǎn), 丟失了一部分語義, 受到的影響大小根據(jù)方法所選擇的程序特征的不同而不同, 所有這些方法都需要大量的人工確認(rèn)。針對這類方法的總結(jié)如表5所示。

表5 基于機(jī)器學(xué)習(xí)的方法比較 Table 5 Comparisons of Analysis Methods Based on Machine Learning

3.6 缺陷檢測輔助工作

由于固件在代碼結(jié)構(gòu)、運(yùn)行環(huán)境、功能等方面同普通軟件存在較大差別, 固件的測試目前面臨了第1章所述的種種困難, 國內(nèi)也有大量學(xué)者針對這些挑戰(zhàn)提出了部分解決方案。

面向無法獲取源碼這一問題, 解放軍信息工程大學(xué)李清寶團(tuán)隊(duì)在固件代碼反編譯領(lǐng)域取得了大量成果。文獻(xiàn)[90]討論了固件代碼逆向中的指令歸一化、控制流恢復(fù)、中斷向量表等關(guān)鍵問題, 設(shè)計(jì)了逆向平臺(tái)amPro; 文獻(xiàn)[91]針對固件嚴(yán)重依賴中斷提出了基于中斷向量表重構(gòu)的固件代碼反匯編技術(shù), 大大提高了反匯編的精度; 文獻(xiàn)[92]提出了動(dòng)靜態(tài)兩個(gè)方面的固件代碼控制流恢復(fù)算法, 提高了固件控制流恢復(fù)的全面性, 為后續(xù)的分析提供了有力的支持; 文獻(xiàn)[93]提出快速位運(yùn)算方法和區(qū)間生成算法,提高了在固件反匯編中計(jì)算字節(jié)運(yùn)算和位運(yùn)算取值范圍的效率; 文獻(xiàn)[94]則基于反匯編技術(shù)提出了對固件代碼的形式化驗(yàn)證方法和多路徑固件惡意行為檢測方法。

面向固件解碼的判定問題, 中科院信息工程研究所孫利民團(tuán)隊(duì)提出了基于分類回歸樹的固件解碼狀態(tài)檢測算法[95], 可以自動(dòng)化分析大量固件解碼狀態(tài); 面向固件系統(tǒng)、結(jié)構(gòu)、支持硬件不同等問題, 提出了基于獲取規(guī)則的方法來自動(dòng)化發(fā)現(xiàn)和標(biāo)注IoT設(shè)備的類型、供應(yīng)商和型號[96], 和基于自然語言處理來分析網(wǎng)頁內(nèi)容識別設(shè)備指紋的方法[97], 方便其他學(xué)者獲取固件詳細(xì)信息; 還提出了基于自然語言處理分析網(wǎng)絡(luò)上的缺陷報(bào)告來理解物聯(lián)網(wǎng)設(shè)備被攻擊的原因, 并協(xié)助抵抗攻擊[98]。文獻(xiàn)[99]對固件獲取、固件格式分析、固件程序提取、目標(biāo)程序分析提取、程序表示技術(shù)、執(zhí)行信息恢復(fù)技術(shù)等進(jìn)行了綜述。

4 未來研究方向

隨著嵌入式設(shè)備數(shù)量呈爆炸式增長, 學(xué)術(shù)界和工業(yè)界逐漸將更多的精力投入到嵌入式設(shè)備的安全中來。固件作為嵌入式設(shè)備的軟件系統(tǒng), 其安全性對嵌入式設(shè)備的重要不言而喻, 雖然目前對固件安全的研究在不斷地增多, 但在許多方面仍有欠缺。其中, 靜態(tài)分析技術(shù)本身具有一些缺陷, 如可擴(kuò)展性差、誤報(bào)較高等, 在分析中無法應(yīng)對代碼行數(shù)較多的項(xiàng)目, 但是隨著邊緣計(jì)算的興起, 固件中的代碼行數(shù)會(huì)成倍增長, 靜態(tài)分析的應(yīng)用將會(huì)有些困難, 許多固件存在混淆機(jī)制, 給反編譯工作造成了一定的阻礙; 目前的符號執(zhí)行技術(shù)已可以直接使用二進(jìn)制可執(zhí)行文件作為輸入, 但是仍需對不同的架構(gòu)進(jìn)行定制, 可擴(kuò)展性仍受到阻礙; 模糊測試可以分為在真實(shí)硬件上運(yùn)行和在模擬器中運(yùn)行, 在真實(shí)硬件上執(zhí)行要面對的問題是真實(shí)硬件上的資源有限, 無法獲取足夠多固件運(yùn)行時(shí)信息, 在模擬器中運(yùn)行要面臨的問題是目前的模擬器還無法完美的模擬硬件的真實(shí)狀態(tài), 外設(shè)的輸入無法正確給出, 因此無法很好的對固件進(jìn)行測試; 程序驗(yàn)證在軟件安全中起著至關(guān)重要的作用, 重大的項(xiàng)目只有通過了程序驗(yàn)證才可發(fā)布, 但是程序驗(yàn)證較為繁瑣, 可處理的代碼量較少, 模型在面對異構(gòu)的固件時(shí)可擴(kuò)展性較差; 基于機(jī)器學(xué)習(xí)的檢測技術(shù)近幾年來在安全領(lǐng)域一直是一個(gè)熱點(diǎn), 這一方法不受軟件平臺(tái)、架構(gòu)的限制, 難點(diǎn)在于如何為代碼進(jìn)行建模、提取代碼特征、如何選擇機(jī)器學(xué)習(xí)算法, 在普通軟件安全領(lǐng)域成熟的檢測手段在固件測試中應(yīng)該也可以使用, 但基于機(jī)器學(xué)習(xí)的測試方法誤差會(huì)較高。

5G技術(shù)的發(fā)展將會(huì)使得聯(lián)網(wǎng)設(shè)備數(shù)量井噴式發(fā)展, 嵌入式設(shè)備的安全問題亟待解決, 本文對未來的可以進(jìn)一步探索的研究方向進(jìn)行了總結(jié)。

4.1 面向固件缺陷檢測評估的海量缺陷固件測試基準(zhǔn)構(gòu)建

由于固件種類豐富, 其運(yùn)行的平臺(tái)、架構(gòu)等千變?nèi)f化, 目前仍沒有工具可以對多個(gè)種類的固件進(jìn)行測試, 通常是針對某一類型或者某一架構(gòu)的固件進(jìn)行測試, 因此在測試中學(xué)者會(huì)自己構(gòu)建方便自己實(shí)驗(yàn)使用的測試集, 到目前為止仍沒有一個(gè)通用的測試基準(zhǔn)可供大家使用。未來可以構(gòu)造這樣一個(gè)測試基準(zhǔn), 包含不同架構(gòu)、不同類型的固件, 且固件中可植入不同類型的缺陷。測試基準(zhǔn)的構(gòu)建將有助于學(xué)術(shù)人員的實(shí)驗(yàn), 也有助于不同工具的比較。

4.2 擺脫設(shè)備依賴的固件仿真運(yùn)行環(huán)境構(gòu)建

隨著QEMU性能的不斷提高、對不同固件的適配性不斷增強(qiáng), 在虛擬機(jī)中對固件進(jìn)行模糊測試變得可行, 但是當(dāng)前的模擬執(zhí)行環(huán)境仍存在一定的局限性, 如對外設(shè)的模擬能力有限, 對硬件架構(gòu)類型的支持有限等。雖然當(dāng)前已有方法來緩解這一局限, 但仍不足以解決商用設(shè)備中外設(shè)種類多、硬件架構(gòu)復(fù)雜等導(dǎo)致無法在仿真環(huán)境中運(yùn)行的難題。未來研究可以著眼于固件仿真能力的提高, 覆蓋更多的外設(shè)類型和硬件架構(gòu), 提高對商用物聯(lián)網(wǎng)設(shè)備固件的仿真能力。

4.3 數(shù)據(jù)驅(qū)動(dòng)的固件漏洞預(yù)測與目標(biāo)制導(dǎo)模糊測試技術(shù)

隨著代碼規(guī)模的不斷攀升, 固件類型與應(yīng)用場景的不斷多樣化, 以及漏洞類型與特征的不斷復(fù)雜 化, 傳統(tǒng)依賴于人工機(jī)理分析確定漏洞檢測規(guī)則的靜態(tài)分析方法在實(shí)際的應(yīng)用擴(kuò)展性方面面臨挑戰(zhàn)。隨著大數(shù)據(jù)技術(shù)、人工智能技術(shù)的不斷進(jìn)步, 如何有效利用智能化技術(shù), 通過挖掘已有海量代碼中的漏洞信息、結(jié)構(gòu)特征、語義特征、代碼修復(fù)、更新信息, 形成智能化的漏洞預(yù)測模型, 實(shí)現(xiàn)自動(dòng)化生成漏洞檢測規(guī)則, 進(jìn)而高效地預(yù)測潛在漏洞, 并為后續(xù)目標(biāo)制導(dǎo)的模糊測試提供制導(dǎo)目標(biāo)是未來值得研究的方向之一。

4.4 面向配置缺陷檢測的測試用例生成技術(shù)

近年來配置缺陷的不斷發(fā)生引起了許多學(xué)者的注意, 固件中的配置缺陷同樣不容忽視。針對普通軟件領(lǐng)域的配置缺陷使用人工智能技術(shù)輔助識別取得了很好的效果, 但目前的研究僅停留在檢測一些淺顯的缺陷上, 如拼寫錯(cuò)誤、類型錯(cuò)誤等。進(jìn)行合理配置同固件的應(yīng)用環(huán)境有著強(qiáng)烈的聯(lián)系, 但現(xiàn)有的工作對外界環(huán)境的考慮較少, 因此還需將固件的應(yīng)用環(huán)境進(jìn)行建模分析; 其次使用機(jī)器學(xué)習(xí)對配置缺陷進(jìn)行檢測需要大量的學(xué)習(xí)數(shù)據(jù), 但通常針對某一特定領(lǐng)域或者將固件部署在新的平臺(tái)上時(shí)無法獲取大量數(shù)據(jù)用于訓(xùn)練。未來的研究可以將機(jī)器學(xué)習(xí)技術(shù)應(yīng)用于輔助靜態(tài)分析和動(dòng)態(tài)分析, 對分析過程中的一些程序特征進(jìn)行特征提取, 運(yùn)用機(jī)器學(xué)習(xí)技術(shù)進(jìn)行進(jìn)一步分析。

4.5 面向定制化缺陷的分析與檢測框架

定制化缺陷來自于用戶, 是用戶在使用過程中對固件的不當(dāng)定制造成的, 用戶在使用過程中無法獲取對固件代碼的完全理解, 這一缺陷的檢測與修復(fù)缺乏固件開發(fā)人員的支持, 因此如果可以有工具來輔助用戶對定制化的固件代碼進(jìn)行缺陷檢測, 則可以大大提高固件的可擴(kuò)展性。定制化缺陷的檢測無需對整個(gè)固件程序進(jìn)行重新測試, 只需對定制化部分測試即可, 但目前尚未出現(xiàn)這一方向的研究工作, 未來可在這一方向做出拓展。

5 總結(jié)

本文針對物聯(lián)網(wǎng)設(shè)備固件中潛在的安全缺陷, 首先概述了典型的固件缺陷類型以及產(chǎn)生機(jī)理, 包括內(nèi)存損壞、命令注入、程序邏輯、并發(fā)等實(shí)現(xiàn)缺陷和配置缺陷以及定制缺陷。接著, 從靜態(tài)分析、符號執(zhí)行、模糊測試、程序驗(yàn)證、基于機(jī)器學(xué)習(xí)五個(gè)技術(shù)角度對現(xiàn)有固件缺陷檢測方法進(jìn)行了分析與比較。然后, 針對研究現(xiàn)狀存在的不足, 提出了未來可以探索的研究方向, 主要包括面向固件缺陷檢測評估的海量缺陷固件測試基準(zhǔn)構(gòu)建、擺脫設(shè)備依賴的固件仿真運(yùn)行環(huán)境構(gòu)建、數(shù)據(jù)驅(qū)動(dòng)的固件漏洞預(yù)測與目標(biāo)制導(dǎo)模糊測試技術(shù)、面向配置缺陷檢測的測試用例生成技術(shù)和面向定制化缺陷的分析與檢測框架。