論文閱讀:SKEE: A Lightweight Secure Kernel-level Execution Environment for ARM

這是一篇NDSS2014的論文,實際上就是一種隔離機制的實現。感覺和同年SP會議上的CPI的論文的思想有些相似。

簡介

​ 現有的工作針對內核監控和保護主要依賴於高特權的系統組件來隔離安全工具,以防潛在的內核攻擊。但是這種方法增加了維護工作和權限系統組件的代碼庫大小,反而增加了安全漏洞的風險。這篇文章針對這個問題,提出了一個ARM上的輕量級的安全內核執行環境。這個工具的研究思路主要從隔離、安全上下文切換、監控和保護內核這三點來展開。SKEE產生的額外開銷也相對較低,表明可以實際應用到ARM平臺上去。

研究動機

研究背景

​ 大多數操作系統依賴內核來實現在內存上的安全訪問控制。而內存上存放着這些內核的代碼,因此,整個系統的安全性依賴於一個巨大的可信計算基(TCB)。這個TCB包含基本的內核代碼以及可能存在漏洞的設備驅動。而且,大量現實中的事件表明,針對內核的攻擊是真實的威脅。

研究問題

目前研究存在的問題:

  • 內核監控和保護工作存在問題:現有的方法使用hypervisor或者沙箱機制,實際上是把安全工具交給一個比內核更高級別的系統構件中去。但由於安全工具本身的代碼量大和潛在的軟件漏洞,反倒會系統引入了風險。
  • ARM被廣泛使用在移動設備上,但是缺乏合適的技術來爲ARM提供隔離機制

​ 因此,需要有一個ARM上的安全環境來對內核進行監控和保護,並且這個工具需要與內核隔離,以內核漏洞影響到安全工具。

研究方案

安全假設

SKEE主要考慮針對以下這三種威脅,做出防禦。

  • 修改或重定位內核可執行文件
  • 利用內核漏洞修改內核數據或者劫持控制流,來實現惡意行爲
  • 攻擊SKEE隔離環境

SKEE提供了兩種安全保護。

  • 防止內核修改內存佈局或者訪問系統權限。
  • 確保從一個陷入危險的內核切換到隔離環境會經過一個嚴格的切換門控制

SKEE基於以下假設來構建。

​ SKEE假設所有的系統都能安全加載。也就是說,隔離環境在boot 啓動時是安全的。這個過程直接使用secure boot來實現。實際上,secure boot只能保證系統啓動時安全,但不能確保系統運行時安全。

​ 假設所有的內核都有數據執行保護機制。同時假設ARM硬件平臺實現了Privileged eXecute Never(PXN)機制。

​ 對於32-bit ARMv7 架構,SKEE要求內核只使用TTBR0來映射操作系統的內存,而TTBR1則由SKEE來使用。虛擬地址的空間的低2GB是用戶態代碼。這兩個要求不影響操作系統的功能,並且這兩個要求都是Linux的默認設置。

​ 對於64-bit ARMv8架構,SKEE要求使用一頁物理地址爲0x0的內存空間。這個要求也很容易通過虛擬化來滿足。

系統架構

​ SKEE的基本思想是創建一個自我保護的虛擬地址空間來支撐一個隔離執行環境。SKEE修改了security boot,從而使得security boot爲內核和SKEE創建兩個分離的地址空間,如下圖所示。SKEE保證安全的關鍵設計有三個:

  • 隔離
  • 安全切換
  • 監控和保護內核

在這裏插入圖片描述

關鍵技術

SKEE隔離

SKEE在防止內核訪問物理內存上使用了兩個步驟。首先是創建一個保護的地址空間,接着限制內核訪問MMU。

(1)創建一個保護的地址空間。

文章給出了下圖,一個ARMv7的地址空間隔離的示意圖。受控於內存轉換表的內核地址空間將使用插樁來實施以下三點來防止內核修改自己的代碼或者訪問SKEE的內存空間。

  • 移除所有指向SKEE環境或者內核內存轉換表的入口。即,拆橋。
  • 將內核代碼和SKEE轉換門映射爲只讀。即,可遠觀而不可褻玩。
  • 限制所有其他的內存區域(內核數據和用戶態內存)使用PXN bit位來執行特權代碼。即,不許百姓放火。

在這裏插入圖片描述

(2)限制內核訪問MMU

​ 爲了防止內核破壞地址空間隔離,只允許使用插樁後的內存轉換表。SKEE通過限制內核修改MMU寄存器來實現這點。另外,內核也不能修改轉換表的基寄存器。SKEE從內核代碼中移除了控制指令,並用跳轉到轉換門的hook來替代。從內核的二進制代碼中識別特定的指令是很容易的,因爲ARM使用定長指令集。借鑑TZRKP和SPROPES的技術,內核不能執行未經過SKEE模擬的特權指令。同時,SKEE還考慮了可加載內核模塊(LKM)對系統內存映射的影響。對於LKM,其必須通過SKEE加載,從而讓SKEE確保LKM的代碼沒有包含從內核模塊移除的特權指令。

安全切換

​ SKEE切換安全環境是通過一個特殊的轉換門來實現的。這個轉換門需要滿足原子性、確定性和獨有性才能保證兩個環境的隔離。

(1)原子性

