Linux內核CVE:回溯移植(Backports)如何改變漏洞暴露情況

創提科技
2026/08/20

分享到

轉載自www.onekey.com

介紹

為構建、集成或部署的固件生成軟體物料清單(SBOM)的目的,不僅在於瞭解其中包含哪些軟體元件及其版本,還在於將這些元件版本與已知的漏洞進行關聯。


傳統上,元件及其版本與一組已公開的漏洞之間的映射關係是通過通用平臺枚舉(CPE)來實現的。CPE是一個字串,它以以下格式明確定義了受影響的組件:cpe:<cpe_version> :<part>:<vendor>:<product>:<version>:<update>:<edition>:<language>:<sw_edition>:<target_sw>:<target_hw>:<other>,CPE本身與CVE相關聯。


對於可能已有記錄但未收錄在官方CVE資料庫中的漏洞,可使用PURL,其標準化格式如下:scheme:type/namespace/name@version?qualifiers#subpath。


該機制雖然運行良好,但存在兩個主要限制條件:

1. 正確性。CVE編號管理機構(CNA)會為其發佈的CVE分配正確的CPE,並維護這些CVE的CPE集合。

2. 表達能力。CPE並沒有提供足夠的資訊來說明CVE可達且可被利用的具體條件。這包括受影響的模組、函數、功能等。


我們將探討這兩個限制,並說明ONEKEY是如何應對這些問題的,以確保我們的客戶不會被大量的誤報淹沒。我們將通過兩個作業系統來說明我們的觀點:Linux 內核和Android作業系統。


今天,我們先從Linux內核開始講起。

 

Linux內核背景

通用平臺枚舉(CPE)用於標識安全公告所描述的產品及版本。這可以很好地説明CPE將元件清單與漏洞目錄關聯起來。


問題在於,當維護者進行補丁回溯移植至穩定分支時,Linux CNA似乎並不總是能及時更新CPE資訊。值得慶倖的是,ubuntu-cve-tracker、kernel-sec和cip-kernel-sec等專案維護著記錄回溯移植情況的資料集,更精確地記錄了補丁引入和修復的版本範圍,這使我們能夠優化從NVD CPE中提取的受影響版本資訊。


在本項分析中,我們使用了三個需謹慎對待的術語:

原始NVD候選項:合併前的NVD CPE匹配器包含經過測試的內核版本。

支持回溯移植的候選項:在通過ONEKEY的生產合併策略應用kernel-vulns和CIP分支範圍後,原始比較集合中的該成員仍然保留。

評估改進:額外的確定性證據會改變所需工作量或品質。我們僅將獨立證實未受影響的情況歸類為誤報。


我們使用的固定快照的原始NVD資料來源包含14,269個帶有 linux:linux_kernel CPE 匹配器的內核CVE。合併後的資料庫包含14,503個內核CVE,其中包括僅在安全公告中提及的CVE——這些CVE會單獨報告,而非被暗中計入縮減分母中。


穩定分支不會完全同步

主線修復程式通常會被回溯移植到仍在維護的穩定分支中。該修復程式可能會在不同的日期和子版本中分別合併到 4.14.x、5.4.y 和 5.15.z 版本中。因此,即使某個特定的穩定內核版本已經接收了該修復程式,僅基於上游版本確定的適用範圍仍可能在很長一段時間內仍可能有意保持較寬的範圍。


我們的流程保留了衡量此項所需的兩個階段。它首先從固定的原始程式碼樹中解析原始的NVD匹配項,然後應用一種合併策略:若有kernel-vulns資料則以該資料為准;CIP資料提供嵌入式LTS的歷史記錄,並由不衝突的NVD範圍填補空白。

11.png

在 Linux 4.4 的最終補丁發佈中,原始比較包含4,226個候選項,經過穩定分支上下文處理後剩餘2,692個,候選項減少了36.3%。在當前的Linux 6.18 補丁發佈中,相應的數量分別為77和58,減少了24.7%。


這些資料並不是衡量NVD品質的評分標準。NVD資料集是發現研究的基準;第二個資料集則利用更新且針對特定分支的證據,回答了一個更具情境性的問題。


在子版本中,回溯移植的情況才顯露出來

單一地“最新 LTS”版本的比較可能會掩蓋其中的機制。因此,對於4.14、5.4和5.15版本,我們分別選取了首個補丁版本、按時間順序排列的補丁系列的中間版本,以及最終或當前的補丁版本。在進行統計之前,就已確定了這一選取規則。

Linux 4.14-1.png

Linux 4.14:首個補丁版、中期補丁版和最終/當前補丁版


Linux 5.4-1.png

Linux 5.4:首個補丁版、中期補丁版和最終/當前補丁版


Linux 5.15-1.png

Linux 5.15:首個補丁版、中期補丁版和最終/當前補丁版


