摘要:根據此規範,與指紋硬件(傳感器)的通信只能由運行在安全模式下的CPU進行,這將確保即使在Root(破解超級用戶權限)設備上也無法從安卓操作系統(開放執行環境,REE)本身接入傳感器。谷歌規定哪些數據需要受TEE保護,以及在涉及到生物識別時哪些措施需要在TEE下進行TEE旨在確保用戶的指紋數據安全,無論設備是否被Root。

OnePlus7 Pro 信息泄露漏洞在近日被披露。OnePlus 7 Pro10.0.3.GM21BA之前的版本中存在安全漏洞。攻擊者可利用該漏洞從指紋感應器中獲取指紋圖像(位圖)。新思科技對此漏洞進行了解析。

近年來,移動可信執行環境(TEE, ARMTrustZone)的應用逐步增長。新思科技網絡安全研究中心(CyRC)對TEE的應用安全進行了研究分析,其中的一個發現涉及到一加手機OnePlus 7Pro Advanced的漏洞。該漏洞可能會導致用戶註冊指紋信息被泄露。

安卓系統指紋認證簡介

在安卓6以前並沒有一套指紋認證的標準。在安卓6以後,谷歌開始介入,並在“即兼容性定義文檔”中定義了一組指紋認證的要求,隨着不斷發展,現在已經包括了更多生物識別傳感器。

標準化方法是需要在TEE執行涉及生物識別信息的所有敏感操作。根據此規範,與指紋硬件(傳感器)的通信只能由運行在安全模式下的CPU進行,這將確保即使在Root(破解超級用戶權限)設備上也無法從安卓操作系統(開放執行環境,REE)本身接入傳感器。

如何在一臺被 Root 過的設備上保護資料?

當安卓設備被Root時,通常意味着解鎖引導加載程序,並對閃存中的一個或多個分區進行修改。但是,“解鎖引導加載程序”並不是一個完全精確的術語。遵循ARM可信的固件模型啓動安卓設備。該模型由多個引導階段組成。解鎖引導加載程序通常是指該過程的最後階段,設備的可信環境在啓動安卓操作系統影像之前接受檢查。TEE在此階段之前啓動。

TEE的運行級別和安全狀態比安卓操作協同的內核具有更高的特權。REE無法接入可信執行環境存儲器,並且所有的通信都通過安卓操作系統內核中的Secure Monitor Calls進行。

谷歌規定哪些數據需要受TEE保護,以及在涉及到生物識別時哪些措施需要在TEE下進行TEE旨在確保用戶的指紋數據安全,無論設備是否被Root。

當然,漏洞總會“有機可乘”的。您的代碼越多,漏洞的數量有可能越多。TEE的好處之一是在該特權級別上運行的代碼比在安卓操作系統內核級別上運行的代碼少,從而減少攻擊面,更容易實現安全性。

在一臺被Root過的設備上,可以在REE的任何位置發起攻擊。

您可以繼續調用libgf_ud_hal庫中已經存在的任何功能。或者,可以調用原始傳輸,建立共享內存緩衝區,並將輸入傳遞給TEE。

這兩種操作的區別在於,前者libgf_ud_hal庫中的函數將使用特定於您要調用的命令的專有結構來填充緩衝區,並且它可能已經進行了原始傳輸;後者,您需要知道在該緩衝區中放入什麼以及如何構造該緩衝區,以便TEE按路線發送,並且trustlet(高通的可信應用程序)可以理解它。

從這開始,緩衝區跨越安卓操作系統內核中一長串的調用,從EL3中的Secure Monitor,S-EL1中的TEE OS,並最終到達S-EL0中的trustlet。

一旦此緩衝區到達Trustlet,它將進入“路由”功能(命令處理程序)。此功能檢查緩衝區的前幾個字節,以找出需要執行trustlet的功能。

典型路由功能

