別眨眼網

Linux Security Module逆向分析實戰

本文記錄了對某發行版Linux中一個安全模組（LSM）的逆向過程，該LSM對系統中待執行的程式進行安全校驗，資料流穿越核心態與使用者態，涉及系統核心及系統服務。此LSM對系統安全性的增強效果明顯，其設計思路值得防守方研究學習，可於個人終端或伺服器安全防護中應用。特此對逆向內容記錄，希望能為讀者在終端防護方面拓寬思路，同時歡迎感興趣的師傅們交流學習。

一。 LSM框架簡介

Linux安全模組（Linux Security Module，LSM）框架是Linux作業系統核心提供的一種安全機制，它透過核心擴充套件實現hook函式以完成多種安全檢查，通常用於強制訪問控制（Mandatory Access Control）。雖然被稱作“模組”，但不同於LKM，這些擴充套件並不是可載入的核心模組，而是和核心程式碼一起編譯在核心檔案（vmlinuz）中。可以透過如下命令檢視本機啟用的LSM，cat /sys/kernel/security/lsm。常見的LSM包括SELinux、Yama等。

LSM框架的hook點設置於核心訪問關鍵物件前，透過呼叫LSM中實現的hook函式，判斷是否可以進行訪問。如果有多個LSM，則會根據初始化的順序依次判斷，都允許才能進行訪問。上述關鍵物件包括程式、程序、套接字、檔案系統等，可在/usr/src/linux-headers-YOURSYSTEMSYSTEMVERSION/include/linux/lsm_hooks。h中檢視詳細的hook說明。

這裡以程式啟動過程為例，簡單說明LSM工作的機制。當透過execve系統呼叫執行一個新程式時，核心最終會執行到__do_execve_file函式完成相關工作，在這裡會呼叫prepare_binprm函式填充struct linux_binprm，填充前會呼叫security_bprm_set_creds進行安全檢查。security_bprm_set_creds就是LSM框架提供的hook，它會依次呼叫註冊在這個鉤子上的回撥函式，完成安全檢查。此流程上相關程式碼以及此鉤子的說明如下。

LSM開發時，透過如下函式定義安全模組的hook函式，逆向時透過此函式可快速定位具體的LSM以及相關回調函式。

二。 安全模組逆向分析

2。1 分析準備

本次分析的物件為某發行版Linux，此係統提供了可執行檔案的簽名校驗功能，僅有簽名的程式可以被執行，本次逆向的目標就是試圖還原校驗功能的框架和邏輯。由於此安全檢查的存在，提權、後門等程式因為此機制的存在而無法直接執行，從某種程度提高了作業系統的安全性。編譯一個hello world程式，執行，會提示無法透過系統安全校驗目前不能執行。strace跟一下，看到在execve時就被幹掉了（如下圖），可以肯定是在核心中完成這個動作的，大機率是透過核心擴充套件實現。

下面嘗試定位此核心擴充套件。lsmod看一眼，沒有發現明顯相關的。檢視此係統的所有LSM，有一個名為elfverify的模組，透過此命名可以推斷，就是此模組完成了程式的校驗功能。

LSM是被編譯在核心中的，因此接下來需要獲取到此係統的核心檔案。系統的核心檔案通常可以在/boot目錄中找到，其中vmlinuz的檔案是壓縮後的核心，可以透過extract-vmlinux工具提取未壓縮的核心檔案vmlinux進行分析。然而提取後的檔案是沒有符號的，符號資訊儲存在同目錄下System。map檔案中。這裡推薦使用vmlinux-to-elf這個工具完成提取與符號修復工作，透過此工具可輸出一個帶符號的ELF檔案，方便逆向分析。

2。2 LSM分析

反編譯檢視恢復後的核心，在elfverify的初始化函式elfverify_init（）中，security_add_hooks（）的第二個引數count為5，即此LSM一共註冊了5個hook函式；跟蹤一下第一個引數security_hook_list，可得到所有實現的回撥函式，總結如下。

hook

回撥函式

說明

security_mmap_file

security_bprm_set_creds

在執行mmap前檢查許可權

security_sb_mount

hook_sb_mount

在某些裝置掛載前檢查許可權

security_socket_create

hook_socket_create

在建立新套接字之前檢查許可權

security_socket_listen

hook_socket_listen

在套接字協議層監聽操作前檢查許可權

security_bprm_set_creds

hook_bprm_set_creds

在程式執行前設定bprm時檢查許可權，檢查基於bprm->file，並存於bprm->security中

