1. 簡介

U-Boot 是廣泛應用於各類硬體平台的開源啟動載入程式(open-source bootloader)，涵蓋嵌入式裝置、路由器及基板管理控制器 (Baseboard Management Controllers, BMC)。作為開機程序中的主要元件，U-Boot 負責硬體初始化，並將執行權轉移至後續階段（如作業系統核心）。由於其屬於最先執行的程式碼之一，其安全性對整體系統的完整性至關重要。此層級的任何危害都可能繞過後續的安全機制，包含 Secure Boot 與 Root of Trust (RoT) 機制 [1] 。

現代啟動載入程式實作已演化出複雜的功能，如網路啟動、檔案系統解析及映像驗證(Image verification)。儘管這些功能提高了靈活性，但也顯著擴大了攻擊面 [2] 。報告分析 U-Boot 的 Flattened Image Tree (FIT) 簽章驗證邏輯中所發現的一系列重大漏洞，FIT 是封裝(packaging)可開機映像(Bootable image)的標準格式。這些漏洞由 Binarly 研究團隊發現，範圍從阻斷服務 (DoS) 到潛在的任意程式碼執行，影響自 v2013.07 以來的多個穩定版本 [1] 。

你的Secure Boot真的安全嗎？U-Boot FIT簽章漏洞讓攻擊者長驅直入！ | 資訊安全新聞

2. 技術背景

2.1 FIT 映像結構

FIT 映像使用 Flattened Device Tree (FDT) 格式。它們將多個元件（如核心、ramdisk 及裝置樹 blob）捆綁為單一檔案。FIT 映像中的每個元件都包含 hash 與數位簽章，以確保完整性及真實性。U-Boot 中的 Verified Boot 機制依賴這些簽章，在執行前驗證映像 [1] 。

2.2 FDT 解析與驗證邏輯

驗證程序涉及使用如 fdt_find_regions 的函式走訪 FDT 結構。此函式識別 FIT 映像中必須進行 hash 與驗證的特定區域。在走訪過程中，啟動載入程式會解析各種標籤與屬性，例如 FDT_BEGIN_NODE 與 hashed-strings ，以判斷映像中哪些部分屬於受信任的設定 [1] 。

3. 漏洞分析

研究識別出六個不同的漏洞（BRLY-2026-037 至 BRLY-2026-042）。報告聚焦於簽章驗證階段中最嚴重的記憶體損壞(Memory corruption)與邏輯繞過(Logic bypass)缺陷。

3.1 空指標取值與緩衝區溢位（BRLY-2026-037）

漏洞 BRLY-2026-037 源於 fdt_get_name 函式，在特定條件下（例如處理格式異常的 FDT 結構或較舊的 FDT 版本（低於 0x10），且節點名稱缺少斜線 '/'）可能回傳 NULL 指標 [1] 。 

  1. /* Code snippet from fdt_get_name in scripts/dtc/libfdt/fdt_ro.c */
  2. const char *fdt_get_name(const void *fdt, int nodeoffset, int *len)
  3. {
  4.     ...
  5.     if (!can_assume(LATEST) && fdt_version(fdt) < 0x10) {
  6.         const char *leaf;
  7.         leaf = strrchr(nameptr, '/');
  8.         if (leaf == NULL) {
  9.             err = -FDT_ERR_BADSTRUCTURE;
  10.             goto fail;
  11.         }
  12.         nameptr = leaf + 1;
  13.     }
  14.     ...
  15. fail:
  16.     if (len)
  17.         *len = err;
  18.     return NULL;
  19. }

fdt_find_regions 函式呼叫了 fdt_get_name ，但未檢查回傳值。若回傳 NULL ，後續的 strcpy 操作會使用 NULL 來源位址，導致 DoS 或在 zero page 對映時引發潛在的程式碼執行 [1] 。

3.2 Stack Buffer Underflow（BRLY-2026-038）

BRLY-2026-038 利用 fdt_get_name 中相同未檢查的回傳值。當該函式失敗時， len 參數會被填入負的錯誤碼（例如 -11 代表 FDT_ERR_BADSTRUCTURE ）。在 fdt_find_regions 中，此負值會導致目的地指標 end 向後移動而非向前，造成 Stack Buffer Underflow [1] 。 

  1. /* Vulnerable logic in fdt_find_regions */
  2. if (end - path + 2 + len >= path_len)
  3.     return -FDT_ERR_NOSPACE;
  4. if (end != path + 1)
  5.     *end++ = '/';
  6. strcpy(end, name);
  7. end += len; // Underflow occurs here if len is negative

3.3 簽章驗證序列分析

以下序列圖說明了在處理格式異常的節點名稱時，FIT 映像解析器與簽章驗證邏輯之間的脆弱互動。

sequenceDiagram participant FIT as FIT Image participant Parser as fdt_find_regions participant LibFDT as fdt_get_name participant Memory as Stack Buffer FIT->>Parser: FDT_BEGIN_NODE tag Parser->>LibFDT: Request node name (offset) Note over LibFDT: Version < 0x10 & No '/' in name LibFDT-->>Parser: Return NULL, len = -11 (Error) Note over Parser: Missing NULL check for name Parser->>Memory: strcpy(end, NULL) -> Potential Crash Parser->>Memory: end += len (-11) -> Pointer moves backward Note over Parser: Subsequent writes overwrite stack frame

4. 比較分析與緩解措施

傳統的啟動載入程式安全性通常著重於防止透過 Debug shell 或開機參數操縱來注入未經授權的 initramfs [2] 。雖然這類攻擊需要實體存取及特定設定，但 FIT 簽章漏洞（BRLY-2026-037/038）更為根本，因為它們針對的是密碼學驗證引擎本身。若驗證邏輯可透過格式異常的映像結構被瓦解，則整個 Secure Boot chain 將形同虛設 [1] 。

漏洞類型 主要原因 影響 緩解策略
記憶體損毀 (FIT) 未檢查 FDT 解析函式的回傳值 DoS，任意程式碼執行 實作嚴謹的 NULL 檢查並驗證 'len' 參數
邏輯繞過 (Initramfs) 未受保護的 Debug shell 與開機參數 未經授權的程式碼執行，持續性 於正式環境中停用 Debug shell；強制使用已簽章的開機參數 [2]

5. 結論

在 U-Boot 的 FIT 簽章驗證程序中所發現的漏洞，凸顯了安全關鍵元件中複雜解析邏輯所帶來的風險。在簽章驗證完成前即可觸發記憶體損毀，對依賴 U-Boot 作為 Root of Trust 的嵌入式系統構成重大威脅。處理這些問題不僅需要修補特定的空指標與 Underflow 錯誤，還需採用更具韌性的編碼實務，在開機程序的所有階段中預期並處理格式異常的輸入 [1] 。

參考文獻

  1. Unfit to Boot: Breaking U-Boot's FIT Signature Verification
  2. Debug shell引發Initramfs危機：安全開機防護策略
  3. 用AI守護開機安全：啟動載入程式漏洞全解析