本文來自微信公眾號“嘶吼專業(yè)版”，作者/胡金魚。
流行的開源項(xiàng)目“ip”的GitHub存儲庫最近被其開發(fā)人員存檔或設(shè)為“只讀”，由于Fedor Indutny的項(xiàng)目收到了CVE報(bào)告，因此網(wǎng)上有人開始向他報(bào)告這個(gè)漏洞。
不幸的是，Indutny的案例并非孤例。近年來，開源開發(fā)者收到的有爭議的CVE報(bào)告數(shù)量不斷增加，有些甚至是未經(jīng)確認(rèn)的偽造CVE報(bào)告。
這可能會(huì)導(dǎo)致這些項(xiàng)目的用戶產(chǎn)生不必要的恐慌，并且安全掃描程序會(huì)生成警報(bào)，而所有這些都會(huì)成為開發(fā)人員的頭痛之源。
“node-ip”GitHub存儲庫已存檔
本月初，“node-ip”項(xiàng)目的作者Fedor Indutny將該項(xiàng)目的GitHub存儲庫存檔，實(shí)際上使其成為只讀的，并限制了人們打開新問題（討論）、拉取請求或向項(xiàng)目提交評論的能力。
node-ip GitHub repo已存檔并設(shè)為“只讀”
“node-ip”項(xiàng)目作為“ip”包存在于npmjs.com注冊表中，每周下載量達(dá)1700萬次，是JavaScript開發(fā)人員使用的最受歡迎的IP地址解析實(shí)用程序之一。
6月底，Indutny在社交媒體上表達(dá)了存檔“node-ip”背后的理由與CVE-2023-42282有關(guān)，這是該項(xiàng)目今年早些時(shí)候披露的一個(gè)漏洞。
使用其他開放項(xiàng)目（例如應(yīng)用程序中的npm包和依賴項(xiàng)）的Node.js開發(fā)人員可以運(yùn)行“npm audit”命令來檢查其應(yīng)用程序所使用的這些項(xiàng)目中是否有針對它們的漏洞報(bào)告。
Bothered dev的開發(fā)人員在社交媒體上表達(dá)了他的擔(dān)憂
該CVE與實(shí)用程序無法正確識別以非標(biāo)準(zhǔn)格式（例如十六進(jìn)制）提供給它的私有IP地址有關(guān)。這會(huì)導(dǎo)致“node-ip”實(shí)用程序?qū)⑺接蠭P地址（十六進(jìn)制格式）如“0x7F.1...”（代表127.1...）視為公共IP地址。
如果應(yīng)用程序僅依賴node-ip來檢查提供的IP地址是否公開，則非標(biāo)準(zhǔn)輸入可能會(huì)導(dǎo)致受影響的實(shí)用程序版本返回不一致的結(jié)果。
“可疑”的安全影響
公開消息稱，CVE-2023-42282最初的評分為9.8，即“嚴(yán)重”。盡管Indutny在其項(xiàng)目的后續(xù)版本中修復(fù)了該問題，但他否認(rèn)該漏洞構(gòu)成了實(shí)際威脅，以及嚴(yán)重程度較高。
該開發(fā)人員早些時(shí)候?qū)懙溃?ldquo;我認(rèn)為該漏洞的安全影響相當(dāng)可疑”，并要求GitHub撤銷CVE。
正如GitHub安全團(tuán)隊(duì)成員所解釋的那樣，對CVE提出異議不是一件容易的事，它要求項(xiàng)目維護(hù)者追蹤最初發(fā)布CVE的CVE編號機(jī)構(gòu)(CNA)。
CNA通常包括NIST的NVD和MITRE。過去幾年，科技公司和安全供應(yīng)商也加入了這一名單，并能夠隨意發(fā)布CVE。這些CVE以及漏洞描述和報(bào)告的嚴(yán)重性評級隨后被其他安全數(shù)據(jù)庫（如GitHub公告）聯(lián)合發(fā)布。
在Indutny在社交媒體上發(fā)布帖子后，GitHub降低了其數(shù)據(jù)庫中CVE的嚴(yán)重性，并建議開發(fā)人員開啟私人漏洞報(bào)告，以便更好地管理傳入的報(bào)告并減少噪音。
在撰寫本文時(shí)，該漏洞在NVD上的嚴(yán)重程度仍然為“嚴(yán)重”。
日益嚴(yán)重的滋擾
CVE系統(tǒng)最初旨在幫助安全研究人員以合乎道德的方式報(bào)告項(xiàng)目中的漏洞，并在負(fù)責(zé)任的披露后對其進(jìn)行分類，但最近吸引了一部分社區(qū)成員提交未經(jīng)核實(shí)的報(bào)告。
雖然許多CVE都是由負(fù)責(zé)任的研究人員善意提交的，并且代表了可信的安全漏洞，但最近出現(xiàn)了一種新模式，新手安全愛好者和漏洞賞金獵人表面上“收集”CVE來豐富他們的簡歷，而不是報(bào)告構(gòu)成現(xiàn)實(shí)世界、實(shí)際利用影響的安全漏洞。
因此，開發(fā)人員和項(xiàng)目維護(hù)人員進(jìn)行了反擊。
2023年9月，著名軟件項(xiàng)目“curl”的創(chuàng)建者Daniel Stenberg斥責(zé)了“虛假curl問題CVE-2020-19909”，這是針對該項(xiàng)目報(bào)告的一個(gè)拒絕服務(wù)漏洞。
根據(jù)NVD的歷史數(shù)據(jù)，這個(gè)現(xiàn)在備受爭議的CVE的嚴(yán)重程度最初被評為9.8級或嚴(yán)重程度，但在隨后的討論中，該漏洞對安全造成的實(shí)際影響引發(fā)質(zhì)疑，隨后其評級被降至“低”3.3級。
“這不是一個(gè)獨(dú)特的例子，也不是第一次發(fā)生。這種情況已經(jīng)持續(xù)多年了，”斯滕伯格在批評CVE條目時(shí)寫道。
另一個(gè)npm項(xiàng)目micromatch每周下載量達(dá)6400萬次，但報(bào)告稱存在“高”嚴(yán)重程度的ReDoS漏洞，社區(qū)成員正在追查其創(chuàng)建者，詢問這些問題。
針對未經(jīng)驗(yàn)證的漏洞報(bào)告發(fā)布CVE的行為類似于針對項(xiàng)目、其創(chuàng)建者及其更廣泛的消費(fèi)者群體發(fā)起拒絕服務(wù)(DoS)。
開發(fā)人員安全解決方案（例如npm audit）旨在防止易受攻擊的組件進(jìn)入用戶的應(yīng)用程序，如果檢測到任何已知漏洞，可能會(huì)觸發(fā)警報(bào)，并且根據(jù)用戶的設(shè)置，可能會(huì)破壞用戶構(gòu)建。
“幾個(gè)月前有人報(bào)告了針對該項(xiàng)目的一個(gè)關(guān)鍵CVE，并認(rèn)為其破壞了全球的構(gòu)建，”一位評論員在2023年針對虛假的curl CVE做出反應(yīng)時(shí)寫道。
正如其他開發(fā)人員所說，這個(gè)問題并不是項(xiàng)目的安全問題，而是Java遞歸數(shù)據(jù)結(jié)構(gòu)的固有性質(zhì)。
平衡點(diǎn)在哪里
此類事件頻發(fā)引發(fā)了人們的疑問：如何才能取得平衡？不斷報(bào)告理論上的漏洞可能會(huì)讓開源開發(fā)者（其中許多是志愿者）因篩選而精疲力竭。
另一方面，如果安全從業(yè)人員（包括新手）對他們認(rèn)為的安全漏洞置之不理，不免給項(xiàng)目維護(hù)人員帶來不便，這是否合乎道德？
第三個(gè)問題出現(xiàn)在沒有活躍維護(hù)者的項(xiàng)目上。多年無人觸及的廢棄軟件項(xiàng)目包含漏洞，即使被披露，也永遠(yuǎn)不會(huì)被修復(fù)，而且沒有辦法聯(lián)系其原始維護(hù)者。
在這種情況下，包括CNA和漏洞賞金平臺在內(nèi)的中介機(jī)構(gòu)就陷入了困境。
在收到研究人員的漏洞報(bào)告后，這些組織可能并不總是能夠獨(dú)立地充分審查每一份此類報(bào)告。在沒有得到（現(xiàn)已缺席的）項(xiàng)目維護(hù)者的意見的情況下，他們可能會(huì)被迫在“負(fù)責(zé)任的披露”窗口期過后分配和發(fā)布CVE。
目前，這些問題均沒有答案。
在安全研究人員、開發(fā)人員和供應(yīng)商社區(qū)齊心協(xié)力找到有效的解決方案之前，開發(fā)人員必然會(huì)對虛假報(bào)告感到沮喪，而CVE系統(tǒng)也將充斥著夸大的“漏洞”，這些漏洞在紙面上看起來可信，但實(shí)際上毫無意義。