可以看出此LSM還對套接字、裝置掛載進行了安全校驗，這裡專注於程式執行的校驗，鎖定hook_bprm_set_creds進行進一步分析。

跟進hook_bprm_set_creds，該函式首先對一些引數進行檢查，接著判斷是否開啟了開發者模式（判斷依據是某個檔案的內容），如果符合條件則放行（返回0），否則呼叫access_verify進行進一步判斷。此函式的引數型別是struct linux_binprm， 原始碼中此結構體被標記為__randomize_layout，這是Linux核心中的一項防禦機制，有此標記的結構體其中的元素將作亂序排列，從而攻擊者難以找到偏移具體對應的元素。因此透過靜態分析，也暫時無法確定傳遞給access_verify的引數。

在access_verify中，會將當前程序透過add_wait_queue掛起等待，並將90-pid-UNKNOWN資訊寫入某個裝置中，這裡的90應該是LSM開發者自定義的一個“魔數”（socket校驗中是91），而第三段的內容由於結構體的隨機化也暫時無法確定（之後分析會知道其實是程式路徑）。之後再從此裝置中讀取資訊，根據內容選擇是否繼續執行，並從佇列中移除程序。

LSM中關於elf校驗的流程到這個函式基本就結束了，並不包含具體的校驗邏輯，只是將待校驗的程序資訊寫入某個裝置並等待結果，可見校驗應該是在另一處完成。經過跟蹤分析，此LSM註冊了一個雜項裝置（在register_elf_verifier_dev（）中），名為elf_verifier。下一步找到了誰從這個裝置中讀取資訊，大機率就能定位到完成校驗的具體程式碼。

然而，在核心中並沒有找到相關的程式碼，下一步得去使用者態的程式找找。

2。3 安全校驗邏輯分析

檢視一下系統程序，發現一條程式名為*-elf-verify，其ppid為1，看了下是系統服務，推斷這就是處理雜項裝置中資料的程式了。為驗證推斷，將此服務停止，執行一個自己編譯的程式，待執行的程序“僵死”，推斷應該是LSM將程序送入等待佇列後，沒有從雜項裝置中讀到校驗結果，就造成了一直掛起的局面。這也確認了正是這個程式處理裝置資料並給予返回結果，校驗邏輯應當就在其中。

對此係統服務程式進行分析與除錯，在進行ELF檔案安全校驗時，它會迴圈的從/dev/elf_verifier這個裝置中讀取內容，讀取到的內容包括PID和完整的程式路徑，並依據此資訊進行校驗，其主要檢查如下兩點：

判斷此路徑的程式是否在白名單或黑名單中

在ELF檔案頭的特殊節中提取簽名（PKCS7），然後進行驗證（證書在系統某路徑中）

上述的黑白名單位於系統/usr目錄下，僅root使用者可編輯。而ELF檔案頭中的特殊節在其他普通的ELF檔案中不會出現，應當是在對ELF檔案進行簽名時加上的，而將簽名信息新增到檔案頭中又不會對程式的正常執行造成影響。如果能夠順利讀取到簽名信息，則呼叫openssl的相關函式進行校驗。校驗完成後，將檢驗結果寫入/dev/elf_verifier，通知核心進行後續動作；同時如果校驗不透過，會透過dbus通知GUI彈出提示告知使用者。

至此，一次校驗完成，整個簽名校驗功能的脈絡基本摸清了。在其中還有一些細節檢查，例如檔案格式、ELF檔案頭等等，就不一一展開介紹了。

三。 總結

該系統的可執行程式簽名校驗功能，透過安全模組（LSM）elfverify、系統服務聯合完成，二者透過雜項裝置/dev/elf_verifier傳遞資料，完成了使用者態和核心態的互動。在核心中，透過實現LSM的security_bprm_set_creds鉤子在程式執行前獲取到待執行程式的完整路徑，將程序暫時掛起，同時將資訊寫入裝置中；使用者態程式從裝置中讀取到資訊後，判斷此路徑程式是否在黑白名單、程式是否是經過簽名的ELF程式，並將判斷結果寫入裝置；核心LSM根據返回的結果確定是否允許執行。

整個過程涉及LSM、裝置、ELF檔案格式、簽名校驗等知識，有深有淺，本文記錄得比較簡單，歡迎感興趣的師傅深入交流。同時，該方式利用LSM框架提供的鉤子，對某些操作進行安全校驗，同時將複雜的校驗邏輯在使用者態完成，透過裝置完成資料傳遞，此類模式在終端安全防護上亦可借鑑。

最後

關注私我，獲取【網路安全學習攻略】