"Brocards" cho việc phân loại lỗ hổng bảo mật

Trong thế giới pháp lý, các luật sư thường sử dụng "brocards" — những châm ngôn ngắn gọn nắm bắt bản chất của một nguyên tắc luật — để đối phó với các lập luận vô lý. Tương tự, trong lĩnh vực bảo mật phần mềm, đặc biệt là quá trình phân loại (triage) lỗ hổng cho các dự án mã nguồn mở, chúng ta cũng cần những nguyên tắc như vậy để sàng lọc các báo cáo chất lượng thấp.

Dưới đây là tổng hợp các "brocards" dành cho việc phân loại lỗ hổng, giúp người bảo trì và các kỹ sư bảo mật nhanh chóng đánh giá tính hợp lệ của một báo cáo.

Thiếu mô hình đe dọa

Một báo cáo lỗ hổng có thể được bác bỏ một cách an toàn nếu nó thiếu mô hình đe dọa, hoặc mô hình đe dọa được trình bày là vô lý.

Ví dụ điển hình là một báo cáo về API của Python gây ra ngoại lệ (exception) trong một số trường hợp không được tài liệu hóa hoặc bất ngờ. Tuy nhiên, báo cáo không giải thích cách một kẻ tấn công có thể khai thác hành vi đó để gây hại. Trong Python, hợp đồng thực thi mặc định là ngoại lệ có thể xảy ra bất cứ lúc nào và hệ thống phải sẵn sàng xử lý chúng. Do đó, việc ném ngoại lệ không tự động tạo ra một lỗ hổng bảo mật.

Một ví dụ khác là báo cáo về tình trạng treo (hang) hoặc ngừng tr响应 trong một công cụ phát triển cục bộ (local developer tool). Mặc dù việc treo là hành vi không mong muốn, nhưng cơ hội gây hại là không đáng kể trong bối cảnh này vì nhà phát triển luôn có thể chấm dứt quy trình.

Năng lực tấn công vượt quá lỗ hổng

Cần cảnh giác với các báo cáo mô tả một trạng thái cuối cùng nghiêm trọng, nhưng chỉ dựa trên các giả định về năng lực của kẻ tấn công mạnh hơn chính lỗ hổng đó. Hiệu quả là, để triển khai cuộc tấn công khai thác lỗ hổng, kẻ tấn công sẽ cần phải có một năng lực ngang bằng hoặc mạnh hơn năng lực mà lỗ hổng đó cung cấp.

Ví dụ, một báo cáo về thao tác nội dung trên một dịch vụ web, trong đó thao tác này chỉ có thể xảy ra nếu kẻ tấn công là một kẻ can thiệp trung gian (Man-in-the-Middle - MiTM) tích cực. Trong trường hợp này, không có lỗ hổng nào tồn tại vì một kẻ MiTM tích cực có thể gửi nội dung hoàn toàn tùy ý và không cần giới hạn mình ở việc thao tác nội dung đã có.

Tương tự, báo cáo về thực thi mã thông qua hỏng bộ nhớ (memory corruption) trong CPython, nơi sự hỏng hóc xảy ra bằng cách trực tiếp thao tác nội bộ đối tượng của CPython tại thời điểm chạy (thông qua ctypes chẳng hạn). Không có lỗ hổng ở đây vì kẻ tấn công đã đang chạy mã tùy ý để thực hiện việc làm hỏng bộ nhớ đó.

Lỗ hổng lý thuyết so với thực tế

Một báo cáo có thể bị bác bỏ nếu nó mô tả một hành vi có thể xảy ra về mặt lý thuyết, nhưng thực tế không xảy ra trong quá trình sử dụng phần mềm.

Đây thường là các báo cáo về lỗ hổng trong một API riêng tư (private API) trong một thư viện, nơi cách sử dụng duy nhất của API đó không bị ảnh hưởng. Ví dụ, một mã nguồn C có thể có một hàm bị tràn bộ nhớ (buffer overflow) với chuỗi dài hơn 100 byte, nhưng nếu tất cả các lệnh gọi hàm trong codebase đều được đảm bảo tĩnh là không vượt quá kích thước đó, thì nó không bị lỗ hổng.

