在嵌入式系統與伺服器硬體中，U-Boot 扮演著至關重要的角色。它是一個啟動載入程序（Bootloader），負責在作業系統啟動前初始化硬體並載入核心。簡單來說，它是設備開機後執行的第一段複雜程式碼，決定了後續所有軟體的信任基礎。
最近安全研究公司 Binarly 發現了 U-Boot 中的六個漏洞，這些漏洞揭示了一個關鍵的安全盲點：即使系統實作了數位簽章驗證，但如果在驗證之前就對不可信的資料進行解析，依然會被攻擊者利用。
解析 FIT 映像檔的風險
U-Boot 使用一種稱為 FIT（Flattened Image Tree）的格式，將核心、設備樹（Device Tree）與記憶體磁碟（Ramdisk）等組件打包成一個單一映像檔。為了確保安全，U-Boot 會在將控制權移交給核心前，檢查該映像檔的數位簽章。
然而，問題出在驗證過程的順序。在 U-Boot 確認簽章是否正確之前，它必須先解析這個映像檔的結構，以便知道簽章在哪裡以及要驗證哪些內容。Binarly 發現，發現 U-Boot 在解析這些不可信映像檔時，對輸入資料的檢查不足，導致了記憶體損毀漏洞。
漏洞分類與技術原理解析
這六個漏洞可分為兩類：導致設備崩潰的拒絕服務攻擊（DoS），以及最高風險的任意程式碼執行（RCE）。
最危險的程式碼執行漏洞
漏洞 BRLY-2026-037 與 BRLY-2026-038 源於對 libfdt 函式庫中 fdt_get_name 的錯誤使用。libfdt 是 U-Boot 與 Linux 核心共用的設備樹解析庫。當 U-Boot 處理一個精心構造的惡意映像檔時，fdt_get_name 可能會回傳一個空指標（Null Pointer）以及一個負數長度。
U-Boot 在沒有檢查回傳值的情況下直接使用了這些數據。其中一個漏洞會導致空指標解引用，在某些記憶體佈局的設備上會觸發堆疊緩衝區溢位（Stack Buffer Overflow）。另一個漏洞則利用負數長度進行指標運算，導致程式向後讀寫記憶體，進而覆蓋掉函數的返回地址（Return Address）。一旦返回地址被篡改，攻擊者就能在啟動階段接管控制權。
導致設備崩潰的漏洞
其餘四個漏洞（BRLY-2026-039 至 BRLY-2026-042）主要導致系統崩潰。部分漏洞是因為過度信任映像檔中定義的大小或偏移量，導致讀取超出記憶體邊界；另一個則是透過深度嵌套的映像檔結構，觸發遞迴呼叫直到耗盡堆疊空間（Stack Exhaustion）。
為什麼這類漏洞極其危險
對於 Junior 工程師來說，最需要理解的是啟動鏈（Chain of Trust）的概念。
如果攻擊者能在作業系統啟動前就執行程式碼，他們就處於所有安全防線的底層。這意味著即使作業系統有強大的防毒軟體或權限管控，也無法偵測到運行在 Bootloader 層級的惡意代碼。
此外，一旦設備因為啟動漏洞而崩潰（Brick），恢復過程通常極其困難。這往往需要物理接觸硬體，使用外部燒錄器直接對快閃記憶體（Flash Memory）進行重新刷寫。
攻擊路徑與限制
雖然這些漏洞威力強大，但攻擊門檻較高。攻擊者必須能將惡意映像檔放入啟動路徑中，這通常需要物理接觸設備，或者已經取得了系統的高權限。
但值得注意的是，遠端攻擊依然可能。例如在某些伺服器管理控制器（BMC）中，如果管理介面存在漏洞，攻擊者可以利用遠端更新機制刷入惡意映像檔，無需物理接觸即可觸發 U-Boot 漏洞。
實務建議與總結
目前 U-Boot 官方已合併相關補丁，但由於發行週期限制，許多穩定版本尚未包含修復。
對於產品開發者與維護者，不能等待下一個正式版本發布，應立即從上游倉庫（Upstream）將相關 Commit 整合進自己的韌體分支中。對於終端用戶，則必須密切關注設備廠商提供的韌體更新。
這次事件再次提醒我們，安全驗證的順序至關重要。無論簽章演算法多強，只要解析過程（Parsing）存在漏洞，驗證機制本身就可能被繞過。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。