Tranh chấp CVE đầu tiên của curl: Khi "lỗ hổng" không phải là lỗ hổng

Dự án curl, một trong những thư viện mạng mã nguồn mở phổ biến nhất thế giới với khoảng 30 tỷ bản cài đặt, vừa trải qua tranh chấp CVE đầu tiên kể từ khi trở thành CNA (CVE Numbering Authority). Một nhà nghiên cứu đã khiếu nại lên MITRE vì không hài lòng khi curl từ chối cấp CVE cho một lỗi mà họ cho là lỗ hổng bảo mật.

Vụ việc bắt đầu từ tháng 12/2025, khi một báo cáo về lỗi kiểm tra hostname có dấu chấm đầu (leading dot) được gửi tới curl. Sau nhiều tháng xem xét và ba lần MITRE liên hệ, phán quyết cuối cùng đã xác nhận quan điểm của curl: đây không phải lỗ hổng bảo mật và không cần CVE.

Bối cảnh: curl và vai trò CNA

Cách đây vài năm, dự án curl đã đăng ký trở thành CNA, nghĩa là họ có quyền tự cấp mã CVE cho các vấn đề bảo mật trong phạm vi của mình. Trong thời gian này, curl đã công bố 57 lỗ hổng bảo mật kèm theo mã CVE tương ứng.

Việc trở thành CNA giúp quy trình cấp CVE của curl trở nên nhanh chóng và mượt mà hơn nhiều. Chỉ cần một lệnh gọi API là có ngay số CVE mới. Tuy nhiên, điều này cũng đồng nghĩa với việc đội ngũ bảo mật của curl phải chịu trách nhiệm đánh giá chính xác từng báo cáo.

Quy trình đánh giá nghiêm ngặt

Với mỗi báo cáo, nhóm curl phải xác định đây có thực sự là lỗ hổng bảo mật hay không. Nếu có, họ phân loại theo bốn mức: LOW, MEDIUM, HIGH hoặc CRITICAL. Vì không thể biết cách người dùng sử dụng curl hoặc libcurl, họ đánh giá mức độ nghiêm trọng hoàn toàn dựa trên góc nhìn kỹ thuật của curl.

Đáng chú ý là curl có khái niệm "thấp hơn LOW" (lower than LOW) cho những vấn đề có rủi ro cực nhỏ, đòi hỏi nhiều điều kiện kỳ lạ và phức tạp mới có thể khai thác. Với những trường hợp này, họ cho rằng tốt hơn là không cấp CVE để tránh "điệu nhảy bảo mật" không cần thiết.

Chi phí thực sự của một CVE

Điểm mấu chốt trong lập luận của curl là chi phí khổng lồ của mỗi CVE đối với hệ sinh thái. Với khoảng 30 tỷ bản cài đặt libcurl trên toàn cầu, mỗi CVE được công bố sẽ kích hoạt hoạt động của nhiều đội ngũ bảo mật trên khắp thế giới, dẫn đến hàng loạt bản vá và cập nhật phần mềm.

Mỗi CVE đều có chi phí rất lớn đi kèm. Chi phí này không đến từ chúng tôi và chúng tôi không thấy hay cảm nhận được, nhưng đó là chi phí cho hệ sinh thái mà chúng tôi tin rằng không nên bỏ qua. Chúng tôi nên hành động có trách nhiệm. Không bao giờ bỏ qua các vấn đề thực sự, nhưng cũng phải đảm bảo không gióng chuông báo động cho những vấn đề lý thuyết không gây ra lỗ hổng nào.

Chi tiết kỹ thuật của tranh chấp

Lỗi được báo cáo nằm trong hàm Curl_cert_hostcheck() - hàm kiểm tra xem hostname có khớp với wildcard trong chứng chỉ TLS hay không. Điều kiện để khai thác lỗi này gồm:

• Người dùng phải sử dụng hostname có dấu chấm đầu trong URL, như https://.example.com/
• Hostname này là bất hợp pháp trong DNS, nhưng vẫn có thể "lách" bằng cách thêm vào file /etc/hosts hoặc tương tự
• Máy chủ kết nối tới phải có chứng chỉ wildcard cho tên tương ứng
• curl phải được biên dịch với OpenSSL hoặc Schannel làm TLS backend

Một chuỗi các điều kiện cực kỳ khó xảy ra. Thậm chí, ngay cả khi có kẻ tấn công điều hướng người dùng tới hostname như vậy, việc phân giải tên miền vẫn sẽ thất bại trừ khi có kẻ tấn công cục bộ với đặc quyền cao can thiệp vào hệ thống phân giải tên.

Diễn biến: Ba lần MITRE liên hệ

• 10/02/2026: Tranh chấp đầu tiên được gửi tới curl, nhà nghiên cứu muốn ép cấp CVE
• 28/05: MITRE liên hệ lần hai, curl trả lời gần như giống hệt lần trước
• 15/06: MITRE liên hệ lần ba, curl vẫn giữ nguyên quan điểm
• 24/06: MITRE đưa ra phán quyết cuối cùng

Phán quyết từ MITRE TL-Root xác nhận: "Đây là một lỗi, đã được sửa trong nhánh master. Nó không được coi là lỗ hổng bảo mật vì yêu cầu kẻ tấn công cục bộ với đặc quyền hiện diện mới có thể khai thác." MITRE đồng ý với đánh giá này và coi vụ việc đã kết thúc.

Bài học cho cộng đồng bảo mật

Vụ việc này cho thấy sự cần thiết của việc đánh giá lỗ hổng một cách thận trọng và có trách nhiệm. Việc cấp CVE một cách tràn lan, thiếu cân nhắc có thể gây ra:

• Lãng phí tài nguyên: Các đội ngũ bảo mật phải xử lý thông báo không cần thiết
• Giảm hiệu quả cảnh báo: Khi có quá nhiều CVE "ảo", những CVE thực sự nghiêm trọng có thể bị bỏ qua
• Áp lực cập nhật không đáng có: Người dùng buộc phải cập nhật cho những lỗi không thể khai thác

Đối với cộng đồng bảo mật Việt Nam, đây là một case study hay về cách các dự án mã nguồn mở lớn cân bằng giữa tính minh bạch và trách nhiệm với hệ sinh thái. Quy trình minh bạch của curl - công bố toàn bộ thông tin, phản hồi nhất quán, và bảo vệ quan điểm bằng lập luận kỹ thuật - là mô hình đáng tham khảo cho các dự án phần mềm đang phát triển hệ thống xử lý lỗ hổng của riêng mình.

Biểu tượng CVE

curl đã sửa lỗi này từ ngày 08/12/2025, trước cả khi tranh chấp bắt đầu, và bổ sung unit test để đảm bảo lỗi không tái xuất hiện. Đây là minh chứng cho thấy việc xử lý lỗi đúng đắn và kịp thời quan trọng hơn nhiều so với việc tranh cãi về việc có nên cấp CVE hay không.