Android安全性漏洞 (CVE):補丁級別和廠商如何影響漏洞暴露

創提科技
2026/09/16

分享到

轉載自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。


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

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

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


在這篇關於CVE匹配的第二篇博客文章中,我們將通過分析Android作業系統的CVE來探討這兩項限制。


僅版本的CPE問題

每當穀歌發佈影響Android作業系統的CVE時,他們會附上只顯示受影響系統到Android OS版本的CPE(例如 cpe:2.3:o:google:android:10)。這些CVE通常會在他們發佈修復這些CVE的Android補丁級別的當天發佈。


這些補丁會在《Android 安全公告》中有所記錄,表格會詳細說明哪些CVE在哪個AOSP版本上被修復,以及屬於哪個補丁級別。在下面的截圖中,我們可以看到,例如,如果你應用了2025-03-01補丁級別,CVE-2024-0032就會在 12、12L、13、14上被修復。

2025年3月Android安全公告-1.png

2025年3月Android安全公告列出了多個影響Framework的CVE


這意味著,等到Android作業系統的CVE資訊發佈時,其CPE資訊可能已經過時無效了,無法準確反映當前補丁狀態。


仍以上面的示例為例,如果您的固件當前運行在Android 12 系統上,且補丁級別為 2025-03-01,那麼 CPE 匹配會認為 CVE-2024-0032 影響到了您,但實際上並非如此。


Android CPE 通常會識別出“google:android”以及作業系統版本。這足以發現可能存在的CVE,但Android的修復機制是通過每月發佈的安全補丁級別來體現的。因此,兩台報告運行Android 13的設備,其安全風險可能截然不同,這取決於它們的補丁級別是在解決某個CVE的公告之前還是之後。


補丁級別是版本語義的一部分

為了探究這一補丁級別差距有多大,我們收集了所有至少有一個CPE屬於google:android的CVE。在6,512個CVE中,有4,847個不同的CVE出現在Android安全公告中。


我們收集了從4.4.4到17的每個明確的Android作業系統標籤。諸如“16 QPR2”和“16-qpr2”之類的等效拼寫會被規範化一個標籤;而點版本和12L則保持獨立。這產生了21個用於分析的明確版本標籤。此外,還有2,876個公告CVE缺少可用的明確版本標籤,但仍然被計入整體覆蓋統計中。恰好有2個 CVE在公告的Linux內核部分帶有6.1標籤;追蹤保留了該證據,但該標籤未包含在Android OS圖表中。


注:“原始候選項”並不意味著存在風險,“已移除”也不一定意味著該NVD記錄在歷史上有誤。前者是基於版本的發現結果;後者則是基於明確的補丁級證據所做的評估調整。


對於每個作業系統標籤,“最新補丁版本”指的是在固定公告資料中明確可用的該作業系統的最新補丁級別。對於已停止支持的版本,這指的是其可達到的最終級別,而非當前日曆月。


上下文決策採用我們內部的“Android AOSP 規則”語義。如果被測試的作業系統版本等於或高於公告中明確指明的版本,且其補丁級別等於或晚於公告的補丁日期,則該規則會形成支援“不受影響”方向的證據。如果上述任一條件未滿足,該候選項仍保留。當無法獲取版本資訊時,將保守地以補丁日期作為判定依據。沒有公告規則支援的原始候選項仍保留為候選項,並被計為補丁級別證據不足。

根据补丁级别上下文筛选仅限 Android 版本的候选项-1.png

根據補丁級別上下文篩選僅限特定 Android 版本的候選項


對於已達到最終可用補丁版本的Android 4.4.4,共有893個僅限該版本的候選項進入比較範圍,最終剩餘253個,候選項數量減少了71.7%。對於已鎖定最新補丁版本的Android 16,相應數量分別為206和19,減少了90.8%。


請注意,這些橫條圖並不是用來比較支持生命週期的。舊版本的可用公告日期較少,而且資料集會隨時間變化。


規則覆蓋率說明了候選項減少比例無法反映的問題

關於某個Android作業系統CVE是否影響特定版本和補丁級別的中繼資料來自Android安全公告,因此按版本統計的公告覆蓋率是一個有效的衡量指標。通過這種方式,我們可以發現資訊收集中的潛在缺口。


下面的覆蓋率圖表將每個版本的原始受影響群體分為兩類:一類是具有可用安全公告規則的候選物件,另一類是缺乏充分補丁級別證據的候選物件。覆蓋率可能很高,但消除率卻很低:安全公告可能會明確指出,經過測試的版本或補丁級別仍然受到影響。反之,覆蓋率不足絕不能作為移除的依據。

按版本划分的 Android 安全公告规则覆盖范围-1.png

按版本劃分的 Android 安全公告規則覆蓋範圍


在8.x版和12版之間存在一個明顯的下降趨勢。我們最初的假設是,這是由特定供應商的 CVE 引起的,但當時並不清楚究竟是哪家供應商導致的。請繼續閱讀,您會找到原因。


供應商背景與作業系統的發展歷程相互交織

儘管這些漏洞都與Google:android CPE相關,但Android CVE並非在所有設備上都具有普遍適用性。其中相當一部分CVE僅影響高通、三星、聯發科或 LG等製造商的定制代碼。