例如,首個Linux 5.15補丁版本僅將原始候選項從6,800個減少到了6,521 個支持回溯的候選項,減少了4.1%。最終/當前樣本中剩餘候選項為1,118 個,但早期較差的結果仍顯示在圖表中。


規則覆蓋不等於漏洞數量減少

版本細化仍無法告訴我們某個固件鏡像實際編譯進了那些內容。ONEKEY 會運行“自動化影響評估”,以確保我們不會報告實際上並不存在的問題:


自動影響評估功能會分析提取的固件檔,以識別並隱藏無法被利用的漏洞。本質上,該功能充當了一個篩檢程式,可幫助您專注於相關漏洞,從而簡化漏洞分級流程。


在以下情況下,該漏洞被視為“無法被利用”:

1. 受影響的版本與您的固件中的版本不同。

2. 該漏洞影響的是未被編譯進固件的功能或模組。

3. 該漏洞影響的是固件未實際使用的功能。


例如,如果某個漏洞只能通過藍牙被利用,但您的固件運行在未安裝藍牙子模組的Linux內核上,那麼該平臺會自動過濾掉該漏洞。


對於影響Linux內核的CVE,我們可以自動推導出兩種規則:

內核原始程式碼規則:將函數和原始檔案資訊關聯到CVE

架構規則:將架構資訊關聯到CVE


在掃描Linux固件時,我們會從內核本身及其所有內核模組中提取內核符號。這些符號會通過按版本劃分的查閱資料表映射到相應的檔和函數上。在此基礎上,我們可以結合內核原始程式碼規則,利用這些資訊來檢查相關代碼是否存在。


對於架構規則,我們只需檢查您的內核是否是為受特定 CVE 影響的架構構建的。


下圖顯示了各 Linux LTS 版本中內核原始程式碼規則和架構規則所占的比例。“任何自動化規則”這一項旨在展示自動化規則與手動編寫規則之間的比例。

22.png

我們在這裡刻意不減去那些受規則覆蓋的 CVE。一個源規則可以根據二進位檔案生成正向證據、負向證據,或者無法形成有效證據。同樣,架構上下文也需要檢測到的架構。規則覆蓋表示具備進一步自動評估的條件;縮減則需要具體的固件映射和明確的決策規則。


實際應用示例

為了使下一步工作更具針對性,我們分析了連續五個OpenWrt發佈的最終或當前補丁版本的官方Raspberry Pi 4 bcm27xx/bcm2711 squashfs工廠鏡像:21.02.7、22.03.7、23.05.6、24.10.7和25.12.5。

OpenWRT Raspberry Pi 4 镜像-1.png

OpenWRT Raspberry Pi 4 鏡像:發現、優化及影響證據


對於OpenWrt 21.02.7,內核檢測功能識別出了跟蹤記錄中記錄的版本,並生成了4,479個原始NVD候選項。通過考慮回溯移植情況的版本範圍篩選,從該比對樣本中剔除了802個項。在同一組 NVD 比對樣本中,自動化影響評估隨後得出了2,830個負分匹配、80個零分匹配和767個正分匹配的最終結果。


對於OpenWrt 25.12.5,相同的固定流程從292個原始候選項開始,通過考慮回溯移植的範圍剔除 80 個,最終在該比較樣本集中,根據所有評分符號得出 212 個最終匹配項。


該評分是證據權衡的結果,並非 CVSS 的替代方案,也不是可利用性判定的標準。負分意味著根據配置的規則,收集到的自動化證據傾向於表明該漏洞不會對當前固件產生影響。零分意味著分析發現了候選漏洞,但未改變證據權衡的結果。正分則表示發現了支持性證據。


因此,針對該特定的OpenWRT構建目標,我們的方法在5個版本中平均將CVE數量減少了78.6%(在21.02.7版本中減少了81%,在25.12.5版本中減少了79%)。


要點總結

僅根據 Linux 內核版本進行簡單的CVE匹配是不夠的,這會導致報告大量誤報。這是因為缺乏具體產品/固件上下文資訊(即內核的哪個部分受到影響),以及在將修復補丁回溯移植至穩定的主線/LTS 分支後,CVE記錄未能及時更新。


在ONEKEY,我們通過以下方式解決這個問題:

確保您編譯的Linux內核確實包含了受特定CVE影響的元件或子元件

我們不會報告那些已經在你構建的分支上通過回溯移植補丁修復的CVE


由於Linux內核CNA提供的CPE資訊品質有限,我們不得不親自完成這些工作。在理想情況下,每當應用回溯補丁時,Linux安全團隊都會維護與Linux 相關的CPE。


與此同時,您可以放心,我們的平臺會為您過濾掉無關漏洞和雜訊,讓您能夠專注於真正影響您Linux固件和設備的問題。實驗表明,在OpenWRT樣本中,即使在尚未對剩餘CVE附帶的CVSS、SSVC或KEV資訊應用篩檢程式的情況下,信息量減少幅度也高達82%。


在下一期中,我們將介紹如何在Android 作業系統中採用類似的方法。