MediaTek系統(tǒng)級芯片(SoC) 已嵌入全球約 37% 的智能手機(jī)和物聯(lián)網(wǎng)設(shè)備中，包括來自小米、Oppo、Realme、Vivo等高端手機(jī)。
MediaTek SoC，包括最新的 Dimensity 系列，包含一個(gè)特殊的 AI 處理單元 (APU) 和音頻數(shù)字信號處理器 (DSP)，以提高媒體性能并降低 CPU 使用率。APU 和音頻 DSP 都具有定制的 Tensilica Xtensa 微處理器架構(gòu)。Tensilica 處理器平臺允許芯片制造商使用自定義指令擴(kuò)展基本 Xtensa 指令集，以優(yōu)化特定算法并防止它們被復(fù)制。
研究人員對MediaTek音頻 DSP 固件進(jìn)行了逆向工程，盡管其操作碼和處理器寄存器具有獨(dú)特的安全防護(hù)，但他們還是發(fā)現(xiàn)了幾個(gè)可從 Android 用戶空間訪問的漏洞。
通過與原始設(shè)備制造商 (OEM) 合作伙伴庫中的漏洞相關(guān)聯(lián)，研究人員發(fā)現(xiàn)的MediaTek安全問題可能會(huì)導(dǎo)致 Android 應(yīng)用程序的本地權(quán)限升級。成功利用 DSP 漏洞可能允許攻擊者監(jiān)聽用戶對話或隱藏惡意代碼。
通過 Android 攻擊音頻 DSP 的方法
研究人員研究的目標(biāo)是找到一種通過 Android 攻擊音頻 DSP 的方法。首先，研究人員需要了解運(yùn)行在應(yīng)用處理器 (AP) 上的 Android 如何與音頻處理器進(jìn)行通信。顯然，必須有一個(gè)驅(qū)動(dòng)程序等待來自 Android 用戶空間的請求，然后使用某種處理器間通信 (IPC)，將這些請求轉(zhuǎn)發(fā)給 DSP 進(jìn)行處理。
使用基于MT6853芯片組的小米紅米Note 9 5G智能手機(jī)作為測試設(shè)備，操作系統(tǒng)為 MIUI Global 12.5.2.0 (Android 11 RP1A.200720.011)。
由于設(shè)備上呈現(xiàn)的媒體相關(guān)驅(qū)動(dòng)程序很少，所以不難找到負(fù)責(zé)AP和DSP之間通信的驅(qū)動(dòng)程序。
媒體驅(qū)動(dòng)程序
研究人員對 /dev/audio_ipi 驅(qū)動(dòng)程序感興趣。
在供應(yīng)商分區(qū)中對驅(qū)動(dòng)程序名稱進(jìn)行簡單搜索，即可找到MediaTek API庫/vendor/lib/hw/audio.primary.mt6853.so。該庫導(dǎo)出AudioMessengerIPI示例，其中包含sendIpiMsg方法，該方法可用于向音頻DSP發(fā)送IPI消息。研究人員使用這個(gè)庫來探索 Android 用戶空間和內(nèi)核之間的通信流程。在研究人員的 PoC 代碼中，研究人員直接處理驅(qū)動(dòng)程序 ioctls，無需額外包裝。
/dev/audio_ipi 驅(qū)動(dòng)程序中定義了以下 ioctls：
發(fā)送消息前，必須使用AUDIO_IPI_INIT_DSP ioctl對DSP固件進(jìn)行初始化。
研究人員可以使用以下簡單的函數(shù)來打開和初始化驅(qū)動(dòng)程序：
在 DSP 端，有幾個(gè)獨(dú)立的消息處理程序，稱為任務(wù)場景。每個(gè)任務(wù)場景都有自己獨(dú)特的功能范圍。例如，電話任務(wù)控制語音增強(qiáng)。AUDIO_IPI_LOAD_SCENE ioctl 用于在 DSP 上加載任務(wù)場景。任務(wù)場景ID是IPI消息的必填參數(shù)。
有三種不同的 ioctl 用于向音頻 DSP 發(fā)送 IPI 消息。不同之處在于與消息關(guān)聯(lián)的有效載荷數(shù)據(jù)的傳輸方式?？赡艿倪x擇是：
將有效載荷作為消息的一部分傳輸 (AUDIO_IPI_SEND_PAYLOAD)。有效載荷大小限制為 0xE0 字節(jié)；
通過注冊為在 AP 和 DSP 之間進(jìn)行通信的共享內(nèi)存 (AUDIO_IPI_SEND_DRAM) 傳輸載荷；有效載荷大小受共享區(qū)域大小的限制；
不要傳輸有效載荷 (AUDIO_IPI_SEND_MSG_ONLY)；
IPI 消息具有以下結(jié)構(gòu)：
重要的領(lǐng)域是：
task_scene——DSP任務(wù)場景ID；
data_type——有效載荷類型，如果有效載荷字段包含與消息關(guān)聯(lián)的數(shù)據(jù)，則設(shè)置為 1。如果有效載荷字段包含有關(guān)共享區(qū)域的信息，則設(shè)置為 2；
msg_id ——消息 ID；
param1 和 param2——消息參數(shù)，通常 param1 包含有效載荷大小。
因此，研究人員可以完全控制從 Android 用戶空間傳輸?shù)南?。通過 task_scene 和 msg_id 字段定位 DSP 處理程序，并通過 param1、param2 和有效載荷字段為其提供研究人員的數(shù)據(jù)。
現(xiàn)在就可以處理共享內(nèi)存了， AUDIO_IPI_REG_DMA ioctl 可用于請求 DSP 驅(qū)動(dòng)程序在 AP 和 DSP 之間共享的專用直接訪問存儲器 (DMA) 中分配一個(gè)區(qū)域。實(shí)際上，分配了兩個(gè)內(nèi)存區(qū)域：一個(gè)用于從AP傳輸數(shù)據(jù)到DSP任務(wù)場景，另一個(gè)用于反向傳輸數(shù)據(jù)。DSP 驅(qū)動(dòng)程序在調(diào)用 AUDIO_IPI_SEND_DRAM ioctl 時(shí)使用這些區(qū)域傳輸消息有效載荷并接收結(jié)果。
AUDIO_IPI_REG_DMA ioctl 需要具有以下結(jié)構(gòu)的對象作為參數(shù)：
研究人員通過 a2d_size 和 d2a_size 字段控制分配區(qū)域的大小。
Android 內(nèi)核日志為研究人員提供了有關(guān)預(yù)留 DMA 的信息：
基本虛擬地址- 0xffffff800b000000；
基本物理地址:0x7d940000；
大小- 0x200000；
當(dāng)研究人員為任務(wù)場景分配共享區(qū)域時(shí)，也會(huì)記錄 DMA 中的相應(yīng)偏移量。
Android 內(nèi)核日志
任務(wù)場景的共享區(qū)域的物理地址(計(jì)算為DMA的基本物理地址+共享區(qū)域的偏移量)在設(shè)備上是持久的。
以下函數(shù)可用于通過 DMA 發(fā)送帶有數(shù)據(jù)傳輸?shù)?IPI 消息：
/dev/audio_ipi 驅(qū)動(dòng)程序不直接與音頻 DSP 通信。相反，它通過將消息添加到 SCP 隊(duì)列將 IPI 消息轉(zhuǎn)發(fā)到系統(tǒng)控制處理器 (SCP)。音頻DSP固件注冊SCP調(diào)度器以接收來自SCP的音頻IPI消息。
逆向過程
固件鏡像
研究人員知道如何向音頻 DSP 發(fā)送 IPI 消息，下一步是在 DSP 固件中找到此類消息的處理程序。
音頻 DSP 在小米出廠更新中通過單獨(dú)的 audio_dsp.img 鏡像文件呈現(xiàn)。獲取鏡像的另一種方法是從根設(shè)備轉(zhuǎn)儲 /dev/block/platform/bootdevice/by-name/audio_dsp 分區(qū)。
鏡像文件具有專有結(jié)構(gòu)，但可以輕松重建。在研究人員的測試設(shè)備上，DSP 鏡像包含九個(gè)分區(qū)。
audio_dsp.img 結(jié)構(gòu)
cert1 和 cert2 分區(qū)是 DER 格式的證書，用于驗(yàn)證 hifi3 分區(qū)的完整性。hifi3_a_dram 分區(qū)是音頻固件使用的動(dòng)態(tài)內(nèi)存。在初始狀態(tài)下，它幾乎是空的。hifi3_a_iram和hifi3_a_sram分區(qū)是自定義FreeRTOS的代碼和數(shù)據(jù)。
每個(gè)分區(qū)都有一個(gè)標(biāo)頭，用于存儲該分區(qū)的大小和名稱。標(biāo)頭以神奇的 0x88168858 開頭，可用于快速定位文件中分區(qū)的開頭。圖 4 顯示了 hifi3_a_dram 標(biāo)頭。
hifi3_a_dram 標(biāo)頭
hifi3_a_dram 分區(qū)的標(biāo)頭和數(shù)據(jù)大小分別為 0x200 和 0x8000，研究人員可以輕松剪切hifi3內(nèi)容。
仔細(xì)看看 hifi3_a_sram，分區(qū)以 0x400 零字節(jié)開始。所以這里沒有特殊的文件格式。研究人員正在處理原始數(shù)據(jù)。接下來的 0x37F8 字節(jié)似乎是指向內(nèi)存的指針，主要位于 0x56000000 地址之后，從字節(jié) 0x3BF8 開始是 Xtensa 代碼。
IDA Pro 7.6 支持 Tensilica Xtensa 架構(gòu)。研究人員在IDA中打開hifi3_a_sram分區(qū)，基地址為0x56000000。
研究人員使用這個(gè)簡單的腳本將前導(dǎo)原始字節(jié)識別為指針（雙字）：
現(xiàn)在研究人員有成千上萬個(gè)指向代碼和數(shù)據(jù)的指針。但是研究人員如何處理代碼呢？Xtensa 操作碼的長度可變，IDA 不知道如何進(jìn)行。
研究人員首先嘗試編寫一個(gè)腳本來查找函數(shù)的開頭并嘗試反匯編。這是可能的，因?yàn)榇蠖鄶?shù)函數(shù)都從分配堆棧的入口操作碼開始。但它在這里效果不佳，因?yàn)橛刑?IDA 不知道的自定義操作碼。反匯編遇到未知操作碼時(shí)會(huì)卡住。研究人員得到的只是如下片段：
最終，研究人員找到了另一個(gè)很好的解決方案。研究人員使用 Xtensa SDK 來幫助 IDA。
HiFi DSP 軟件開發(fā)工具鏈可以從 tensilicatools.com 網(wǎng)站免費(fèi)下載。XtDevTools 是安裝包的一部分。研究人員使用 ~/xtensa/XtDevTools/install/tools/RI-2020.5-linux/XtensaTools/bin/xt-objdump 工具來創(chuàng)建 hifi3 分區(qū)的對象轉(zhuǎn)儲。這樣研究人員就轉(zhuǎn)儲了hifi3_a_sram：
對象轉(zhuǎn)儲包含反匯編的 Xtensa 代碼，來看看IDA收到的指令：
如你所見，xt-objdump 工具的 hifi3_ss_spfpu_7 核心比 IDA 插件知道更多的 Xtensa 操作碼。顯然，MediaTek使用了Tensilica準(zhǔn)備的標(biāo)準(zhǔn)音頻DSP模板作為其處理器的基礎(chǔ)。MediaTek添加了幾個(gè)特定的指令，但與 Tensilica 為音頻 DSP 提供的指令相比，它們的數(shù)量很少。
對象轉(zhuǎn)儲包含許多漏洞，不能作為研究的主要來源。但它可以幫助 IDA 更輕松地拆解 hifi3 分區(qū)。
Xtensa 插件在 IDA 中由 xtensa.so 庫表示。因?yàn)橐砑拥闹噶钐啵圆蝗菀状蜓a(bǔ)丁。最好的解決方案是使用對象轉(zhuǎn)儲來查找所有基本的 Xtensa 指令，并將反匯編作為注釋添加到任何無法識別的指令中。一個(gè)簡單的 IDA 腳本就可以完成這項(xiàng)工作。在下圖中，你可以看到應(yīng)用轉(zhuǎn)儲后 IDA 導(dǎo)航欄的外觀。幾乎所有的代碼塊都被識別。
IDA 導(dǎo)航欄
反匯編后的代碼如下所示：
大多數(shù)固件功能都包含用于記錄調(diào)試信息的代碼。日志消息包括當(dāng)前函數(shù)的名稱。MediaTek給了研究人員自描述的函數(shù)名和快速搜索代碼中函數(shù)的能力。
研究人員以與 hifi3_a_sram 相同的方式拆解了 hifi3_a_iram 分區(qū)。hifi3_a_dram 和 hifi3_a_iram 的基地址分別為 0x4FFB0000 和 0x4FFE0000。
FreeRTOS
既然找到了研究音頻DSP固件的方法，就來看看它的內(nèi)容。
MediaTek 音頻 DSP 操作系統(tǒng)是 FreeRTOS 的改編版本。MediaTek使用了第三方內(nèi)核，并在其上實(shí)現(xiàn)了音頻和消息邏輯。
操作系統(tǒng)在啟動(dòng)時(shí)會(huì)創(chuàng)建許多音頻任務(wù)，并將它們與場景 ID 相關(guān)聯(lián)。研究人員可以在 create_all_audio_task 函數(shù)中找到所有支持的任務(wù)和場景 ID。以下任務(wù)在研究人員的測試設(shè)備上運(yùn)行：
每個(gè)音頻任務(wù)由一個(gè)包含指向 recv_message 函數(shù)的指針的任務(wù)對象表示。當(dāng)新的 IPI 消息到達(dá)時(shí)，SCP 消息調(diào)度程序調(diào)用此函數(shù)。IPI 消息作為第二個(gè)參數(shù)傳遞給函數(shù)。
recv_message 函數(shù)正是研究人員正在尋找的。這是音頻任務(wù)開始處理從 Android 端發(fā)送的 IPI 消息的地方?？焖俨榭创a后，研究人員看到除了電話呼叫、卸載、控制器和守護(hù)進(jìn)程之外，大多數(shù)任務(wù)都使用相同的 task_common_recv_message 函數(shù)。畢竟，只有接下來的五個(gè)函數(shù)解析 IPI 消息，這是研究人員可以搜索漏洞的地方：
研究人員手動(dòng)檢查了這些功能，發(fā)現(xiàn)了幾個(gè)可用于從 Android 攻擊 DSP 的漏洞。
CVE-2021-0661、CVE-2021-0662 和 CVE-2021-0663
AUDIO_DSP_TASK_MSGA2DSHAREMEM 消息處理程序中的經(jīng)典堆溢出
此漏洞與所有常見的音頻 DSP 任務(wù)有關(guān)。在處理 ID 為 6 (AUDIO_DSP_TASK_MSGA2DSHAREMEM) 的 IPI 消息時(shí)，task_common_task_loop 函數(shù)會(huì)將消息載荷復(fù)制到公共任務(wù)對象的 atod_share 字段中。消息 param1 用作要復(fù)制的字節(jié)數(shù)。省略了 param1 不大于 atod_share 字段大小的檢查。因此，當(dāng)載荷大小大于0x20字節(jié)時(shí)，載荷會(huì)覆蓋atod_share之后的內(nèi)存。
下面的調(diào)用send_ipi_dma在Android端覆蓋DSP內(nèi)存垃圾和導(dǎo)致崩潰：
init_share_mem_core 函數(shù)中的經(jīng)典堆溢出
當(dāng)接收到ID為7的IPI消息時(shí)，守護(hù)任務(wù)的task_auddaemon_task_loop函數(shù)調(diào)用init_share_mem_core函數(shù)。init_share_mem_core 使用 param1 作為要復(fù)制的字節(jié)數(shù)將消息有效載荷復(fù)制到內(nèi)部 audio_dsp_dram 緩沖區(qū)。該函數(shù)檢查 param1 是否小于 0xE0 字節(jié)，但 audio_dsp_dram 大小為 0x20 字節(jié)， 0xC0 字節(jié)可以被覆蓋。
要使用受控值修復(fù) DSP 堆，研究人員可以發(fā)送攜帶有效載荷的 IPI 消息作為消息的一部分：
Android 內(nèi)核日志確認(rèn)了該漏洞：
audio_dsp_hw_open_op 函數(shù)中的數(shù)組索引驗(yàn)證不正確
在處理 ID 為 0x203 (AUDIO_DSP_TASK_PCM_PREPARE) 的 IPI 消息時(shí)，task_common_task_loop 函數(shù)調(diào)用 get_audiobuf_from_msg 從 param2 尋址的物理內(nèi)存中提取音頻緩沖區(qū)。接下來，將此緩沖區(qū)作為參數(shù)傳遞給作為 audio_dsp_hw_open_op 的包裝器的 audio_dsp_hw_open 函數(shù)。audio_dsp_hw_open_op 函數(shù)將此音頻緩沖區(qū)復(fù)制到靜態(tài)數(shù)組。音頻緩沖區(qū)中偏移量 0x54 處的字段用作數(shù)組索引。沒有索引值的溢出檢查。因此，研究人員可以提供任意索引，用受控值覆蓋數(shù)組后面的一部分內(nèi)存。
要擁有音頻緩沖區(qū)，研究人員可以通過共享 DMA 區(qū)域?qū)?IPI 消息發(fā)送到 DSP，并將 param2 指向有效載荷所在的內(nèi)存。正如研究人員之前所展示的，共享 DMA 區(qū)域的物理地址永久存在于設(shè)備上。
以下 PoC 代碼會(huì)重新啟動(dòng)研究人員的測試設(shè)備：
請注意，get_audiobuf_from_msg 函數(shù)也不驗(yàn)證 param2。在 param2 中使用任何不合適或空的地址都會(huì)使 memcpy 函數(shù)中的 DSP 崩潰：
尋找一種從非特權(quán)應(yīng)用程序攻擊 Android HAL 的方法
現(xiàn)在研究人員知道如何通過 /dev/audio_ipi 驅(qū)動(dòng)程序從 Android 攻擊音頻 DSP。不幸的是，無特權(quán)的 Android 應(yīng)用程序以及 adb shell 沒有與此驅(qū)動(dòng)程序通信的權(quán)限。SELinux 僅允許從 factory、meta_tst 和 mtk_hal_audio 上下文訪問 audio_ipi_device 對象。攻擊者需要找到一種方法來利用 MediaTek 硬件抽象層 (HAL) 從 mtk_hal_audio 上下文下訪問 DSP 驅(qū)動(dòng)程序。
在尋找攻擊 Android HAL 的方法時(shí)，研究人員發(fā)現(xiàn)了 MediaTek 為調(diào)試目的實(shí)施的幾個(gè)危險(xiǎn)的音頻設(shè)置。第三方 Android 應(yīng)用程序可以濫用這些設(shè)置來攻擊 MediaTek Aurisys HAL 庫。
音頻硬件參數(shù)
Android 文檔指出 AudioManager 提供對音量和鈴聲模式控制的訪問。Android 應(yīng)用程序可以綁定音頻服務(wù)，然后使用 AudioManager 的 setParameters 方法來配置硬件。
設(shè)備制造商可以添加他們自己的音頻設(shè)置并跟蹤他們的更改。MediaTek 提供專有參數(shù)來配置 Aurisys 庫。在研究人員的測試設(shè)備上，/vendor/lib/hw/audio.primary.mt6853.so 庫負(fù)責(zé)處理MediaTek添加的音頻參數(shù)。在下圖中，你可以看到 setParameters 字符串參數(shù)的可接受格式。
MediaTek音頻參數(shù)
參數(shù)字符串包含以下信息：
處理命令的目標(biāo)子系統(tǒng)，它可以是 HAL 或 DSP；
aurisys 場景；
標(biāo)識受影響的 HAL 庫的命令項(xiàng)；
命令字符串，研究人員找到了八個(gè)支持的命令；
該值實(shí)際上是命令的參數(shù)；
/vendor/etc/aurisys_config.xml 和 aurisys_config_hifi3.xml 文件定義了所有支持的 aurisys 場景和命令項(xiàng)。
例如，以下參數(shù)可用于啟用語音處理信息的日志記錄：
大多數(shù)支持的命令在信息泄漏方面對研究人員來說很有趣。但是研究人員只想關(guān)注 PARAM_FILE 命令，它允許研究人員設(shè)置與特定 Aurisys HAL 庫相關(guān)的配置文件的位置。
例如，非特權(quán) Android 應(yīng)用程序可以通過設(shè)置以下參數(shù)來自定義 OEM 提供的 libfvaudio.so HAL 庫：
Aurisys 庫在提供時(shí)解析配置文件。
注意，設(shè)備制造商通常不關(guān)心正確地驗(yàn)證配置文件，因?yàn)榉翘貦?quán)用戶無法使用這些文件。但在研究人員的例子中，他們控制著配置文件。HAL 配置成為攻擊媒介。格式錯(cuò)誤的配置文件可用于使 Aurisys 庫崩潰，從而導(dǎo)致 LPE。
研究人員已經(jīng)準(zhǔn)備了一個(gè)針對小米設(shè)備上的 libfvaudio.so HAL 庫的攻擊示例，但出于安全原因，研究人員無法分享詳細(xì)信息。
為了緩解所描述的音頻配置問題，MediaTek決定在 Android 的發(fā)布版本中刪除通過 AudioManager 使用 PARAM_FILE 命令的功能，且漏洞被命名為 CVE-2021-0673。
參考及來源：https://research.checkpoint.com/2021/looking-for-vulnerabilities-in-mediatek-audio-dsp/
來源：嘶吼專業(yè)版
在線咨詢
在線咨詢
0371-63319761