Trustlet開發人員需要確保其生產的trustlet構建不會向REE公開任何敏感功能。例如,考慮以下我們在trustlet中找到的調試代碼。您可以從傳感器中轉儲數據並將其返回到REE:

或者可以效仿OnePlus 7 Pro的操作,只需在“路由”組件中使此代碼不可接入即可。

CVE-2020-7958

我們在OnePlus 7 Pro上發現的問題是,通過工廠測試命令處理程序可以使用類似的功能。

REE 中的邏輯

指紋子系統的REE部分包含在libgf_ud_hal.so共享庫中。可通過多種方式獲得此共享庫文件:

 1. 從被”root”的設備上,在/vendor / lib64 /目錄下。
 2. 例如,可以從供應商的軟件升級頁面下載軟件版本(固件)。/ vendor / lib64 /目錄的內容可以在vendor.img分區中找到。該分區映像可以作爲常規ext2文件系統數據映像掛載。

libgf_ud_hal.so共享庫包含一個名爲goodix :: SZCustomizedProductTest ::factoryCaptureImage()的方法。我們通過逆向工程發現了以下解構的僞代碼:

TEE命令的結構因命令而異,但重要的是,它包含以下路由信息:

 1. 目標ID(目標)設置爲1003。trustlet將使用它將命令路由到處理具有此目標ID的命令的正確模塊。
 2. 命令ID(cmd_id),爲17。此參數將命令路由到trustlet內部模塊中的特定分支。

請注意,至今我們還沒有談到TEE,我們正在討論指紋傳感器的概念。我們懷疑此庫可能是傳感器供應商提供的SDK(軟件開發工具包)的一部分,而設備供應商(例如OnePlus)對他們使用的硬件傳感器僅進行了最小的更改和重新配置。

準備好命令結構後,即可使用goodix:: HalBase :: invokeCommand()函數與高通提供的TEE通信庫libQSEEComAPI.so進行通信。

trustlet 中的邏輯

在OnePlus 7 Pro的指紋身份驗證信任中,我們通過查看錯誤處理程序和導出的符號來識別以下路由功能:

“模塊”在這裏迭代,並且將對每個模塊執行檢查,以查看模塊元數據條目是否具有與正在處理的命令的“目標ID”相匹配的“目標ID”。如果有,則將從元數據結構中讀取並調用該模塊的入口點地址,以便它可以繼續處理以下命令:

我們在trustlet中發現了一個名爲g_dump_module的符號:

該符號實際上指向具有將圖像從傳感器轉儲到REE中的功能的模塊。但是,該模塊不在gf_modules_cmd_entry_point使用的表中:

這很好:將圖像轉儲組件從命令路由邏輯中排除。

但是,這裏還有另一個有趣的模塊:g_product_test_module。測試代碼具有對我們有用的功能並不罕見。在此二進制文件中的字符串中搜索與圖像轉儲有關的所有內容,發現了以下有趣的函數名稱:sz_factory_test_capture_image

修復和事後思考

修復措施非常簡單:將ID 17的命令處理程序從生產Trustlet中刪除。這意味着REE對goodix ::SZCustomizedProductTest :: factoryCaptureImage的調用將失敗。

構建涉及TEE的敏感功能是一個複雜的過程,多個供應商需要參與,並且要對硬件和軟件領域都擁有豐富的知識。集成多個SDK是一個挑戰。這些SDK可能在REE和TEE上都具有組件,而要找出像這樣不常見的漏洞可能是更大的挑戰。我們強烈建議一加手機能夠迅速指派合適的團隊去解決此問題。

我們希望本文能解釋Trustlet的內部運作、不同組件如何協同工作以提供可信執行環境,以及如何對其進行攻擊。以上爲摘要翻譯,完整原文請參考: https://www.synopsys.com/blogs/software-security/cve-2020-7958-trustlet-tee-attack/

*本文作者:SIGsecurity,轉載請註明來自FreeBuf.COM

相關文章