-
博客
希望我們能(néng)與您分享和探讨成(chéng)長(cháng)中的點點滴滴
揭示AUTOSAR中隐藏的漏洞
創提信息
2024/01/03
分享到
AUTOSAR是一個普遍采用的軟件框架，用于各種(zhǒng)汽車零部件，如ABS, ECU,自動照明、環境控制、充電控制器、信息娛樂系統等。AUTOSAR的創建目的是促進(jìn)汽車零部件之間形成(chéng)标準接口，可以在不同制造商之間互通。
因此，任何配備微控制器(MCU)的汽車零部件都(dōu)應符合AUTOSAR的規定。
AUTOSAR标準不僅管理用于模塊間通信的數據格式，還(hái)規定了這(zhè)些模塊的标準API。在汽車行業内使用的AUTOSAR平台有兩(liǎng)個版本：Classic和Adaptive。
Adaptive平台是爲高性能(néng)設備量身定制的，例如信息娛樂系統或高級駕駛輔助系統(ADAS)，這(zhè)些設備通常在Linux或QNX等資源豐富的操作系統上運行。另一方面(miàn)，Classic平台部署于運行在微控制器單元裸闆(MCU)上的低性能(néng)設備中，包括ABS, EBD, 安全氣囊控制單元、車身控制模塊、傳輸控制模塊等系統。
雖然AUTOSAR是一個穩健而可靠的開(kāi)發(fā)框架，但它并非沒(méi)有潛在的錯誤和漏洞。在對(duì)AUTOSAR文件進(jìn)行内部分析時(shí)，我們偶然發(fā)現了一個特别有趣的漏洞，這(zhè)個漏洞可能(néng)會(huì)帶來很大的安全風險。代碼中的缺陷并不是由于AUTOSAR本身造成(chéng)的，而是對(duì)AUTOSAR使用不當的結果。
在本文中，我們打算深入研究和剖析這(zhè)個具體的案例。
AUTOSAR Classic固件開(kāi)發(fā)
在大多數情況下，固件是利用兩(liǎng)家領先的AUTOSAR軟件提供商(Vector和Elektrobit)提供的工具鏈開(kāi)發(fā)的。
Vector和Elektrobit都(dōu)提供了配置工具和SDK，其中包括标準AUTOSAR模塊的預構建實現，如MicroSAR OS運行時(shí)、CAN接口、NVM API、診斷模塊、加密和内存接口等。這(zhè)種(zhǒng)被(bèi)稱爲基本軟件(Basic Software,簡稱BSW)的SDK是以中間件方式執行，因此不能(néng)在目标硬件上獨立運行。
除了BSW之外，還(hái)有一套被(bèi)稱爲微控制器抽象層(Microcontroller Abstraction Layer,簡稱MCAL)的驅動程序和庫，用于對(duì)硬件的訪問。每個打算將(jiāng)其MCU用于汽車行業的硬件制造商都(dōu)提供了适用于其MCU的AUTOSAR MCAL。例如，有來自博世、恩智浦、瑞薩和英飛淩的MCAL。MCAL驅動程序和庫也需要遵循AUTOSAR标準，以确保BSW可以與任何硬件制造商的MCAL一起(qǐ)使用。
新固件的開(kāi)發(fā)通常從配置工具開(kāi)始。在這(zhè)裡(lǐ)，開(kāi)發(fā)人員構建要使用的硬件平台，爲他們的項目選擇所需的MCAL和BSW模塊，然後(hòu)在所有模塊之間建立連接。例如，開(kāi)發(fā)人員可以指定BSW中的CanIf模塊應該使用哪個MCAL的CAN接口。一旦配置階段完成(chéng)，配置工具就(jiù)會(huì)生成(chéng)源代碼，這(zhè)些源代碼本質上是MCAL和BSW的一個子集。
生成(chéng)源代碼之後(hòu)，可以使用任何編譯器或集成(chéng)開(kāi)發(fā)環境(IDE)對(duì)其進(jìn)行編譯，然後(hòu)再將(jiāng)其安裝到目标設備上。由配置工具輸出的源代碼已經(jīng)包含了設備以默認行爲操作所必需的一切。因此，開(kāi)發(fā)人員可能(néng)不需要對(duì)所生成(chéng)的代碼進(jìn)行任何修改。在BSW層之上的任何自定義代碼往往都(dōu)是最小化了的，通常占固件總大小的10%以下。
基于AUTOSAR的固件漏洞
在我們進(jìn)行紅隊滲透測試的過(guò)程中，我們獲得了基于AUTOSAR的固件進(jìn)行安全評估。從攻擊者和滲透測試者的角度來看，基于AUTOSAR的文件的潛在攻擊點非常有限。該模塊的源代碼非常可靠，始終經(jīng)過(guò)代碼審查和漏洞分析。
關于常規漏洞和通用缺陷枚舉(CWE)，發(fā)現它們的可能(néng)性相當小。沒(méi)有動态内存分配，所有變量要麼(me)是全局的，要麼(me)是堆棧上的，從而消除了發(fā)現double-free或use-after-free等漏洞的機會(huì)。汽車代碼不執行字符串操作，而隻關注二進(jìn)制解析。因此，通過(guò)sprintf, sscanf, strcpy等操作遇到堆棧溢出的可能(néng)性在這(zhè)裡(lǐ)是不存在的。
當涉及到潛在的競态條件漏洞時(shí)，AUTOSAR Classic不允許動态任務初始化或動态創建的同步原語。任務和同步事(shì)件列表是在配置階段預先确定的。因此，考慮到靜态的、預先配置的任務資源和事(shì)件集，自動生成(chéng)的代碼不太可能(néng)包含死鎖或競态條件。
因此，我們必須深入研究AUTOSAR框架，了解它的用法和對(duì)API的潛在使用不當，特别關注用戶如何以可能(néng)導緻漏洞的方式調用它。
我們在NvM模塊中遇到了一組函數：NvM_ReadBlock, NvM_WriteBlock和NvM_RestoreBlockDefaults，這(zhè)組函數通常用于在NVM中加載和存儲設備設置（如EEPROM, NAND, NOR内存等）。
通過(guò)對(duì)NVRAM管理器規範中的函數原型進(jìn)行研究：
很明顯，這(zhè)些函數缺少緩沖區大小檢查，僅使用塊ID來确定在配置階段配置的特殊塊表中的數據大小。換句話說(shuō)，用戶有責任包含在寫入時(shí)驗證保存在NvM塊中的數據大小是否合适的代碼。同樣(yàng)，當從NvM塊中讀取數據時(shí)，用戶有責任提供足夠大的緩沖區，因爲NvM_ReadBlock隻是根據NvM塊的大小簡單地覆蓋緩沖區。
因此，這(zhè)樣(yàng)的API調用可能(néng)會(huì)導緻越界(Out of Bounds, 簡稱OOB)讀取或寫入。根據作爲NvM_DstPtr/NvM_SrcPtr傳遞的緩沖區類型，可能(néng)會(huì)出現各種(zhǒng)問題：
• 如果用戶提供了一個小的堆棧變量，但讀取了一個大的NvM塊，NvM_ReadBlock將(jiāng)在堆棧變量之外寫入數據，這(zhè)會(huì)導緻堆棧損壞，并可能(néng)爲遠程代碼執行(Remote Code Execution,簡稱RCE)打開(kāi)大門。
• 如果提供的變量是全局變量，NvM_ReadBlock將(jiāng)覆蓋鄰近的全局變量。這(zhè)可能(néng)會(huì)導緻代碼中出現未定義的行爲。
• 如果用戶爲NvM_WriteBlock提供了一個小的堆棧或全局變量，將(jiāng)導緻NvM_WriteBlock讀取變量外的數據，并將(jiāng)随機數據存儲到NVM中。
利用這(zhè)種(zhǒng)方法，我們發(fā)現了一個有趣的由于AUTOSAR API使用不當導緻緩沖區溢出漏洞的案例。
發(fā)現基于AUTOSAR的漏洞
讓我們看一下我們遇到的漏洞的簡化版本：
NvM_ReadBlock將(jiāng)從NVM讀取0x110字節，然後(hòu)將(jiāng)其寫入myVar的位置。雖然NvM_ReadBlock會(huì)準确地寫入myVar的值，但之後(hòu)它仍將(jiāng)繼續用不可預測的值覆蓋鄰近的全局變量。
在我們發(fā)現的案例中，NvM_ReadBlock被(bèi)設置爲在堆棧上執行越界寫入操作，這(zhè)可能(néng)會(huì)覆蓋函數的返回地址。
在這(zhè)個具體案例中，對(duì)易受攻擊函數的調用被(bèi)MCU複雜的自定義工作流程所掩蓋。然而，它仍然是可觸發(fā)的，并且确實導緻了執行崩潰。
緩解威脅
代碼生成(chéng)之後(hòu)，管理源代碼中與NvM API一起(qǐ)使用的變量大小就(jiù)完全是開(kāi)發(fā)人員的責任了。因此，AUTOSAR開(kāi)發(fā)人員應當盡一切努力在配置器中對(duì)齊變量和NVM塊的大小。AUTOSAR開(kāi)發(fā)人員還(hái)應當避免修改生成(chéng)的代碼，除非他們完全理解有關NVM塊大小的約束。
此外，沒(méi)有NVM函數可以提供NVM塊的大小來執行如下檢查：assert(sizeof(myVar) == NvM_BlockSize(Block_ID))；這(zhè)是因爲塊大小被(bèi)硬編碼到NvM模塊配置中，并被(bèi)視爲内部數據。
即使在使用AUTOSAR這(zhè)樣(yàng)的标準化框架時(shí)，在某些情況下，也可能(néng)無意中引入重大的内存漏洞。爲了減少這(zhè)種(zhǒng)情況，強烈建議采用持續的質量保證措施和定期的滲透測試。
總結
雖然AUTOSAR爲汽車軟件開(kāi)發(fā)提供了一個穩健而标準的框架，但由于使用不當，特别是在NvM API的變量管理中，仍然可能(néng)出現潛在的漏洞。随著(zhe)汽車技術越來越複雜，有必要通過(guò)持續的質量保證和定期的滲透測試來加強軟件安全性。這(zhè)些實踐，加上對(duì)正在使用的框架的深刻理解，可以幫助開(kāi)發(fā)人員降低潛在的安全風險，并提高汽車系統的整體安全性。