CWE-476 là Dereference con trỏ NULL. Lỗi phát sinh khi Sản phẩm giải tham chiếu một con trỏ mà nó cho là hợp lệ, nhưng con trỏ đó có giá trị NULL. Hiện có 529 lỗ hổng trong kho dữ liệu liên quan đến CWE-476 và 1 trong số đó nằm trong danh mục khai thác thực tế của CISA.
Lỗi xảy ra tại thời điểm chương trình truy cập vùng nhớ hoặc đối tượng thông qua một con trỏ NULL thay vì kiểm tra và xử lý trạng thái không hợp lệ. Nguyên nhân có thể là không kiểm tra giá trị trả về của hàm, khởi tạo không đầy đủ, dữ liệu đầu vào làm phát sinh trạng thái thiếu đối tượng, hoặc việc sử dụng đồng thời khiến con trỏ không còn hợp lệ sau khi kiểm tra. Trong phần lớn môi trường, thao tác này làm tiến trình phát sinh lỗi và dừng; trong điều kiện đặc biệt, nếu NULL tương ứng với địa chỉ 0x0 và mã đặc quyền có thể truy cập địa chỉ đó, việc đọc hoặc ghi có thể dẫn đến tác động nghiêm trọng hơn.
Điểm yếu xuất hiện khi một con trỏ được giả định là hợp lệ nhưng thực tế có giá trị NULL, thường trong giai đoạn triển khai. Nó có thể xảy ra sau khi hàm trả về NULL, khi biến hoặc cấu trúc chưa được khởi tạo, khi dữ liệu trạng thái không đồng bộ, hoặc khi điều kiện tranh chấp làm tài nguyên thay đổi giữa lúc kiểm tra và sử dụng. CWE này có thể gặp trong C, C++, Java, C#, Go và Python; tên gọi liên quan gồm NPD, null deref, NPE và nil pointer dereference.
Hậu quả thường gặp là ảnh hưởng tính sẵn sàng: tiến trình có thể crash, thoát hoặc khởi động lại. Trên một số nền tảng, xử lý ngoại lệ có thể ngăn việc kết thúc ngay lập tức, nhưng vẫn khó đưa phần mềm trở lại trạng thái an toàn. Trong trường hợp hiếm, nếu mã đặc quyền có thể đọc hoặc ghi vùng nhớ tương ứng với NULL, lỗi có thể ảnh hưởng tính bí mật và tính toàn vẹn, bao gồm đọc hoặc sửa đổi bộ nhớ hay thực thi mã hoặc lệnh trái phép.
| Tác động | Phạm vi | Diễn giải |
|---|---|---|
| Từ chối dịch vụ: sập, thoát hoặc khởi động lại | Tính sẵn sàng | NULL pointer dereferences usually result in the failure of the process unless exception handling (on some platforms) is available and implemented. Even when exception handling is being used, it can still be very difficult to return the software to a safe state of operation. |
| Thực thi mã hoặc lệnh trái phép, Đọc bộ nhớ, Thay đổi bộ nhớ | Tính toàn vẹn, Tính bí mật | In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution. |
Yêu cầu: Chọn ngôn ngữ lập trình không dễ phát sinh lỗi giải tham chiếu con trỏ NULL.
Kiến trúc và thiết kế: Xác định mọi biến và kho dữ liệu nhận thông tin từ nguồn bên ngoài, sau đó kiểm tra đầu vào để bảo đảm chúng chỉ được khởi tạo bằng các giá trị mong đợi.
Triển khai: Khởi tạo tường minh mọi biến và kho dữ liệu khi khai báo hoặc ngay trước lần sử dụng đầu tiên. Kiểm tra kết quả của mọi hàm và xác minh giá trị khác NULL trước khi sử dụng. Với các con trỏ có thể bị thay đổi hoặc được trả về từ hàm có khả năng trả về NULL, hãy kiểm tra trước khi giải tham chiếu. Trong môi trường đa luồng hoặc bất đồng bộ, dùng API khóa thích hợp, giữ khóa từ lúc kiểm tra cho đến khi thao tác hoàn tất rồi mới mở khóa. Kiểm tra giá trị trả về thường hữu ích, nhưng không tự xử lý được điều kiện tranh chấp hoặc biến khởi tạo sai.
Phân tích động tự động: fuzzing, kiểm thử độ bền và fault injection với nhiều đầu vào có thể phát hiện lỗi nếu chương trình trở nên không ổn định, bị crash hoặc tạo kết quả sai; phương pháp này có hiệu quả vừa phải và có thể làm chậm chương trình. Có thể tích hợp cơ chế kiểm tra lỗi an toàn bộ nhớ trong lúc biên dịch, chẳng hạn AddressSanitizer cho C/C++; phương pháp này có hiệu quả vừa phải, cần đầu vào được tạo để đi tới đoạn mã lỗi, làm giảm hiệu năng và chỉ báo cáo điều kiện lỗi chứ không nhất thiết chỉ ra nguyên nhân ban đầu.
Phân tích động thủ công: chủ động tạo các điều kiện lỗi ít xảy ra trong sử dụng bình thường, như thiếu bộ nhớ, thiếu quyền, giao dịch bị ngắt hoặc mất các dịch vụ mạng cơ bản, rồi theo dõi hành vi bất thường. Ngoại lệ được môi trường ứng dụng bắt lại vẫn có thể cho thấy ứng dụng chưa xử lý đúng điều kiện bất ngờ.
Phân tích tĩnh tự động: SAST có thể tìm một số trường hợp bằng cách lập mô hình luồng dữ liệu và luồng điều khiển, sau đó tìm các mẫu nguy hiểm nối từ nguồn đầu vào tới nơi dữ liệu được sử dụng; phương pháp này có hiệu quả cao nhưng không bảo đảm phát hiện mọi trường hợp.
| Phương pháp | Cách làm | Hiệu quả |
|---|---|---|
| Phân tích động tự động | This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. | Khá |
| Phân tích động thủ công | Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself. | - |
| Phân tích tĩnh tự động | Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) | Cao |
| Phân tích động tự động | Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].Crafted inputs are necessary to reach the code containing the error, such as generated by fuzzers. Also, these tools may reduce performance, and they only report the error condition - not the original mistake that led to the error. | Khá |
Các mục sau là ví dụ đại diện, không phải danh sách đầy đủ:
CVE-2024-41130: thư viện C++ suy luận LLM giải tham chiếu NULL khi thao tác đọc thất bại.CVE-2005-3274, CVE-2009-4895, CVE-2009-3547: điều kiện tranh chấp hoặc khóa không phù hợp dẫn đến giải tham chiếu NULL.CVE-2002-1912, CVE-2005-0772, CVE-2004-0365, CVE-2003-1013, CVE-2003-1000, CVE-2004-0389, CVE-2004-0458, CVE-2004-0079, CVE-2002-0401: gói tin hoặc yêu cầu được tạo sai kích hoạt lỗi, thường gây từ chối dịch vụ hoặc crash.CVE-2020-29652: máy khách SSH có thể khiến máy chủ Go bị từ chối dịch vụ do giải tham chiếu con trỏ nil.CVE-2009-2692, CVE-2009-3620, CVE-2009-2698, CVE-2009-0949, CVE-2008-3597, CVE-2020-6078, CVE-2008-0062, CVE-2008-5183, CVE-2001-1559: các chuỗi lỗi liên quan đến handler chưa khởi tạo, giá trị trả về không được kiểm tra, bộ nhớ hoặc cấu trúc chưa khởi tạo, trạng thái không đồng bộ, hoặc giá trị hệ thống sai.CVE-2004-0119: yêu cầu được tạo trong quá trình chọn giao thức xác thực có thể gây crash hoặc thực thi mã tùy ý.Dưới đây là các lỗ hổng tiêu biểu liên quan đến CWE-476, dựa theo mức độ ưu tiên
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.
Đánh giá mức độ an toàn và các đề xuất tới từ CyStack cho các trang Web
Tìm hiểu các nghiên cứu của đội ngũ chuyên gia chúng tôi trong an ninh mạng
Tìm hiểu về giải pháp tình báo mối đe doạ và phát hiện lộ lọt dữ liệu tới từ CyStack
vi
