LWN：內(nèi)核CVE編號是如何分配的！

關(guān)注了就能看到更多這么棒的文章哦～

How kernel CVE numbers are assigned

June 19, 2024

This article was contributed by Lee Jones
Gemini-1.5-flash translation
https://lwn.net/Articles/978711/

距離 Greg Kroah-Hartman 和 MITRE 宣布 Linux 內(nèi)核項(xiàng)目成為其自身的 CVE 編號機(jī)構(gòu) (CNA) (CVE Numbering Authority) 已經(jīng)過去四個月了。從那時起，Linux CNA 團(tuán)隊(duì)就一直在建立工作流程和機(jī)制，以幫助管理與這一挑戰(zhàn)相關(guān)的各種任務(wù)。然而，社區(qū)成員似乎對團(tuán)隊(duì)一直在使用的流程和規(guī)則缺乏了解。本文由 Linux 內(nèi)核 CNA 團(tuán)隊(duì)成員撰寫，其主要目的是闡明團(tuán)隊(duì)的工作方式以及內(nèi)核 CVE 編號的分配方式。

早期的 CVE 公告引發(fā)了一些問題，包括 在郵件列表中 以及其他一些地方。Linux CNA 團(tuán)隊(duì)收到了堅定支持的信息，特別是來自那些致力于 Linux 安全的人。其他一些表達(dá)擔(dān)憂的意見主要來自分發(fā)商和維護(hù)企業(yè)平臺的團(tuán)隊(duì)，這些團(tuán)隊(duì)試圖通過盡可能少的變更來保持穩(wěn)定和安全。提出的一些較強(qiáng)有力的觀點(diǎn)是，CVE 數(shù)量的增加將增加工作量，并壓垮那些試圖審查所有 CVE 的安全團(tuán)隊(duì)。其他人則認(rèn)為，發(fā)行版和企業(yè)級別的 CVE 用戶，特別是那些為這項(xiàng)服務(wù)付費(fèi)的用戶，應(yīng)該一直在審查穩(wěn)定版中提交的所有代碼，以查找對相關(guān)安全漏洞的修復(fù)。一位獨(dú)立的安全維護(hù)者對付費(fèi)分發(fā)版沒有審查除了那些被識別為 CVE 候選者的穩(wěn)定修復(fù)之外的其他 fix 感到特別震驚，因?yàn)樗麄儽緛響?yīng)該這樣做。

無論貢獻(xiàn)者站在哪一邊，幾乎所有人都同意：由于各種原因，舊的 CVE 流程運(yùn)行得不好。LWN 在 這篇最近的文章 中列出了許多主要觀點(diǎn)。另一個值得關(guān)注的要點(diǎn)是，許多下游維護(hù)者（包括我在內(nèi)，盡管 Android 有來自長期支持穩(wěn)定內(nèi)核的定期合并的額外安全保障）對 cherry-picking 所有相關(guān) CVE 并將其視為持續(xù)安全更新的良好做法感到滿意。當(dāng)然，這種做法會導(dǎo)致一種錯誤的安全感，因?yàn)樗z漏了數(shù)百個與安全相關(guān)的修復(fù)，最終會導(dǎo)致內(nèi)核安全性降低。

新的流程更加全面，旨在識別每個修復(fù)潛在安全問題的提交。有些人提到他們認(rèn)為這種策略有點(diǎn)過于熱心，然而，自從我們在 2 月份開始這項(xiàng)工作以來，它只在 v6.7.1 和 v6.8.9 之間的 16,514 次提交中分配了 863 個 CVE 編號。這僅僅是 5% 的比例。

Kroah-Hartman 和其他人分享的歷史想法以及對當(dāng)前文獻(xiàn)的誤解加劇了負(fù)面意見。在關(guān)于 2019 年 內(nèi)核食譜討論 的一篇文章中，Kroah-Hartman 被轉(zhuǎn)述為說：“下一個選項(xiàng)，‘燒毀它們’，可以通過為應(yīng)用于內(nèi)核的每個補(bǔ)丁請求 CVE 編號來實(shí)現(xiàn)?！?事實(shí)上，該計劃從未打算制造大量的 CVE 編號來壓倒當(dāng)前系統(tǒng)，從而使其最終被放棄，而且這種情況也從未接近成為現(xiàn)實(shí)。Linux CNA 團(tuán)隊(duì)謹(jǐn)慎地將 CVE 分配降到最低，只為對安全構(gòu)成潛在風(fēng)險的漏洞分配編號。

不幸的是，文檔 中的一些說法并不能很好地消除這些擔(dān)憂。例如，這部分內(nèi)容經(jīng)常被引用：

因此，CVE 分配團(tuán)隊(duì)過于謹(jǐn)慎，正在為他們識別到的任何錯誤修復(fù)分配 CVE 編號。這解釋了 Linux 內(nèi)核團(tuán)隊(duì)發(fā)布的 CVE 數(shù)量似乎很大。