Tương tự, các báo cáo về lỗ hổng trong API (công khai hoặc riêng tư), nơi lỗ hổng chỉ có thể xảy ra khi vi phạm một bất biến (invariant) mà lập trình viên chịu trách nhiệm duy trì. Ví dụ, một API yêu cầu chuỗi đầu vào phải là UTF-8 hợp lệ. Nếu đầu vào vi phạm điều kiện này gây ra lỗi chương trình, thì công cụ fuzzing phát hiện ra hành vi này không thực sự tìm thấy lỗ hổng, vì trong một chương trình thực, lập trình viên chịu trách nhiệm đảm bảo các "khối xây dựng" của API được kết hợp đúng cách.

Tuân thủ tiêu chuẩn

Một báo cáo có thể bị bác bỏ nếu hành vi được mô tả là hậu quả trực tiếp của việc phần mềm tuân thủ đúng một tiêu chuẩn hoặc thông số kỹ thuật. Trong những trường hợp này, lỗ hổng (nếu có) nằm trong chính tiêu chuẩn đó, không phải trong việc triển khai.

Hành vi này thường xuất phát từ các yêu cầu "mạnh mẽ" (robustness) trong các tiêu chuẩn. Nhiều RFC cho phép các tương tác không được xác định rõ ràng. Ví dụ, RFC 7230 cho phép máy chủ bỏ qua các dòng trống trước dòng yêu cầu hoặc chấp nhận dòng LF đơn lẻ làm dấu kết thúc dòng. Việc triển khai theo đúng quy tắc này không phải là lỗ hổng.

Một ví dụ khác là các yêu cầu mật mã, chẳng hạn như việc sử dụng MD5. Nếu MD5 chỉ được sử dụng trong các cấu trúc mà nó thực sự không bị vỡ (như HMAC-MD5), thì việc hiện diện của MD5 không tự bản thân nó tạo thành lỗ hổng.

Chi phí khắc phục lớn hơn tác hại

Người bảo trì nên từ chối hoặc tranh luận các báo cáo lỗ hổng mà hậu quả của việc xử lý báo cáo đó nghiêm trọng hơn hậu quả của chính lỗ hổng.

Ví dụ kinh điển là các lỗ hổng "ReDoS" (Từ chối dịch vụ qua Biểu thức chính quy), đặc biệt trong các bối cảnh mà tác động của việc "từ chối dịch vụ" là không đáng kể. Các báo cáo này thường tốn nhiều công sức của người bảo trì để phân loại và cộng đồng hạ nguồn để khắc phục, dẫn đến việc từ chối dịch vụ chính cộng đồng.

Một trường hợp gần đây là CVE-2026-4539, nơi một người báo cáo ẩn danh đã đệ trình một CVE chống lại dự án Pygments thông qua VulDB, dường như lướt qua bất kỳ sự xem xét nào của người bảo trì. Báo cáo này không đi kèm phiên bản sửa lỗi nhưng đã kích hoạt hàng chục nghìn phụ thuộc hạ nguồn với cảnh báo lỗ hổng mức độ "trung bình", gây ra sự gián đoạn đáng kể.

Kết luận

Sự hiện diện của một báo cáo lỗ hổng (và một định danh CVE hoặc khác cho báo cáo đó) không phải là điều kiện cần hay đủ để một lỗ hổng tồn tại. Nhiều lỗ hổng không bao giờ được "formal" báo cáo, và nhiều báo cáo hình thức không thực sự mô tả các lỗ hổng có ý nghĩa.

Đây là một thực tế đáng buồn trong hệ sinh thái báo cáo lỗ hổng hiện nay, nơi các đối tác như MITRE được hưởng lợi từ việc được coi là nguồn thông tin chất lượng cao, trong khi cũng có thể từ chối mọi trách nhiệm về việc xác minh tính chính xác của các tuyên bố lỗ hổng ngoài việc cung cấp một định danh ổn định.