​ 原子性指的是切換環境的操作是不可分割的。也就是說這個動作要麼成功,要麼失敗。在內核進入切換門前是不能訪問SKEE的空間。切換門首先會暴露SKEE的地址,然後跳轉到SKEE。由於內核和SKEE運行在同一特權級,也就沒有辦法一條指令實現切換,比如通過單點入口或者硬件控制。SKEE只能試圖去控制一連串的指令不會對內核暴露其地址空間。這可能也是攻擊者可以攻擊的一個點,比如擾亂門的指令執行順序或者跳到一連串指令的中間。SKEE考慮到這種情況了。

(2)確定性

​ 確定性指的是切換門的指令執行順序是確定的。雖然內核可以訪問到切換門,但是切換門不會相信內核的任何系統狀態或任何輸入。因此,這樣就確保了每次切換指令的執行順序都是一樣的,確定的。

(3)獨有性

​ 獨有性指的是訪問切換函數是獨有的。切換門是通往SKEE的唯一路徑。對於32位ARMv7來說,要在兩個不同的地址空間切換,相應的轉換表的基寄存器也必須相應地更新。這個更新操作只能通過MCR指令來做。如果切換門暴露了一個MCR指令的實例,那麼一個被攻破的內核就可能違反隔離機制。只要通過創建一個惡意頁表集合,加載這些頁表的基地址到指定的寄存器,然後跳轉到MCR指令去擁有一個不受限制的地址空間。爲了解決這個問題,切換門不能包含任何跟新TTBR0或者TTBR1的指令。文章提出了一種解決方法:任何非0值加載到TTBCR.N就會導致相同的系統狀態。這樣,切換動作就是確定的。

​ 對於64位ARMv8來說,TTBR0和TTBR1用來映射不同的虛擬地址。限制OS使用一個轉化表基寄存器,然後把另外一個留給SKEE,需要對OS做改動。這樣就影響SKEE的兼容性。爲了解決這個問題,SKEE與內核共享TTBR1。因此,在兩個地址空間切換就需要修改TTBR1的值。這也可以通過MCR指令來實現。但是,這也就無法確保切換的確定性。因此,切換門使用一個特殊的MSR編碼來保證TTBR1的確定變化。

​ 另外,作者還使用了ASID技術來加速切換上下文環境。

監控和保護

​ 爲了高效監控和保護內核,SKEE提供了安全工具能夠做到以下三點。

  • 陷入內核核心事件的能力
  • 訪問內核內存的能力
  • 控制內核內存保護的能力

​ SKEE控制內核的虛擬地址空間允許其修改內存區域的訪問權限來強制內核陷入某些操作。之前也提到過,SKEE用鉤子來取代了內核特權指令。這些鉤子可以放置於內核重要操作的執行路徑上,比如系統調用句柄等等。總的來說,SKEE擁有的特權和基於虛擬化的方式是相似的。SKEE的優勢在於不增加可信計算基的代碼量,而且可以運行在ARMv7這種不支持虛擬化擴展的方式的系統上。

測試評估

​ 這篇文章主要實現了兩個平臺上的SKEE,一個是32-bit ARMv7,測試於三星Note 4,另一個是64-bit ARMv8,測試於三星Galaxy S6上。

​ 作者對SKEE的評估,主要包含模擬系統事件的開銷,樣本安全檢測的額外開銷。

模擬系統事件的開銷

​ 首先作者測量了在SKEE內運行安全工具的開銷和不在SKEE保護下,運行安全工具的開銷。實際上由於SKEE運行在內核旁邊的一個平行世界,在環境內或是環境外的運行的影響是一樣的。因此,唯一的開銷就是在環境相互切換上的開銷。在使用TLB無效化的時候,ARMv7和ARMv8的開銷是相差不多的,使用了ASID技術後,ARMv8的開銷大大降低。不降低的結果其實也可以接受。

​ 另外,作者使用了多個benchmark 工具進行了性能評估。不論是v7還是v8系統,性能開銷最高不超過17%,大部分都在10%以下。可見,這個SKEE的性能開銷可以讓人接受。

​ 此外,作者還測量了加載APP的性能開銷,這裏選擇的app都是手遊,需要很長的加載時間。大部分APP的性能額外開銷都在10%以下。可見這個SKEE效果還是不錯的。

​ 最後,作者還測量了啓動的額外開銷。這個實驗中,SKEE的表現很差,因爲啓動過程中涉及到了大量的內存分配操作。但實際上,這方面的開銷大在實際應用中的影響也稍微小一些。

樣本安全檢測的額外開銷

​ 第二組實驗中,作者加了安全檢查來保證模擬事件不會突破隔離機制。這個實驗的目的是測量在SKEE上運行安全框架的額外開銷。實驗結果隨測試集變化很大。但是總體來說都低於10%的開銷,所以結果可以接受。另外,在啓動方面,有安全框架下的SKEE額外開銷也比較小。

總結

​ 這篇文章的主要難點還是在於兩個環境的切換過程,作者圍繞這個切換做了很多相關工作。文章中也提到切換操作並不是原子操作,攻擊者可能有辦法利用這點來實現攻擊。不過難度應該還是挺大的。

​ 文章的思路實際上和基於hypervisor的方式有點像,但有區別在於一個是縱向的,一個是橫向的。這裏的橫縱向是從內核的權限級別來看。這也啓發我們想別的問題,可能也可以採取這樣的思路。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章