• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

      面向物聯(lián)網(wǎng)設(shè)備安全的多層次內(nèi)核訪問控制方法

      2022-12-16 10:18:24詹東陽俞兆豐張宏莉
      信息安全學(xué)報(bào) 2022年6期
      關(guān)鍵詞:訪問控制內(nèi)核調(diào)用

      詹東陽, 俞兆豐, 葉 麟, 張宏莉

      1哈爾濱工業(yè)大學(xué)網(wǎng)絡(luò)空間安全學(xué)院 哈爾濱 中國(guó) 150001

      1 引言

      近年來, 物聯(lián)網(wǎng)快速發(fā)展, 已經(jīng)成為最重要的計(jì)算平臺(tái)之一, 大量的物聯(lián)網(wǎng)設(shè)備被部署在多種應(yīng)用場(chǎng)景下, 如工業(yè)互聯(lián)網(wǎng)、無線傳感器網(wǎng)絡(luò)、智能家居等[1]。然而, 物聯(lián)網(wǎng)設(shè)備的計(jì)算能力通常較弱, 而且對(duì)能耗有較高的要求, 導(dǎo)致了物聯(lián)網(wǎng)系統(tǒng)通常以較輕量化的配置運(yùn)行, 使其安全能力較弱[1-2]。此外,物聯(lián)網(wǎng)系統(tǒng)內(nèi)運(yùn)行的安全保護(hù)程序同樣受到計(jì)算能力和能耗等因素影響, 安全保護(hù)能力受到限制[3]。

      在安全保護(hù)能力較弱的環(huán)境下, 保護(hù)物聯(lián)網(wǎng)設(shè)備的操作系統(tǒng)十分重要[4]。系統(tǒng)調(diào)用是用戶空間程序與操作系統(tǒng)之間最大的接觸面, 用戶空間程序能夠利用大量系統(tǒng)調(diào)用中的漏洞(如CVE-2017-7308、CVE-2017-5123等)攻擊操作系統(tǒng), 以實(shí)現(xiàn)進(jìn)一步的權(quán)限提升等攻擊[5]。因此, 隔離物聯(lián)網(wǎng)設(shè)備中的應(yīng)用程序與操作系統(tǒng)是增強(qiáng)物聯(lián)網(wǎng)系統(tǒng)安全的重要部分。

      Linux Seccomp能夠用于增強(qiáng)應(yīng)用與操作系統(tǒng)之間的隔離性, 它是Linux內(nèi)核的一個(gè)安全模塊, 能夠阻止應(yīng)用程序訪問的系統(tǒng)調(diào)用類別?;赟eccomp限制用戶態(tài)程序僅能訪問其運(yùn)行依賴的必要系統(tǒng)調(diào)用, 可以防止其他系統(tǒng)調(diào)用中包含的漏洞被利用,從而提升內(nèi)核的隔離能力。Eclipse IoT開發(fā)者調(diào)查報(bào)告表明Linux是目前最流行的物聯(lián)網(wǎng)設(shè)備操作系統(tǒng)[6],因此, Seccomp經(jīng)常被用于增強(qiáng)物聯(lián)網(wǎng)設(shè)備中操作系統(tǒng)的隔離能力[7]。此外, Seccomp是Linux內(nèi)核中的內(nèi)嵌模塊, 通常引入的開銷較低, 能夠滿足物聯(lián)網(wǎng)設(shè)備的性能需求[5]。

      現(xiàn)有的分析程序運(yùn)行所依賴系統(tǒng)調(diào)用的方法通常分為動(dòng)態(tài)跟蹤以及靜態(tài)分析兩類。動(dòng)態(tài)跟蹤方法通常跟蹤并收集目標(biāo)程序在執(zhí)行過程中觸發(fā)的系統(tǒng)調(diào)用, 基于已觸發(fā)的系統(tǒng)集合構(gòu)建目標(biāo)程序運(yùn)行依賴的系統(tǒng)調(diào)用庫(kù)[8-10]。然而, 動(dòng)態(tài)執(zhí)行無法遍歷目標(biāo)程序所有的執(zhí)行路徑, 因此會(huì)導(dǎo)致動(dòng)態(tài)收集的依賴系統(tǒng)調(diào)用集合不全, 以此為依據(jù)生成的Seccomp訪問規(guī)則由于可能會(huì)缺乏必要的系統(tǒng)調(diào)用而影響目標(biāo)程序的正常運(yùn)行。絕大多數(shù)程序是通過動(dòng)態(tài)鏈接庫(kù)(如: glibc等)觸發(fā)系統(tǒng)調(diào)用的, 基于靜態(tài)分析的方法通常分析目標(biāo)程序的代碼或者二進(jìn)制文件, 識(shí)別其依賴的動(dòng)態(tài)鏈接庫(kù)API, 之后建立動(dòng)態(tài)鏈接庫(kù)API到系統(tǒng)調(diào)用的映射, 從而分析程序依賴的系統(tǒng)調(diào)用集合[11-14]。然而, 受到控制流分析過程中間接跳轉(zhuǎn)分析精度較差的影響, 靜態(tài)分析方法僅能構(gòu)建動(dòng)態(tài)鏈接庫(kù)中API到系統(tǒng)調(diào)用的超集, 導(dǎo)致得到的依賴系統(tǒng)調(diào)用集合中存在無關(guān)的系統(tǒng)調(diào)用, 使得訪問控制不夠精準(zhǔn), 無法最大化隔離操作系統(tǒng)。綜上, 現(xiàn)有的系統(tǒng)調(diào)用依賴分析方法面臨著可用性以及精準(zhǔn)度的問題。針對(duì)這個(gè)問題, 文獻(xiàn)[5]在靜態(tài)分析的基礎(chǔ)上動(dòng)態(tài)驗(yàn)證動(dòng)態(tài)鏈接庫(kù)中涉及間接跳轉(zhuǎn)的執(zhí)行路徑的安全性, 在一定程度上解決了間接跳轉(zhuǎn)分析不準(zhǔn)確引入無關(guān)系統(tǒng)調(diào)用問題。然而, 該方法依然面臨著性能開銷以及全面性的問題。

      為了實(shí)現(xiàn)物聯(lián)網(wǎng)環(huán)境下高效精準(zhǔn)的內(nèi)核訪問控制, 本文提出一種多層次的內(nèi)核訪問控制方法, 通過分別在動(dòng)態(tài)鏈接庫(kù)以及系統(tǒng)調(diào)用兩個(gè)層次構(gòu)建關(guān)聯(lián)化的訪問控制機(jī)制, 不僅能對(duì)系統(tǒng)調(diào)用進(jìn)行訪問控制, 而且能夠限制程序訪問的動(dòng)態(tài)鏈接庫(kù)的API以及函數(shù), 提升對(duì)內(nèi)核系統(tǒng)調(diào)用的攻擊難度。首先,研究面向glibc等動(dòng)態(tài)鏈接庫(kù)的高效的控制流分析技術(shù), 分析動(dòng)態(tài)鏈接庫(kù)中的控制流圖, 并構(gòu)建API到系統(tǒng)調(diào)用的映射。之后, 分析目標(biāo)程序依賴的動(dòng)態(tài)鏈接庫(kù)API集合, 從而基于API到系統(tǒng)調(diào)用映射分析出程序運(yùn)行所依賴的系統(tǒng)調(diào)用集合, 并生成Seccomp配置, 在系統(tǒng)調(diào)用層面實(shí)現(xiàn)訪問控制。此外, 基于依賴的API集合以及控制流圖刪除靜態(tài)鏈接庫(kù)中無用的API以及函數(shù), 在動(dòng)態(tài)鏈接庫(kù)層面實(shí)現(xiàn)訪問控制, 使攻擊者無法利用無用的代碼實(shí)現(xiàn)內(nèi)核攻擊。最后, 構(gòu)建高效的動(dòng)態(tài)分析機(jī)制, 實(shí)現(xiàn)關(guān)聯(lián)化的訪問控制。對(duì)于允許執(zhí)行的系統(tǒng)調(diào)用, 在內(nèi)核系統(tǒng)調(diào)用入口基于用戶棧還原對(duì)應(yīng)的動(dòng)態(tài)鏈接庫(kù)API和棧深度, 并匹配系統(tǒng)調(diào)用以及API的關(guān)聯(lián)性, 從而識(shí)別并阻斷非程序邏輯觸發(fā)的系統(tǒng)調(diào)用。

      本方法從應(yīng)用的動(dòng)態(tài)鏈接層以及系統(tǒng)調(diào)用層兩個(gè)層次對(duì)應(yīng)用進(jìn)行內(nèi)核訪問控制, 并且引入了動(dòng)態(tài)分析方法進(jìn)行兩個(gè)層次的關(guān)聯(lián)化訪問控制。相較于現(xiàn)有的僅包含系統(tǒng)調(diào)用的內(nèi)核訪問控制方法, 本方法能夠在不同的層次上抵御更多面向操作系統(tǒng)內(nèi)核的安全威脅。首先, 通過引入動(dòng)態(tài)鏈接庫(kù)層次的訪問控制, 攻擊者無法利用動(dòng)態(tài)鏈接庫(kù)中無用代碼觸發(fā)系統(tǒng)調(diào)用, 增加了實(shí)現(xiàn)攻擊的難度, 并且緩解了動(dòng)態(tài)鏈接庫(kù)中無用代碼引發(fā)的漏洞。此外, 通過基于動(dòng)態(tài)分析的多層關(guān)聯(lián)訪問控制, 能夠排除由于靜態(tài)分析不準(zhǔn)確引入的額外系統(tǒng)調(diào)用。靜態(tài)分析引入的額外系統(tǒng)調(diào)用在實(shí)際執(zhí)行中是不存在相應(yīng)路徑的, 因此通過關(guān)聯(lián)匹配API和系統(tǒng)調(diào)用, 能夠識(shí)別程序?qū)嶋H執(zhí)行過程中API與系統(tǒng)調(diào)用與分析得到的安全規(guī)則不相符的情況, 從而識(shí)別惡意調(diào)用路徑。而且, 相比于文獻(xiàn)[5]分析執(zhí)行路徑中的全部函數(shù), 本方法僅動(dòng)態(tài)分析API以及調(diào)用點(diǎn)的安全性, 因此引入的負(fù)載更低。

      本文的主要貢獻(xiàn)包括4個(gè)方面:

      1) 提出了一種多層次的內(nèi)核訪問控制方法, 通過分別在動(dòng)態(tài)鏈接庫(kù)以及系統(tǒng)調(diào)用兩個(gè)層次構(gòu)建關(guān)聯(lián)化的訪問控制機(jī)制, 提升用戶態(tài)程序?qū)?nèi)核的攻擊難度;

      2) 提出了一種適用于物聯(lián)網(wǎng)應(yīng)用的動(dòng)態(tài)鏈接庫(kù)無用API和代碼縮減方法, 在系統(tǒng)調(diào)用訪問控制的基礎(chǔ)上, 使攻擊者無法利用無用的代碼實(shí)現(xiàn)攻擊;

      3) 通過動(dòng)態(tài)分析系統(tǒng)調(diào)用與API的對(duì)應(yīng)關(guān)系以及棧深度, 高效地驗(yàn)證了系統(tǒng)調(diào)用觸發(fā)路徑的安全性, 阻止了靜態(tài)分析引入的額外系統(tǒng)調(diào)用以及由無用動(dòng)態(tài)鏈接庫(kù)代碼觸發(fā)的系統(tǒng)調(diào)用;

      4) 對(duì)原型系統(tǒng)進(jìn)行了有效性和性能測(cè)試, 實(shí)驗(yàn)結(jié)果表明系統(tǒng)能夠在保證程序正常運(yùn)行的前提下,有效阻止無用系統(tǒng)調(diào)用的訪問, 并且能夠阻止物聯(lián)網(wǎng)設(shè)備中大量潛在漏洞。

      2 相關(guān)工作

      隨著物聯(lián)網(wǎng)的快速發(fā)展, 物聯(lián)網(wǎng)安全被越來越多的研究者關(guān)注[15-18]。物聯(lián)網(wǎng)設(shè)備有限的硬件資源是物聯(lián)網(wǎng)設(shè)備更容易受到攻擊的主要原因之一, 因此許多研究關(guān)注于保護(hù)物聯(lián)網(wǎng)系統(tǒng)安全[19-20]。物聯(lián)網(wǎng)設(shè)備中的程序通常是由低層次編程語言(如:C/C++語言)編寫, 由于這類語言不具備完善的安全檢查、異常處理等機(jī)制, 編寫者可能由于疏忽引入一些漏洞(如: 緩沖區(qū)溢出、內(nèi)存泄露等)[21]。由于硬件資源有限, 物聯(lián)網(wǎng)設(shè)備通常缺乏必要的動(dòng)態(tài)系統(tǒng)防御措施(如控制流完整性檢測(cè)等), 這使得攻擊者更容易利用漏洞。大量研究指出代碼注入攻擊導(dǎo)致的漏洞常見于物聯(lián)網(wǎng)固件[19-20], 通過篡改函數(shù)返回地址劫持物聯(lián)網(wǎng)應(yīng)用的控制流仍然是物聯(lián)網(wǎng)應(yīng)用面臨的主要威脅[22-23]。在這種背景下, 攻擊者更容易觸發(fā)操作系統(tǒng)中系統(tǒng)調(diào)用包含的漏洞, 從而攻擊操作系統(tǒng)。

      為了保護(hù)操作系統(tǒng), 大量研究基于Linux Seccomp阻止應(yīng)用程序訪問與其運(yùn)行無關(guān)的系統(tǒng)調(diào)用,從而防止其他系統(tǒng)調(diào)用中包含的漏洞被利用, 提升內(nèi)核的隔離能力[8-14]。Linux Seccomp是Linux操作系統(tǒng)內(nèi)嵌的用于限制系統(tǒng)調(diào)用的安全模塊, 通常引入的實(shí)時(shí)開銷較低, 能夠滿足物聯(lián)網(wǎng)設(shè)備的性能需求[5,7]。

      為了獲取目標(biāo)程序運(yùn)行依賴的必要系統(tǒng)調(diào)用,動(dòng)態(tài)跟蹤方法通常跟蹤并分析目標(biāo)程序的執(zhí)行過程[8-10]。文獻(xiàn)[24]將程序的執(zhí)行過程分為初始化階段和服務(wù)階段, 通常這兩個(gè)階段依賴的系統(tǒng)調(diào)用是不同的, 需在程序運(yùn)行的不同階段采用不同的系統(tǒng)調(diào)用訪問控制策略。然而, 動(dòng)態(tài)跟蹤通常無法覆蓋目標(biāo)程序的所有執(zhí)行路徑, 導(dǎo)致收集到的系統(tǒng)調(diào)用不全。靜態(tài)分析的方法通常構(gòu)建動(dòng)態(tài)鏈接庫(kù)(如: glibc等)的控制流圖, 并基于控制流圖生成API到系統(tǒng)調(diào)用的映射, 從而根據(jù)目標(biāo)程序調(diào)用的API分析其依賴的系統(tǒng)調(diào)用集合[11-14]。然而, 靜態(tài)分析由于缺乏動(dòng)態(tài)執(zhí)行信息無法精準(zhǔn)地獲取間接跳轉(zhuǎn)的目標(biāo)函數(shù), 僅能獲取其超集, 導(dǎo)致控制流圖會(huì)包含實(shí)際不存在的函數(shù)調(diào)用關(guān)系, 進(jìn)而導(dǎo)致API到系統(tǒng)調(diào)用的映射中存在無關(guān)的系統(tǒng)調(diào)用, 存在精準(zhǔn)度不足的問題。綜上,現(xiàn)有的系統(tǒng)調(diào)用依賴分析方法面臨著可用性以及精準(zhǔn)度的問題。

      針對(duì)這個(gè)問題, 文獻(xiàn)[5]在靜態(tài)分析的基礎(chǔ)上動(dòng)態(tài)驗(yàn)證動(dòng)態(tài)鏈接庫(kù)中涉及間接跳轉(zhuǎn)的執(zhí)行路徑的安全性。靜態(tài)分析中間接跳轉(zhuǎn)引入的額外路徑在真實(shí)執(zhí)行環(huán)境中是不存在的, 通過動(dòng)態(tài)驗(yàn)證能夠還原系統(tǒng)調(diào)用的觸發(fā)路徑, 如果該路徑與靜態(tài)分析中路徑相符, 則說明該系統(tǒng)調(diào)用是程序真實(shí)依賴的。相反,當(dāng)攻擊者調(diào)用間接跳轉(zhuǎn)引入的額外系統(tǒng)調(diào)用時(shí), 其在動(dòng)態(tài)鏈接庫(kù)中的執(zhí)行路徑是靜態(tài)分析中不存在的。然而, 該方法依然面臨著性能開銷以及分析全面性方面的問題。首先, 該方法在系統(tǒng)調(diào)用內(nèi)核入口處恢復(fù)觸發(fā)系統(tǒng)調(diào)用的動(dòng)態(tài)鏈接庫(kù)中全部的函數(shù)執(zhí)行路徑并驗(yàn)證其安全性, 這對(duì)于物聯(lián)網(wǎng)設(shè)備來說性能開銷較大。其次, 該方法未對(duì)動(dòng)態(tài)鏈接庫(kù)API進(jìn)行限制, 導(dǎo)致攻擊者能夠利用整個(gè)鏈接庫(kù)中的代碼實(shí)現(xiàn)各種攻擊, 并且可以不按照程序的執(zhí)行邏輯觸發(fā)系統(tǒng)調(diào)用。例如, 當(dāng)動(dòng)態(tài)鏈接庫(kù)中存在一條真實(shí)可行的執(zhí)行路徑可訪問由間接跳轉(zhuǎn)引入的額外系統(tǒng)調(diào)用時(shí),攻擊者能夠利用緩沖區(qū)溢出、ROP等漏洞執(zhí)行該路徑從而觸發(fā)相應(yīng)系統(tǒng)調(diào)用。而該調(diào)用已經(jīng)由間接跳轉(zhuǎn)分析引入了允許的系統(tǒng)調(diào)用集合, 并且動(dòng)態(tài)鏈接庫(kù)中觸發(fā)該系統(tǒng)調(diào)用的執(zhí)行路徑也是真實(shí)存在的,因此, 系統(tǒng)無法識(shí)別這類攻擊。

      限制程序可訪問的動(dòng)態(tài)鏈接庫(kù)代碼也是提高程序安全性的重要方法之一, 通過重新設(shè)計(jì)或編寫動(dòng)態(tài)鏈接庫(kù), 能夠防止攻擊者利用動(dòng)態(tài)鏈接庫(kù)中的無用代碼。Piece-wise Debloating[25]只加載必要的動(dòng)態(tài)鏈接庫(kù)并用空代碼替換運(yùn)行無關(guān)的部分。Nibbler[26]通過分析目標(biāo)應(yīng)用程序的函數(shù)調(diào)用圖刪除未使用的代碼。LibFilter[27]刪除動(dòng)態(tài)鏈接庫(kù)中未使用的函數(shù)。但是, 這類方法沒有限制系統(tǒng)調(diào)用的類別, 導(dǎo)致攻擊者可能通過引入新的動(dòng)態(tài)鏈接庫(kù)或者直接利用匯編代碼對(duì)操作系統(tǒng)進(jìn)行攻擊。

      綜上, 現(xiàn)有的內(nèi)核訪問控制方法普遍面臨著可用性、精準(zhǔn)度、性能等方面的問題, 因此研究精準(zhǔn)高效的內(nèi)核訪問控制方法是十分必要的。

      3 多層次的內(nèi)核訪問控制方法

      3.1 系統(tǒng)概述

      本文研究一種多層次的內(nèi)核訪問控制方法, 分別在目標(biāo)程序的動(dòng)態(tài)鏈接庫(kù)層和系統(tǒng)調(diào)用層進(jìn)行內(nèi)核訪問控制, 以提升物聯(lián)網(wǎng)操作系統(tǒng)的安全性。系統(tǒng)架構(gòu)如圖1所示。首先, 對(duì)目標(biāo)程序進(jìn)行靜態(tài)程序分析, 從而獲取其依賴的動(dòng)態(tài)鏈接庫(kù)種類、API以及通過匯編指令直接觸發(fā)的系統(tǒng)調(diào)用集合。第二步, 構(gòu)建動(dòng)態(tài)鏈接庫(kù)的控制流圖并分析其中API和系統(tǒng)調(diào)用的映射關(guān)系, 從而生成目標(biāo)程序依賴的系統(tǒng)調(diào)用集合。之后, 基于動(dòng)態(tài)鏈接庫(kù)的控制流圖以及目標(biāo)程序依賴的動(dòng)態(tài)鏈接庫(kù)API, 消除動(dòng)態(tài)鏈接庫(kù)中的無用代碼, 從而實(shí)現(xiàn)動(dòng)態(tài)鏈接庫(kù)層次的內(nèi)核訪問控制。最后, 基于目標(biāo)程序依賴的系統(tǒng)調(diào)用集合生成相應(yīng)的系統(tǒng)調(diào)用訪問控制策略。引入動(dòng)態(tài)分析機(jī)制, 在系統(tǒng)調(diào)用訪問時(shí), 動(dòng)態(tài)分析觸發(fā)系統(tǒng)調(diào)用的API與系統(tǒng)調(diào)用的對(duì)應(yīng)關(guān)系, 從而分析動(dòng)態(tài)鏈接庫(kù)執(zhí)行路徑的安全性, 發(fā)現(xiàn)動(dòng)態(tài)鏈接庫(kù)中的代碼濫用問題。

      圖1 系統(tǒng)架構(gòu)圖Figure 1 System architecture

      3.2 目標(biāo)程序分析

      為了獲取目標(biāo)程序依賴的動(dòng)態(tài)鏈接庫(kù)以及API的集合, 分析目標(biāo)程序的二進(jìn)制可執(zhí)行文件。首先,通過讀取并分析可行性程序的ELF文件, 能夠獲取其依賴的動(dòng)態(tài)鏈接庫(kù)列表。之后分析二進(jìn)制文件識(shí)別用于觸發(fā)系統(tǒng)調(diào)用的匯編指令, 從而發(fā)現(xiàn)利用內(nèi)聯(lián)匯編直接觸發(fā)的系統(tǒng)調(diào)用。

      大部分程序通過動(dòng)態(tài)鏈接庫(kù)(如, glibc)觸發(fā)系統(tǒng)調(diào)用, 本文在獲取了動(dòng)態(tài)鏈接庫(kù)種類的基礎(chǔ)上識(shí)別二進(jìn)制文件中各類動(dòng)態(tài)鏈接庫(kù)的API。通常, 對(duì)動(dòng)態(tài)鏈接庫(kù)API函數(shù)的訪問可以通過二進(jìn)制文件中的注釋來識(shí)別, 例如glibc的API通常在目標(biāo)程序中被標(biāo)記為"<API_name@@GLIBC__version>"。因此, 在反匯編二進(jìn)制文件后可以通過注釋以及函數(shù)名識(shí)別各API。

      當(dāng)二進(jìn)制文件通過內(nèi)嵌匯編代碼直接訪問系統(tǒng)調(diào)用時(shí), 本文分析其匯編代碼中系統(tǒng)調(diào)用部分識(shí)別其訪問的系統(tǒng)調(diào)類別。具體的, ARM處理器采用SVC指令實(shí)現(xiàn)系統(tǒng)調(diào)用的訪問機(jī)制, 系統(tǒng)調(diào)用號(hào)采用R7寄存器傳遞。為了通過靜態(tài)分析識(shí)別系統(tǒng)調(diào)用號(hào), 本文從系統(tǒng)調(diào)用指令開始, 采用文獻(xiàn)[28]中靜態(tài)污點(diǎn)分析的思想向前查找R7寄存器的數(shù)值來源。即將R7寄存器標(biāo)記為污點(diǎn)數(shù)據(jù), 當(dāng)有寄存器或內(nèi)存向其傳遞數(shù)據(jù)時(shí), 該寄存器或內(nèi)存也被標(biāo)記為污點(diǎn)數(shù)據(jù),當(dāng)數(shù)據(jù)來源是一個(gè)常量時(shí)污點(diǎn)分析結(jié)束, 該常量為系統(tǒng)調(diào)用號(hào)。最后, 將系統(tǒng)調(diào)用號(hào)與系統(tǒng)調(diào)用名相對(duì)應(yīng), 得到程序觸發(fā)的系統(tǒng)調(diào)用類別。

      3.3 構(gòu)建API到系統(tǒng)調(diào)用的映射

      本文基于源代碼分析利用編譯器輔助構(gòu)建動(dòng)態(tài)鏈接庫(kù)的控制流圖。由于glibc不支持LLVM編譯器,本文利用gcc的編譯中間文件(如, cgraph文件以及cfg文件)分析控制流圖。cgraph文件記錄了源代碼中的符號(hào)信息, 包括: 類型(如變量、外部函數(shù)、函數(shù)定義、函數(shù)別名等)、函數(shù)間調(diào)用關(guān)系等信息, 可以據(jù)此建立函數(shù)別名和函數(shù)調(diào)用關(guān)系。而且cgraph文件同樣定義了函數(shù)別名的對(duì)應(yīng)關(guān)系, 基于函數(shù)間調(diào)用關(guān)系以及函數(shù)別名關(guān)系, 能夠構(gòu)建函數(shù)之間的直接調(diào)用圖。

      本文采用文獻(xiàn)[29]的多層間接調(diào)用分析思想分析函數(shù)間的間接調(diào)用關(guān)系。首先, 識(shí)別源代碼中的address-taken函數(shù), 即函數(shù)的地址曾被保存于某些結(jié)構(gòu)體的函數(shù), 這些函數(shù)可能是間接調(diào)用的目標(biāo)函數(shù)。之后, 分析間接調(diào)用的參數(shù)數(shù)量、類型以及返回值的類型, 并與address-taken函數(shù)進(jìn)行比對(duì), 從而識(shí)別與間接調(diào)用點(diǎn)相匹配的address-taken函數(shù), 作為可能的目標(biāo)函數(shù)集合。最后, 基于指針的數(shù)據(jù)傳遞關(guān)系進(jìn)一步排除數(shù)據(jù)無關(guān)的指針, 從而篩選出相關(guān)的目標(biāo)函數(shù)。為此, 本文分析編譯過程生成的cfg文件, 該文件保存了各函數(shù)的控制流圖信息, 通過cfg文件中可以獲取函數(shù)的定義、函數(shù)調(diào)用等信息, 從而識(shí)別函數(shù)調(diào)用的參數(shù)類型、數(shù)量以及返回值類型。通過構(gòu)建并合并直接調(diào)用圖以及間接調(diào)用圖, 能夠生成動(dòng)態(tài)鏈接庫(kù)的完整函數(shù)調(diào)用圖。

      相比于文獻(xiàn)[5]采用二進(jìn)制分析構(gòu)建直接控制流圖, 本文采用的基于編譯器輔助的源代碼分析能夠獲得更豐富的語義, 而且分析結(jié)果可以直接用于后續(xù)的動(dòng)態(tài)鏈接庫(kù)代碼縮減。

      在生成完整函數(shù)調(diào)用圖后, 識(shí)別調(diào)用圖中的API函數(shù)以及觸發(fā)系統(tǒng)調(diào)用的函數(shù)。本文基于動(dòng)態(tài)鏈接庫(kù)介紹文檔構(gòu)建了API函數(shù)名列表, 基于該列表能夠在函數(shù)調(diào)用圖中識(shí)別全部API。本文以glibc為例分析該動(dòng)態(tài)鏈接庫(kù)中的系統(tǒng)調(diào)用觸發(fā)函數(shù)。glibc通常采用匯編指令、編譯過程中嵌入?yún)R編等方式觸發(fā)系統(tǒng)調(diào)用[11]。為此, 本文分析編譯生成的expand文件, 該文件由寄存器傳輸語言(register transfer language, RTL)編寫, 包含了程序的內(nèi)嵌匯編語言。通過分析匯編語言能夠獲取調(diào)用的系統(tǒng)調(diào)用類型。對(duì)于在編譯過程中動(dòng)態(tài)生成的匯編語言, 本文分析此類函數(shù)列表從而獲取函數(shù)與系統(tǒng)調(diào)用的對(duì)應(yīng)關(guān)系。在識(shí)別API以及系統(tǒng)調(diào)用之后, 能夠基于函數(shù)調(diào)用圖分析API可達(dá)的系統(tǒng)調(diào)用, 從而構(gòu)建API與系統(tǒng)調(diào)用的對(duì)應(yīng)關(guān)系。

      3.4 動(dòng)態(tài)鏈接庫(kù)代碼縮減

      本文基于動(dòng)態(tài)鏈接庫(kù)的函數(shù)調(diào)用圖以及目標(biāo)程序所依賴的動(dòng)態(tài)鏈接庫(kù)API, 查找該程序運(yùn)行所依賴的動(dòng)態(tài)鏈接庫(kù)函數(shù), 并將無用函數(shù)刪除, 從而形成定制化的動(dòng)態(tài)鏈接庫(kù)。定制化的動(dòng)態(tài)鏈接庫(kù)只能服務(wù)于特定的應(yīng)用程序, 因此需修改系統(tǒng)中動(dòng)態(tài)鏈接庫(kù)加載器使其能夠?yàn)樘囟ǖ某绦蚣虞d特定的動(dòng)態(tài)鏈接庫(kù)。

      文獻(xiàn)[25]提出了一個(gè)動(dòng)態(tài)鏈接庫(kù)定制化縮減方法, 它在編譯時(shí)分析代碼, 并在生成的二進(jìn)制文件中嵌入函數(shù)依賴的元數(shù)據(jù)。之后修改加載程序, 在動(dòng)態(tài)鏈接庫(kù)加載時(shí)根據(jù)元數(shù)據(jù)覆蓋動(dòng)態(tài)鏈接庫(kù)中未使用的代碼。該方法適合通用的庫(kù)函數(shù)應(yīng)用場(chǎng)景, 而物聯(lián)網(wǎng)設(shè)備的功能通常較為單一, 其內(nèi)部的服務(wù)程序通常是固定的且數(shù)量是有限的。因此, 本文采用的生成定制化動(dòng)態(tài)鏈接庫(kù)的方法在加載器工作過程中不會(huì)因分析函數(shù)級(jí)的依賴關(guān)系產(chǎn)生實(shí)時(shí)負(fù)載。

      3.5 關(guān)聯(lián)化的動(dòng)態(tài)分析機(jī)制

      動(dòng)態(tài)分析模塊在獲取程序的依賴系統(tǒng)調(diào)用后,首先利用Seccomp阻止程序訪問無關(guān)的系統(tǒng)調(diào)用。對(duì)于靜態(tài)分析得到的程序運(yùn)行依賴的必要系統(tǒng)調(diào)用,在Seccomp允許其執(zhí)行的基礎(chǔ)上提出一種動(dòng)態(tài)分析機(jī)制, 分析該系統(tǒng)調(diào)用的安全性。

      基于靜態(tài)分析獲得的系統(tǒng)調(diào)用控制策略面臨兩方面的問題。首先, 間接調(diào)用分析不準(zhǔn)確擴(kuò)大了動(dòng)態(tài)鏈接庫(kù)中API到系統(tǒng)調(diào)用的映射, 引入了無關(guān)系統(tǒng)調(diào)用。其次, 動(dòng)態(tài)鏈接庫(kù)存在多個(gè)API對(duì)應(yīng)同一系統(tǒng)調(diào)用的情況, 程序可能僅依賴某一個(gè)API, 而僅限制系統(tǒng)調(diào)用的種類, 無法識(shí)別該系統(tǒng)調(diào)用是由程序邏輯觸發(fā)的還是由其他非法路徑(如ROP攻擊等)觸發(fā)的。

      為了解決這個(gè)問題, 本文通過在內(nèi)核入口處分析觸發(fā)系統(tǒng)調(diào)用的用戶態(tài)內(nèi)存棧重構(gòu)出動(dòng)態(tài)鏈接庫(kù)中觸發(fā)該系統(tǒng)調(diào)用的執(zhí)行路徑, 進(jìn)而分析其安全性,架構(gòu)圖如圖 2所示。與文獻(xiàn)[5]不同, 本文僅分析觸發(fā)系統(tǒng)調(diào)用的動(dòng)態(tài)鏈接庫(kù)API的種類是否符合API與系統(tǒng)調(diào)用映射以及API是否存在于目標(biāo)程序的依賴API集合中, 來分析路徑的安全性。首先, 僅分析API的完整性降低了動(dòng)態(tài)分析的負(fù)載, 從而更適用于物聯(lián)網(wǎng)設(shè)備內(nèi)。其次, 本文在文獻(xiàn)[5]的基礎(chǔ)上進(jìn)一步驗(yàn)證了API的安全性。

      圖2 動(dòng)態(tài)分析架構(gòu)圖Figure 2 System architecture of dynamic analysis

      為了動(dòng)態(tài)分析路徑的安全性, 需從棧中提取動(dòng)態(tài)鏈接庫(kù)API種類。為此, 需構(gòu)造API函數(shù)與其內(nèi)存地址之間的映射。由于靜態(tài)分析無法獲得動(dòng)態(tài)內(nèi)存位置, 因此本文在重新編譯的動(dòng)態(tài)鏈接庫(kù)中加入元數(shù)據(jù)從而標(biāo)記API, 之后使用自定義的ELF loader在運(yùn)行時(shí)加載對(duì)應(yīng)的動(dòng)態(tài)鏈接庫(kù)并獲得各API的內(nèi)存地址。

      動(dòng)態(tài)分析模塊作為內(nèi)核模塊在各系統(tǒng)調(diào)用入口處分析 Seccomp 允許的系統(tǒng)調(diào)用的安全性。相比于在總的內(nèi)核入口點(diǎn)處攔截, 在系統(tǒng)調(diào)用入口攔截分析的觸發(fā)頻率更低, 性能開銷更小。當(dāng)特定系統(tǒng)調(diào)用被觸發(fā)時(shí), 分析模塊檢查當(dāng)前進(jìn)程是否屬于被監(jiān)控的目標(biāo)進(jìn)程, 如果是則進(jìn)行安全分析。

      3.6 討論與分析

      本文通過分析執(zhí)行過程中動(dòng)態(tài)鏈接庫(kù)API以及棧深度來分析系統(tǒng)調(diào)用路徑的安全性。與僅驗(yàn)證系統(tǒng)調(diào)用類別的方法相比, 本文提出的方法提升了攻擊的難度。但是攻擊者可能會(huì)篡改整個(gè)用戶棧來躲避動(dòng)態(tài)分析的檢查。

      然而, 這種攻擊是不易實(shí)現(xiàn)的。首先, 內(nèi)存棧的canary機(jī)制在棧中插入校驗(yàn)位來檢測(cè)棧溢出攻擊。當(dāng)標(biāo)記位被覆蓋時(shí), 程序?qū)⒈唤K止。雖然canary機(jī)制并不完全安全, 但是研究者已經(jīng)提出了大量保護(hù)方法[30], 提升了棧篡改的難度。其次, 動(dòng)態(tài)鏈接庫(kù)是經(jīng)過修改的, 其內(nèi)存分布與通用的動(dòng)態(tài)鏈接庫(kù)完全不同, 因此攻擊者難以基于公開的動(dòng)態(tài)鏈接庫(kù)函數(shù)偏移來偽造正確的返回地址以欺騙動(dòng)態(tài)分析模塊。此外, 縮減的動(dòng)態(tài)鏈接庫(kù)中僅有必要的代碼, 基于這些代碼構(gòu)造ROP攻擊是更加困難的, 而且動(dòng)態(tài)分析模塊能夠發(fā)現(xiàn)程序引入的新動(dòng)態(tài)鏈接庫(kù)。最后, 偽造全部?jī)?nèi)存棧會(huì)影響攻擊控制流。攻擊者通常需要按照一定邏輯調(diào)用一些高權(quán)限的系統(tǒng)調(diào)用或利用一些系統(tǒng)調(diào)用中的漏洞進(jìn)行提權(quán)攻擊, 如果棧被安全的執(zhí)行路徑覆蓋, 控制流將無法返回到相應(yīng)的攻擊路徑, 這可能導(dǎo)致程序崩潰, 攻擊者無法繼續(xù)攻擊。

      因此, 動(dòng)態(tài)分析模塊增強(qiáng)了訪問控制機(jī)制的安全性, 使攻擊更加困難。

      本方法面向物聯(lián)網(wǎng)常用的ARM Linux平臺(tái)設(shè)計(jì),因此在設(shè)計(jì)和實(shí)現(xiàn)上與面向x86架構(gòu)的內(nèi)核訪問控制方法[5,11]有一些差異。首先, 在靜態(tài)分析目標(biāo)程序與動(dòng)態(tài)鏈接庫(kù)代碼以識(shí)別觸發(fā)的系統(tǒng)調(diào)用類別時(shí),由于ARM平臺(tái)的系統(tǒng)調(diào)用機(jī)制與x86不同, 需要單獨(dú)構(gòu)建ARM環(huán)境中系統(tǒng)調(diào)用觸發(fā)代碼的分析過程以及系統(tǒng)調(diào)用名與調(diào)用號(hào)的對(duì)應(yīng)關(guān)系。其次, ARM架構(gòu)下的glibc調(diào)用系統(tǒng)調(diào)用的匯編代碼與傳統(tǒng)x86不同, 需要識(shí)別并分析SVC指令并且識(shí)別相應(yīng)的寄存器數(shù)值。此外, 由于匯編指令不同, 面向x86平臺(tái)的污點(diǎn)分析、控制流構(gòu)建方法不適用于ARM平臺(tái), 需要面向ARM指令集重新設(shè)計(jì)。

      本文通過分析應(yīng)用程序從而生成定制化的動(dòng)態(tài)鏈接庫(kù)以及訪問控制策略, 隨著物聯(lián)網(wǎng)設(shè)備種類的不斷增加, 本方法面臨著易用性和通用性方面的挑戰(zhàn)。首先, 隨著設(shè)備種類的多樣化, 高度定制化程序可能采用不同的動(dòng)態(tài)鏈接庫(kù), 這會(huì)增加本方法的分析復(fù)雜性, 降低易用性; 其次, 很多定制化的傳感器不具有獨(dú)立的操作系統(tǒng), 使得本方法無法直接適用于該類系統(tǒng), 降低了方法的通用性。本文將在未來工作中使本方法適配更多種類的物聯(lián)網(wǎng)設(shè)備和系統(tǒng),提升方法的易用性和通用性。

      4 系統(tǒng)實(shí)現(xiàn)

      本章介紹原型系統(tǒng)實(shí)現(xiàn)中的一些關(guān)鍵細(xì)節(jié)。

      4.1 編譯動(dòng)態(tài)鏈接庫(kù)

      由于glibc不支持Clang/LLVM編譯器, 本文采用gcc編譯glibc。為了生成編譯過程文件, 在編譯的CFLAGS參數(shù)中分別加入-fdump-ipa-cgraph、-fdumprtl-expand、-fdump-tree-cfg等參數(shù), 從而分別生成cgraph、expand和cfg文件。

      4.2 控制流構(gòu)建

      在獲取動(dòng)態(tài)鏈接庫(kù)(如glibc)的編譯中間文件后,需分析其中的程序語義以獲取函數(shù)調(diào)用圖。cgraph文件中每一個(gè)符號(hào)都有兩個(gè)名稱, 本文分別稱為firstname以及secondname。這兩種名稱在構(gòu)建函數(shù)調(diào)用關(guān)系時(shí)會(huì)交替使用。firstname用于References字段和Referring字段, 而secondname用于Calls和Called by字段。使用cgraph文件建立調(diào)用關(guān)系和別名關(guān)系時(shí), 調(diào)用關(guān)系可以直接從Calls字段讀出, 而別名則需要進(jìn)一步處理。對(duì)于一個(gè)符號(hào), 如果它是別名, 需要根據(jù)他的References字段的值尋找它指向的符號(hào), 由于指向的符號(hào)也可能是別名, 所以要遞歸式的查找, 直到遇到一個(gè)函數(shù)定義, 此時(shí)可以將最開始的別名映射到這個(gè)函數(shù)名。

      5 實(shí)驗(yàn)

      在實(shí)現(xiàn)了原型系統(tǒng)后, 本文在ARM Linux平臺(tái)分別測(cè)試了系統(tǒng)的有效性、性能以及漏洞防御能力,并且與現(xiàn)有方法進(jìn)行對(duì)比。本方法的有效性主要體現(xiàn)在通過禁用目標(biāo)程序的內(nèi)核與動(dòng)態(tài)鏈接庫(kù)的代碼訪問, 緩解了禁用代碼中包含的CVE漏洞, 分別在5.1節(jié)和5.3節(jié)進(jìn)行了測(cè)試。本文選擇50個(gè)常用的ARM Linux程序作為分析的目標(biāo)。為此, 本文從文獻(xiàn)[31]的物聯(lián)網(wǎng)固件數(shù)據(jù)集中收集了1000個(gè)ARM固件鏡像, 并利用binwalk和Firmwalker解析鏡像。從解壓后的文件鏡像中, 本文選擇50個(gè)通用的基于glibc的程序進(jìn)行測(cè)試。

      5.1 有效性測(cè)試

      為了測(cè)試系統(tǒng)的有效性, 首先利用靜態(tài)分析獲取的程序依賴系統(tǒng)調(diào)用列表生成相應(yīng)的定制化動(dòng)態(tài)鏈接庫(kù)以及Seccomp配置。分析結(jié)果如圖3所示, 該圖展示了通過靜態(tài)分析為每個(gè)程序禁止的系統(tǒng)調(diào)用的數(shù)量。圖中橫坐標(biāo)是程序的序號(hào), 縱坐標(biāo)是禁止的系統(tǒng)調(diào)用數(shù)量, 平均數(shù)為248.08個(gè)。圖4展示了各程序禁用動(dòng)態(tài)鏈接庫(kù)函數(shù)的數(shù)量, 平均數(shù)為708.64個(gè)。結(jié)果表明, 本方法能夠禁止大量的系統(tǒng)調(diào)用以及動(dòng)態(tài)鏈接庫(kù)的代碼訪問, 縮小系統(tǒng)攻擊面。為了驗(yàn)證靜態(tài)分析的正確性, 實(shí)驗(yàn)將目標(biāo)程序與相應(yīng)的Seccomp配置一一執(zhí)行。實(shí)驗(yàn)發(fā)現(xiàn)所有程序都可以正常執(zhí)行, 這證明了本方法的健壯性。在執(zhí)行過程中, 動(dòng)態(tài)分析模塊分析允許系統(tǒng)調(diào)用的安全性, 平均每個(gè)程序執(zhí)行的系統(tǒng)調(diào)用為14.18個(gè), 說明實(shí)際執(zhí)行的系統(tǒng)調(diào)用數(shù)量遠(yuǎn)小于允許的數(shù)量, 因此通過動(dòng)態(tài)分析進(jìn)一步分析系統(tǒng)調(diào)用的安全性是必要的。

      圖3 各程序禁止系統(tǒng)調(diào)用數(shù)量Figure 3 The number of syscall limitation of each program

      圖4 各程序禁止動(dòng)態(tài)鏈接庫(kù)函數(shù)的數(shù)量Figure 4 The number of function limitation of each program

      5.2 性能測(cè)試

      動(dòng)態(tài)訪問控制會(huì)給目標(biāo)程序帶來實(shí)時(shí)性能開銷,為了測(cè)量開銷, 實(shí)驗(yàn)首先在沒有訪問控制的情況下運(yùn)行目標(biāo)程序100次, 并記錄執(zhí)行結(jié)果。然后, 在訪問控制下使用相同的輸入對(duì)它們進(jìn)行測(cè)試。實(shí)驗(yàn)選用了LMBench作為測(cè)試的工具, 該工具是一種常用的性能測(cè)試工具, 能夠測(cè)試內(nèi)存、文件等方面的性能。實(shí)驗(yàn)選擇2個(gè)測(cè)試指標(biāo)(內(nèi)存讀寫bw_mem和文件塊I/O bw_file_rd)來測(cè)量開銷, 測(cè)試得到的各指標(biāo)的分?jǐn)?shù)如表1所示。從表中可以看出, 訪問控制對(duì)bw_mem測(cè)試引入的負(fù)載小于1%, bw_file_rd測(cè)試引入的負(fù)載約為3.2%, 說明了本系統(tǒng)引入的實(shí)時(shí)負(fù)載較低。

      sysverify[5]同樣采用了動(dòng)態(tài)驗(yàn)證的方法, 該方法分析了內(nèi)存棧每個(gè)地址的安全性并且重構(gòu)完整的系統(tǒng)調(diào)用觸發(fā)路線。因此, 本文與完整路徑分析的方法進(jìn)行性能對(duì)比。為此, 本文首先實(shí)現(xiàn)了sysverify提出的路徑分析方法。測(cè)試采用了相同的性能測(cè)試工具以及參數(shù)。測(cè)試結(jié)果如表1所示, 完整路徑分析的方法在兩個(gè)測(cè)試中分別引入了約2.8%以及6.7%的實(shí)時(shí)負(fù)載。通過結(jié)果可以發(fā)現(xiàn)本文提出的方法性能優(yōu)于完整路徑分析的性能。原因是完整路徑分析會(huì)對(duì)每個(gè)棧中地址進(jìn)行分析, 并且需要重構(gòu)執(zhí)行路徑, 再與已有路徑庫(kù)進(jìn)行比對(duì); 而本文提出方法僅需要分析API的安全性。此外, 物聯(lián)網(wǎng)設(shè)備由于性能有限,也會(huì)放大性能差異。因此, 本文提出的方法更適用于硬件資源更為有限的物聯(lián)網(wǎng)設(shè)備。

      表1 不同訪問控制的性能對(duì)比Table 1 Performance comparison of different access controls

      靜態(tài)分析主要包含兩部分, 即分析動(dòng)態(tài)鏈接庫(kù)生成API-系統(tǒng)調(diào)用的映射, 以及分析各目標(biāo)應(yīng)用程序依賴的API, 從而生成對(duì)應(yīng)的動(dòng)態(tài)鏈接庫(kù)以及系統(tǒng)調(diào)用訪問控制策略等安全配置。其中, 動(dòng)態(tài)鏈接庫(kù)API-系統(tǒng)調(diào)用映射僅需生成一次, 安全配置需要根據(jù)目標(biāo)程序按需生成。本文在配備Intel i5 2.7 GHz CPU、8G內(nèi)存的計(jì)算機(jī)上分別測(cè)試了靜態(tài)分析2個(gè)階段所需的時(shí)間, 其中生成glibc動(dòng)態(tài)鏈接庫(kù)API-系統(tǒng)調(diào)用映射的時(shí)間10次平均為27min 30s, 生成50個(gè)目標(biāo)程序所需動(dòng)態(tài)鏈接庫(kù)以及安全配置所需時(shí)間平均為16min 28s。由于靜態(tài)分析是離線分析, 不會(huì)對(duì)應(yīng)用程序產(chǎn)生實(shí)時(shí)負(fù)載, 且每個(gè)應(yīng)用僅需分析一次, 因此靜態(tài)分析的性能是可以接受的。

      5.3 漏洞防御能力測(cè)試

      本方法靜態(tài)分析的目標(biāo)是生成程序依賴的動(dòng)態(tài)鏈接庫(kù)API集合、系統(tǒng)調(diào)用集合以及API和系統(tǒng)調(diào)用的映射。本方法能夠基于靜態(tài)分析生成的結(jié)果, 通過對(duì)動(dòng)態(tài)鏈接庫(kù)API和系統(tǒng)調(diào)用的訪問控制阻止包含漏洞的代碼或系統(tǒng)調(diào)用的執(zhí)行, 從而阻止動(dòng)態(tài)鏈接庫(kù)或系統(tǒng)該調(diào)用包含的漏洞(如: CVE-2016-8655,CVE-2017-5123, CVE-2017-7308等)被攻擊者利用。因此, 實(shí)驗(yàn)測(cè)量可以通過刪除未使用的代碼或系統(tǒng)調(diào)用來緩解的CVE漏洞數(shù)量。為此, 本文首先爬取CVE漏洞網(wǎng)站并收集與動(dòng)態(tài)鏈接庫(kù)(glibc)和系統(tǒng)調(diào)用相關(guān)的CVE漏洞, 同時(shí)收集其涉及的的具體函數(shù)名、動(dòng)態(tài)鏈接庫(kù)API以及系統(tǒng)調(diào)用名。當(dāng)漏洞涉及的函數(shù)被阻止訪問時(shí), 對(duì)應(yīng)的漏洞就無法被攻擊者利用。

      根據(jù)程序依賴的動(dòng)態(tài)鏈接庫(kù)API列表, 并結(jié)合控制流圖, 能夠分析得出各程序需刪減的動(dòng)態(tài)鏈接庫(kù)函數(shù)。基于刪減庫(kù)函數(shù)與CVE漏洞的對(duì)應(yīng)關(guān)系,能夠計(jì)算出針對(duì)各程序所阻止的CVE漏洞數(shù)量。通過計(jì)算, 本系統(tǒng)共抵御了15個(gè)動(dòng)態(tài)鏈接庫(kù)中包含的CVE漏洞, 部分代表性的CVE漏洞如表2所示。

      表2 由動(dòng)態(tài)鏈接庫(kù)縮減緩解的部分CVE漏洞列表Table 2 Partial list of CVEs mitigated by dynamically-linked library debloating

      與動(dòng)態(tài)鏈接庫(kù)分析相似, 當(dāng)包含漏洞的系統(tǒng)調(diào)用被阻止訪問時(shí), 該漏洞被緩解?;谙到y(tǒng)調(diào)用與CVE漏洞的映射以及各程序禁用的系統(tǒng)調(diào)用列表, 本系統(tǒng)共阻止了目標(biāo)程序涉及的95個(gè)CVE漏洞, 平均為每個(gè)程序阻止了89個(gè)CVE漏洞。通過禁用系統(tǒng)調(diào)用緩解的部分代表性的CVE漏洞展示在表3中。

      表3 禁用系統(tǒng)調(diào)用緩解的部分CVE漏洞列表Table 3 Partial list of CVEs mitigated by syscalllimitation

      由于動(dòng)態(tài)鏈接庫(kù)的復(fù)雜性, 多個(gè)API可能會(huì)觸發(fā)相同的系統(tǒng)調(diào)用。動(dòng)態(tài)分析模塊分析動(dòng)態(tài)鏈接庫(kù)API和系統(tǒng)調(diào)用的對(duì)應(yīng)關(guān)系, 能夠識(shí)別由非法API觸發(fā)的系統(tǒng)調(diào)用。例如, 在靜態(tài)分析中, openat系統(tǒng)調(diào)用能夠被open和fopen這兩個(gè)動(dòng)態(tài)鏈接庫(kù)API訪問,而目標(biāo)程序僅依賴fopen, 動(dòng)態(tài)分析模塊能夠阻止從open執(zhí)行路徑訪問該系統(tǒng)調(diào)用的情況。經(jīng)統(tǒng)計(jì), 動(dòng)態(tài)分析模塊能為平均12.3個(gè)涉及漏洞的系統(tǒng)調(diào)用識(shí)別非法的觸發(fā)路徑。

      Confine[11]是一個(gè)基于系統(tǒng)調(diào)用限制的內(nèi)核攻擊面縮小工具, 它首先分析目標(biāo)應(yīng)用依賴的API列表,之后通過動(dòng)態(tài)鏈接庫(kù)API和系統(tǒng)調(diào)用的映射關(guān)系建立應(yīng)用運(yùn)行依賴的系統(tǒng)調(diào)用結(jié)合, 從而在目標(biāo)應(yīng)用運(yùn)行過程中通過Seccomp禁用無關(guān)系統(tǒng)調(diào)用。本文與Confine的不同之處主要在于, 在限制無關(guān)系統(tǒng)調(diào)用訪問的基礎(chǔ)上, 額外限制了應(yīng)用對(duì)動(dòng)態(tài)鏈接庫(kù)中無關(guān)代碼的訪問并且檢查應(yīng)用在觸發(fā)系統(tǒng)調(diào)用時(shí)執(zhí)行路徑的安全性。因此, 本文主要測(cè)試了本方法與Confine不同之處提供的額外安全能力。首先, 如前文所述, 本方法通過禁用無關(guān)的動(dòng)態(tài)鏈接庫(kù)代碼能夠額外緩解15個(gè)動(dòng)態(tài)鏈接庫(kù)中包含的CVE漏洞。其次, 通過動(dòng)態(tài)分析觸發(fā)系統(tǒng)調(diào)用路徑的安全性,本方法能夠?yàn)闇y(cè)試應(yīng)用識(shí)別平均12.3個(gè)涉及漏洞的系統(tǒng)調(diào)用的非法觸發(fā)路徑。因此, 相較于Confine本方法能夠進(jìn)一步增強(qiáng)系統(tǒng)安全性。

      綜上, 通過與現(xiàn)有方法的對(duì)比, 本文提出的方法能夠緩解更多漏洞, 提升攻擊者對(duì)內(nèi)核攻擊的難度, 此外本文提出的方法引入的實(shí)時(shí)負(fù)載更低。

      6 結(jié)論

      本文提出了一種多層次的物聯(lián)網(wǎng)系統(tǒng)內(nèi)核訪問控制方法, 通過分別在動(dòng)態(tài)鏈接庫(kù)以及系統(tǒng)調(diào)用兩個(gè)層次構(gòu)建關(guān)聯(lián)化的訪問控制機(jī)制, 提升用戶態(tài)程序?qū)?nèi)核的攻擊難度, 增強(qiáng)物聯(lián)網(wǎng)操作系統(tǒng)的隔離能力。實(shí)驗(yàn)結(jié)果表明, 本方法能夠有效縮減物聯(lián)網(wǎng)設(shè)備內(nèi)程序可訪問的動(dòng)態(tài)鏈接庫(kù)代碼以及系統(tǒng)調(diào)用數(shù)量, 阻止攻擊者利用無用代碼中的漏洞。未來的工作將關(guān)注于把本系統(tǒng)擴(kuò)展到更多的動(dòng)態(tài)鏈接庫(kù)以及更多的應(yīng)用場(chǎng)景下, 提升更多種類的操作系統(tǒng)的安全性。

      猜你喜歡
      訪問控制內(nèi)核調(diào)用
      萬物皆可IP的時(shí)代,我們當(dāng)夯實(shí)的IP內(nèi)核是什么?
      強(qiáng)化『高新』內(nèi)核 打造農(nóng)業(yè)『硅谷』
      核電項(xiàng)目物項(xiàng)調(diào)用管理的應(yīng)用研究
      基于嵌入式Linux內(nèi)核的自恢復(fù)設(shè)計(jì)
      Linux內(nèi)核mmap保護(hù)機(jī)制研究
      LabWindows/CVI下基于ActiveX技術(shù)的Excel調(diào)用
      ONVIF的全新主張:一致性及最訪問控制的Profile A
      基于系統(tǒng)調(diào)用的惡意軟件檢測(cè)技術(shù)研究
      動(dòng)態(tài)自適應(yīng)訪問控制模型
      淺析云計(jì)算環(huán)境下等級(jí)保護(hù)訪問控制測(cè)評(píng)技術(shù)
      玉林市| 乌兰察布市| 崇义县| 元阳县| 珲春市| 云浮市| 固原市| 丰台区| 宜兴市| 汝州市| 施甸县| 庄浪县| 阿拉善盟| 文成县| 永州市| 衡山县| 通山县| 保靖县| 万盛区| 谢通门县| 马边| 临夏县| 壤塘县| 潼南县| 深圳市| 上虞市| 庆元县| 临沧市| 汕尾市| 洞口县| 平泉县| 哈尔滨市| 奈曼旗| 射阳县| 游戏| 福泉市| 封丘县| 中超| 巴东县| 晋城| 垫江县|