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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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