報告多年前已修復的漏洞的目的仍然未知
丹尼爾·斯坦伯格， 捲曲作者, 警告用戶， 通過博客文章， 關於一份報告 由 MITRE 組織 虛假的嚴重漏洞。
報告 有關分配了 CVE-ID“CVE-2020-19909”的漏洞的詳細信息嚴重性級別為 9,8（滿分 10），這是導致代碼執行提升的遠程利用漏洞的典型特徵。
在漏洞報告中 命令行選項的解析代碼中引用了一個錯誤 “–retry-delay”，已於 2019 年修復並導致整數溢出。 由於該錯誤僅在從命令行運行該實用程序時顯式傳遞錯誤值時才會顯現出來，並導致對重新發送數據之前的延遲進行錯誤解釋，因此開發人員尚未將該錯誤歸類為漏洞。
這是一個由幾個小構件組成的故事，它們分散在不同的時間和地點。 這個故事清楚地表明了我們當前具有 ID CVE 和賦予 NVD 大量權力的系統是一個完全崩潰的系統。
丹尼爾·斯坦伯格提到這個問題 三年後到來 當有人向 MITRE 提交漏洞報告並將問題指定為嚴重嚴重級別時。
所以在你的帖子中， 批評 MITRE， 既然它這麼說 該組織怎麼可能“接受所指示的嚴重級別”， 因為即使它是一個可利用的漏洞，拒絕服務問題通常也屬於另一類。
我們在curl 項目中在安全方面積極努力，並且始終與報告問題的安全研究人員合作。 我們介紹我們自己的 CVE，記錄它們，並確保將它們告訴全世界。 我們列出了其中 140 多個，並提供了所有可以想像到的細節。 我們的目標是為所有內容提供黃金級文檔，其中包括我們過去的安全漏洞。
其他人突然提交了curl 的CVE 令人驚訝。 這還沒有告訴我們，我們真的很喜歡它。 現在有一個新的 CVE 報告了一個捲曲問題，但我們在網站上沒有任何詳細信息可透露。 不好。
值得注意的是 curl 開發人員向 MITRE 請求取消該報告 CVE，但 MITRE 代表乾脆取消訂閱，拒絕刪除 CVE 他們只是將其標記為有爭議（“有爭議”）。
除此之外，據稱“有爭議的報告”是通過“NVD”漏洞報告服務匿名發送的，因此迄今為止發布此類“虛假漏洞”的原因尚不清楚。
很多評論的人 在 Curl 作者的帖子中，他們似乎已經達到了某個點，因為他們提到了這一點 可能是有人決定證明缺乏適當的審計 在收到漏洞報告後，能夠使用 CVE 作為一種機制來抹黑項目或引起人們注意修復代碼中的潛在危險問題，而不分析其安全影響。
就連來自 KeePassXC 團隊的 Jonathan White，他的暱稱“droidmonkey”，也發表了評論，他提到 KeePassXC 團隊也經歷過類似的問題，這強化了這樣的想法：很可能有人根據對可能導致漏洞的修復錯誤的研究準備了報告，但主要項目的開發人員認為這些錯誤不會影響安全性（例如，可能存在緩衝區溢出，但僅在處理時才表現出來）用戶無法影響的內部數據）。
最後，如果你是 有興趣了解更多關於它的信息， 您可以在中查看詳細信息 以下鏈接。