這部分內(nèi)容經(jīng)常被誤解或被過分地理解。關(guān)于為“任何錯誤修復(fù)”分配 CVE 編號的部分應(yīng)該擴(kuò)展為“任何與內(nèi)核安全態(tài)勢相關(guān)的錯誤修復(fù)”。例如，修復(fù)損壞的 LED 驅(qū)動程序的修復(fù)永遠(yuǎn)不會被考慮來分配 CVE。也就是說，這樣規(guī)定了問題的確切類型之后數(shù)量就會大大減少。最近有人嘗試這樣做，并提交給 [email protected] 進(jìn)行預(yù)審查，但立即被該組拒絕。然而，我尋找的非詳盡考慮清單包括緩沖區(qū)溢出、數(shù)據(jù)損壞、崩潰 (BUGs 、oops 和 panic，包括受 panic_on_warn 影響的那些)、使用后釋放 (UAF)、鎖死、雙重釋放、拒絕服務(wù) (DoS)、數(shù)據(jù)泄露等。

一個不時出現(xiàn)的問題可以概括為：“為什么我們?nèi)绱藷嶂杂诖?，為什么我們不能只為?yán)重的安全性修復(fù)創(chuàng)建 CVE？”；答案是質(zhì)量評估是一項(xiàng)不可能的任務(wù)。由于內(nèi)核是無限可配置和可適應(yīng)的，因此無法知道它可以部署和使用的所有方式。評估潛在的漏洞并將通用的漏洞可達(dá)性、嚴(yán)重性和影響級別相關(guān)聯(lián)是不可行的。在一個平臺上無法利用的漏洞可能在另一個平臺上很容易被利用。即使一個特定問題可以被證明是普遍來說都是低風(fēng)險的，它仍然可能被用作更復(fù)雜、更鏈?zhǔn)焦糁械囊粋€墊腳石。由于所有這些原因以及更多原因，我們發(fā)現(xiàn)最明智的方法是假設(shè)“安全漏洞就是漏洞”，并為任何可能與安全相關(guān)的任何問題分配編號。

Linux CNA 團(tuán)隊(duì)不會輕易進(jìn)行 CVE 編號分配，這個過程也不是自動化的。在第一個完整版本 (6.7.y) 中，這個過程包括團(tuán)隊(duì)中的所有三名成員（Greg Kroah-Hartman、Sasha Levin 和我）手動審查每個打入穩(wěn)定分支的補(bǔ)丁，并對每個補(bǔ)丁進(jìn)行投票。如果一個提交獲得了三個贊成票，就會分配一個 CVE 編號。獲得兩票的提交將接受第二次審查，然后進(jìn)行討論。

團(tuán)隊(duì)成員以各種方式來 review 這些改動。其中一人使用 Mutt 以與他們審查 mainline 補(bǔ)丁提交完全相同的方式進(jìn)行審查，另一人正在訓(xùn)練一個機(jī)器學(xué)習(xí) (ML) 模型來識別難以發(fā)現(xiàn)的問題，而我更喜歡把 Git 輸出用管道傳輸給一個輔助工具，該工具突出顯示了容易獲得“Yes”投票的典型代碼樣例?！癗o”投票需要更多時間來審查。目前的想法是，通過使用不同的工具和方法，我們的正面結(jié)果將更加穩(wěn)??；至少理論上是這樣。

一旦 CVE 創(chuàng)建完成，它們就會提交到 linux-cve-announce 郵件列表，感興趣的人們可以在閑暇時審查它們。SUSE 的工程師在這方面功不可沒。他們在對那些以前的 CNA 以不可搜索的方式提到的重復(fù) CVE，或者是不值得分配 CVE 最終分配 CVE 的過程中發(fā)揮了重要作用。他們的意見幫助塑造了團(tuán)隊(duì)現(xiàn)在進(jìn)行分析的方式。任何人都可以自由地 review 甚至被鼓勵來 review 我們的 linux-cve-announce 列表，并回復(fù)他們認(rèn)為無效的 CVE。如果團(tuán)隊(duì)同意這個判定，則 CVE 分配將被立即拒絕。自從這項(xiàng)工作開始以來，已經(jīng)發(fā)生了 65 起這樣的情況。

希望這有助于澄清目前關(guān)于用于審查、識別和處理 CVE 候選人的方法的一些誤解，并消除最近人們向我傳達(dá)的一些擔(dān)憂。具體來說，CVE 編號不是以自動方式分配的，它們只分配給可能合理地被認(rèn)為具有安全隱患的漏洞。該團(tuán)隊(duì)對建設(shè)性反饋和改進(jìn)的真正建議持開放態(tài)度；它致力于履行其責(zé)任，并在流程的所有階段都謹(jǐn)慎行事并盡職盡責(zé)。如果您有任何問題或建議，您可以使用內(nèi)核的 Documentation/process/cve.rst 文件中提供的聯(lián)系方式。我們很樂意收到您的來信。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～