如果被利用，這些漏洞可能允許攻擊者未經授權訪問敏感信息或通常會導致問題
最近 思科Talos （思科系統公司網路安全研發部門） 廣為人知，透過部落格文章，有關發現的信息 Buildroot 建置系統中存在許多漏洞。
思科Talos 我提到發現了六個漏洞 在建置根目錄中 這允許， 在攔截過境交通 (MITM) 期間， 更改生成的系統映像或排程代碼執行 在建構系統中。
前五個漏洞 編目於 塔洛斯-2023-1844 (CVE-2023-45841, CVE-2023-45842, CVE-2023-45838, CVE-2023-45839, CVE-2023-45840) 影響程式碼以使用雜湊值驗證資料包的完整性.
問題 它們歸結為使用 HTTP 下載檔案的能力以及缺乏檔案驗證雜湊值 對於某些資料包，允許替換這些資料包的內容，有機會幹擾建置伺服器的流量（例如，當使用者透過攻擊者控制的無線網路進行連接時）。
由於套件中可能包含補丁檔案或 Makefile，因此透過提供受損的來源包，攻擊者可以在編譯器中執行任意命令。直接後果是，攻擊者還可以更改為 Buildroot 目標和主機產生的任何檔案。
特別是，aufs 和 aufs-util 套件是透過 HTTP 載入的，並且不與雜湊值進行比較。還缺少 riscv64-elf-toolchain、versal-firmware 和 mxsldr 軟體包的雜湊值，這些軟體包預設透過 HTTPS 加載，但在出現問題時會回退到未加密的下載。如果沒有「.hash」文件，Buildroot 工具會認為驗證成功並處理下載的軟體包，包括應用軟體包中包含的任何修補程式並執行建置腳本。
透過欺騙下載的軟體包，攻擊者可以向其中添加自己的修補程式或 Makefile，從而允許對生成的映像進行更改或建立系統腳本並執行其程式碼。
在一部分 第六個漏洞 被分類為 塔洛斯-2023-1845 （CVE-2023-43608） 是由於功能實現中的錯誤所引起的 BR_NO_CHECK_HASH_FOR, 這允許您禁用檢查 所選資料包的哈希完整性。
有人提到 段：
.hash 檔案中的每個哈希行稱為 check_one_hash。如果哈希不匹配，check_one_hash 將退出並顯示錯誤代碼。否則，nb_checks 會遞增以指示檢查成功。如果 .hash 檔案中沒有條目來檢查指定的輸入文件，則 IF 條件中的檢查將傳回錯誤，除非 BR_NO_CHECK_HASH_FOR[9] 包含此特定文件，這表示該文件被排除在雜湊檢查之外。
總的來說， 有3種方法可以檢查哈希返回值0:
- .hash 包不存在文件
- $file hash 與 .hash 檔案的定義匹配
- $file 不存在於 .hash 檔案中，且 BR_NO_CHECK_HASH_FOR 包含套件的基本名稱（明確繞過檢查）
對於漏洞演示的概念，“ 開發人員專注於選項 3， 因為這似乎通常用於繞過無法輕鬆散列的資源的完整性檢查（例如經常更改的開發資源）。在建立套件的特定版本時也會使用它，因為 Buildroot 來源中可能不提供該版本的雜湊值。
某些軟體包（例如 Linux 核心、U-Boot 和 versal-firmware）允許載入尚未產生驗證哈希的最新版本。對於這些版本，使用了 BR_NO_CHECK_HASH_FOR 選項，該選項會停用雜湊驗證。
資料是透過 HTTPS 下載的，但預設情況下，如果下載失敗，則使用替代方法透過 http:// 協定存取不加密的網站。在 MITM 攻擊期間，攻擊者可能會阻止與 HTTPS 伺服器的連接，然後回滾下載。
最後，應該提到的是 最新 Buildroot 版本中的漏洞已解決 如果你有興趣能夠了解更多，可以查閱詳情 在下面的鏈接.