Mục đích của việc báo cáo các lỗ hổng đã được sửa từ nhiều năm trước vẫn chưa được xác định
Daniel Stenberg, tác giả cuộn tròn, cảnh báo người dùng, thông qua một bài đăng trên blog, về một báo cáo bởi tổ chức MITER, của một lỗ hổng nghiêm trọng giả mạo.
Báo cáo thông tin chi tiết về lỗ hổng mà CVE-ID "CVE-2020-19909" được gán vàovà mức độ nghiêm trọng là 9,8 trên 10, điển hình cho các lỗ hổng bị khai thác từ xa dẫn đến khả năng thực thi mã nâng cao.
Trong báo cáo lỗ hổng một lỗi được tham chiếu trong mã phân tích cú pháp của tùy chọn dòng lệnh “–retry-delay”, đã được sửa vào năm 2019 và gây ra lỗi tràn số nguyên. Vì lỗi chỉ biểu hiện khi một giá trị không chính xác được truyền rõ ràng khi chạy tiện ích từ dòng lệnh và dẫn đến việc giải thích không chính xác về độ trễ trước khi dữ liệu được gửi lại nên lỗi này chưa được các nhà phát triển phân loại là lỗ hổng.
Đây là một câu chuyện bao gồm một số khối xây dựng nhỏ và chúng xảy ra rải rác theo thời gian và ở những nơi khác nhau. Đó là một câu chuyện cho thấy rõ hệ thống hiện tại của chúng ta với ID CVE và rất nhiều quyền lực được trao cho NVD lại là một hệ thống bị hỏng hoàn toàn.
Daniel Stenberg, đề cập rằng vấn đề đến ba năm sau khi ai đó gửi báo cáo về lỗ hổng bảo mật cho MITER và gán cho sự cố ở mức độ nghiêm trọng nghiêm trọng.
Vì vậy, trong bài viết của bạn, chỉ trích MITER, vì nó nói thế làm thế nào mà tổ chức này có thể "chấp nhận mức độ nghiêm trọng được chỉ ra", bởi vì ngay cả khi đó là một lỗ hổng có thể khai thác được thì các vấn đề từ chối dịch vụ thường thuộc một loại khác.
Tại dự án Curl, chúng tôi làm việc quyết liệt và chăm chỉ về vấn đề bảo mật và luôn làm việc với các nhà nghiên cứu bảo mật báo cáo vấn đề. Chúng tôi giới thiệu CVE của riêng mình, ghi lại chúng và đảm bảo giới thiệu với thế giới về chúng. Chúng tôi đã liệt kê hơn 140 trong số đó với mọi chi tiết có thể hình dung được về chúng được cung cấp. Mục tiêu của chúng tôi là cung cấp tài liệu cấp vàng cho mọi thứ và bao gồm các lỗ hổng bảo mật trong quá khứ của chúng tôi.
Việc người khác đột nhiên gửi CVE cho Curl là một điều bất ngờ. Điều này đã không được nói với chúng tôi và chúng tôi thực sự sẽ thích nó. Hiện tại có một CVE mới báo cáo vấn đề cong và chúng tôi không có thông tin chi tiết nào để nói về vấn đề này trên trang web. Không tốt.
Đáng chú ý là các nhà phát triển Curl đã chuyển sang MITER với yêu cầu hủy báo cáo CVE nhưng đại diện MITER lại hủy đăng ký, từ chối xóa CVE và họ chỉ đánh dấu nó là gây tranh cãi (" TRANH CHẤP").
Ngoài ra, còn đề cập rằng các "báo cáo gây tranh cãi" được gửi ẩn danh thông qua dịch vụ báo cáo lỗ hổng "NVD" và do đó cho đến nay lý do công bố loại "lỗ hổng giả" này vẫn chưa được xác định rõ ràng.
Nhiều người đã bình luận trong bài viết của tác giả Curl, họ dường như đã đi đến một điểm nhất định khi đề cập đến điều đó có lẽ ai đó đã quyết định chứng minh việc thiếu kiểm toán thích hợp khi nhận được báo cáo về lỗ hổng bảo mật, khả năng sử dụng CVE làm cơ chế làm mất uy tín của các dự án hoặc kêu gọi sự chú ý đến việc khắc phục các vấn đề nguy hiểm tiềm ẩn trong mã mà không phân tích tác động bảo mật của chúng.
Và ngay cả Jonathan White, từ nhóm KeePassXC, với biệt danh "droidmonkey", đã đưa ra một nhận xét trong đó đề cập đến thực tế là nhóm KeePassXC cũng đã trải qua một vấn đề tương tự, điều này củng cố ý kiến cho rằng có khả năng ai đó đã chuẩn bị các báo cáo dựa trên nghiên cứu về các lỗi đã sửa có khả năng dẫn đến lỗ hổng bảo mật nhưng các nhà phát triển dự án chính nhận thấy là không ảnh hưởng đến bảo mật (ví dụ: có thể xảy ra lỗi tràn bộ đệm nhưng chỉ biểu hiện khi xử lý dữ liệu nội bộ không thể bị ảnh hưởng bởi người dùng).
cuối cùng nếu bạn là muốn biết thêm về nó, bạn có thể kiểm tra các chi tiết trong liên kết theo dõi.