該資訊既可在CVE描述中查看,也可在參考資料中查看,參考資料通常會連結到供應商的特定資源。


此類案例的一個典型例子是 CVE-2024-34663,該漏洞報告涉及 libquram(一款僅存在于三星設備上的圖像解碼庫),並將其與 google:android CPE 相關聯:

CVE-2024-34663-1.png

CVE-2024-34663,一個影響三星 libquram.so 的漏洞


這些“錯誤”的CPE來自相關廠商,而在此具體案例中,是“三星移動(三星電子有限公司的移動通信業務)”發佈的CNA。我們認為這些CPE有誤,因為它們認為任何運行Android 12、13或14版本的Android設備都受到一個僅存在于三星設備上的漏洞的影響。而且,即使在三星設備中,也並非所有設備都嵌入了libquram。


通過繪製各廠商特定 CVE 的分佈圖,我們發現 21% 的 Android 作業系統 CVE 屬於廠商特定 CVE:

按去重后的供应商上下文划分的 Android CVE 占比-1.png

按去重後的供應商上下文劃分的Android CVE占比


圖中列出的類別包含387個高通、533個三星、63個聯發科和46個LG的CVE。具有多個已識別供應商信號的CVE 在“多供應商”類別中僅計數一次;未包含上述任一單一信號的CVE則仍歸類於“其他Android CVE”。


為了驗證Android 8.x至12版本中公告規則覆蓋率較低是否與廠商特定CVE數量增加同時發生,我們使用與目錄級視圖相同的去重廠商類別,對每個版本的原始NVD資料集進行了劃分。從Android 7.0到12版本,我們已經可以看到三星在廠商中的占比呈上升趨勢。

按版本划分的 Android CVE 中的供应商背景-1.png

按版本劃分的 Android CVE 中的供應商背景


僅憑聚合分佈無法確定造成這一現象的主要因素,因此我們針對每個受測版本,將供應商類別與公告規則覆蓋範圍按規範的 CVE 標識進行了關聯。

Android 8.-1.png

該合併結果表明,三星是導致從Android 8.x到12版本總體覆蓋率較低的主要因素。在Android 8.0、8.1、9或12版本中,沒有一個標記為三星的候選漏洞被安全公告規則覆蓋;在Android 10版本中,305個候選漏洞中僅有1個被覆蓋;在Android 11版本中,249個候選漏洞中僅有1個被覆蓋。高通在同一版本範圍內的覆蓋率始終維持在97.2%至97.8%之間,這印證了高通CVE通常包含在Android安全公告補丁規則中的假設。


在該區間內,被標記為“三星”的候選項占缺乏公告規則證據的候選項的64.8%至92.9%。圖表中的確定性反事實分析僅從各版本的分母中剔除了這些行:Android 10的覆蓋率從69.5%上升至86.6%,Android 12的覆蓋率從81.9%上升至98.4%,從8.0到12的每個版本均呈現相同的變化趨勢。


應用名稱是身份標識,而不是用來重複計數的標籤

對於確實影響特定 Android 作業系統版本和補丁級別的 CVE,如果它們僅影響您未在固件中集成的特定 AOSP 應用程式,那麼這些漏洞可能不會影響您的固件。


這些內容可能可以表示為 <target_sw> CPE 欄位,或者通過 Android 應用套裝程式的自訂 PURL(例如 pkg:aosp/com.google.android.nfc@1.0)來實現,而不是使用萬用字元來匹配整個作業系統。


我們針對 Android 作業系統制定了一些應用程式特定規則,這些規則涵蓋了部分(但並非全部)應用程式特定的 CVE。具體內容如下:


针对特定应用的 Android 上下文,按包标识进行去重-1.png

針對特定應用的 Android 上下文,按包標識進行去重


對比樣本包括92個藍牙、30個NFC、21個“設置”、20 個“通話”、4個 Keymaster 以及3個 Wi-Fi 相關的安全性漏洞(CVE)。“其他應用程式特定”類別收錄了上述命名組之外的包範圍內的發現;“非應用程式特定”類別則包含沒有應用程式規則的安全性漏洞(CVE)。


要點總結

僅基於Android作業系統版本進行簡單的CVE匹配是不夠的,這會導致報告大量誤報。


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

確保該CVE影響您固件當前運行的版本和安全補丁級別,從而在Android 16上將候選CVE數量減少 90%;

當CVE與特定供應商相關聯時,確保您的固件由該供應商生產,或運行在該製造商的晶片組上;

當CVE影響特定的Android套裝軟體時,確保您的固件嵌入了該Android 應用程式。


由於谷歌和廠商提供的CPE資訊品質較低,這些工作我們不得不自己來完成。在理想情況下,Android團隊應維護與Android CVE相關的CPE條目:始終在CPE的“update”欄位中提供安全補丁級別;當CPE影響AOSP包時,在“target_sw”欄位中提供包名;並對三星或LG等主要廠商發佈的特定于廠商的條目中的資料提出異議或進行修正。


與此同時,您可以放心,我們的平臺會為您過濾掉無關資訊,讓您能夠專注於真正影響您的Android固件和設備的問題。