Định nghĩa chính thức

Chi tiết kỹ thuật

Điểm yếu phát sinh khi chương trình không bảo đảm dữ liệu vừa với bộ đệm được cấp phát trên heap. Việc ghi vượt giới hạn có thể làm hỏng dữ liệu heap lân cận hoặc thông tin điều khiển nằm trong bộ nhớ, bao gồm con trỏ hàm và các cấu trúc thời gian chạy khác. Tùy thuộc vào dữ liệu bị ghi đè và môi trường thực thi, lỗi này có thể gây treo chương trình, tiêu hao tài nguyên, thực thi mã trái phép hoặc vượt qua các cơ chế kiểm soát bảo mật.

Đặc điểm

Đây là một điểm yếu đơn giản ở cấp biến thể, thường được đưa vào trong giai đoạn triển khai và thường liên quan đến các ngôn ngữ không an toàn về bộ nhớ, đặc biệt là C và C++. Đặc điểm xác định là bộ đệm bị ảnh hưởng nằm trong vùng nhớ heap thay vì trên stack. Tình trạng này có thể bắt nguồn từ việc kiểm tra giới hạn đầu vào không đầy đủ, lỗi tính toán số nguyên, xử lý kết thúc chuỗi không đúng hoặc sử dụng API không an toàn.

Hậu quả thường gặp

Tác động trực tiếp có thể là chương trình bị treo, kết thúc hoặc khởi động lại, tiêu thụ quá nhiều CPU, cạn kiệt bộ nhớ hoặc gây ra một dạng từ chối dịch vụ khác. Việc làm hỏng dữ liệu heap hoặc con trỏ hàm có thể cho phép thực thi mã hoặc lệnh trái phép, sửa đổi bộ nhớ hoặc vượt qua cơ chế bảo vệ, ảnh hưởng đến tính bí mật, toàn vẹn, khả dụng và kiểm soát truy cập. Việc thực thi mã tùy ý cũng có thể làm suy yếu các dịch vụ bảo mật khác.

Dữ liệu MITRE CWE chính thức

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ừ chối dịch vụ: tiêu thụ tài nguyên CPU, Từ chối dịch vụ: tiêu thụ bộ nhớ	Tính sẵn sàng	Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Thực thi mã hoặc lệnh trái phép, Vượt qua cơ chế bảo vệ, Thay đổi bộ nhớ	Tính toàn vẹn, Tính bí mật, Tính sẵn sàng, Kiểm soát truy cập	Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.
Thực thi mã hoặc lệnh trái phép, Vượt qua cơ chế bảo vệ, Khác	Tính toàn vẹn, Tính bí mật, Tính sẵn sàng, Kiểm soát truy cập, Khác	When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Biện pháp giảm thiểu rủi ro

Ngăn ghi dữ liệu không an toàn: Sử dụng ngôn ngữ hoặc trình biên dịch có kiểm tra giới hạn tự động, thực hiện kiểm tra giới hạn đầu vào trong giai đoạn triển khai và tránh các hàm nguy hiểm như gets, thay bằng các hàm tương đương có kiểm tra giới hạn. Sử dụng thư viện trừu tượng để che giấu các API rủi ro, nhưng cần hiểu rằng đây không phải giải pháp hoàn chỉnh. Áp dụng các chức năng phòng ngừa ở cấp hệ điều hành như một lớp phòng thủ bổ sung.

Tăng cường bản build và môi trường chạy: Bật cơ chế phát hiện tràn bộ đệm do trình biên dịch hoặc phần mở rộng trình biên dịch cung cấp, chẳng hạn cờ /GS của Microsoft Visual Studio, FORTIFY_SOURCE của Fedora/Red Hat, StackGuard và ProPolice. Các cơ chế này chỉ phát hiện một số dạng tràn và thường phản ứng bằng cách kết thúc ứng dụng, vì vậy bản thân chúng vẫn có thể dẫn đến từ chối dịch vụ. Sử dụng ngẫu nhiên hóa bố cục bộ nhớ và các biện pháp bảo vệ liên quan, bao gồm ASLR và PIE; chúng làm giảm độ tin cậy của việc khai thác luồng điều khiển nhưng không bảo vệ hoàn toàn vì việc làm lộ địa chỉ hoặc tấn công kênh bên có thể vượt qua ASLR.

Dữ liệu MITRE CWE chính thức

Pre-design: Use a language or compiler that performs automatic bounds checking.
Kiến trúc và thiết kếUse an abstraction library to abstract away risky APIs. Not a complete solution.
Gia cố môi trường · Vận hành, Xây dựng và biên dịch · Hiệu quả: Phòng thủ nhiều lớpUse automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.
Gia cố môi trường · Vận hành, Xây dựng và biên dịch · Hiệu quả: Phòng thủ nhiều lớpRun or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333].
Hiện thực hóaImplement and perform bounds checking on input.
Thư viện hoặc framework · Hiện thực hóaDo not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary.
Vận hànhUse OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth.

Cách phát hiện trong hệ thống

Fuzzing: Tạo số lượng lớn đầu vào đa dạng, gọi mã một cách động và tìm các lỗi lặp lại được như treo chương trình, hỏng bộ nhớ hoặc tiêu hao tài nguyên. Fuzzing có hiệu quả cao trong việc phát hiện hành vi bất thường, nhưng phụ thuộc vào việc đầu vào có tiếp cận được đoạn mã lỗi hay không.

Phân tích động tự động: Tích hợp các cơ chế kiểm tra an toàn bộ nhớ trong thời gian chạy khi biên dịch, chẳng hạn AddressSanitizer (ASan) cho C/C++. Cần có đầu vào được tạo phù hợp để đi tới lỗi; các công cụ này có thể làm giảm hiệu năng và chỉ báo cáo điều kiện lỗi, không chỉ ra sai sót lập trình ban đầu gây ra lỗi.

Dữ liệu MITRE CWE chính thức

Phương pháp	Cách làm	Hiệu quả
Kiểm thử fuzzing	Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.	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á

Lỗ hổng điển hình

Hồ sơ chính thức liệt kê các ví dụ tiêu biểu sau, không phải danh sách đầy đủ:

CVE-2025-46687: Việc thiếu kiểm tra độ dài dẫn qua lỗi tràn số nguyên và cấp phát bộ đệm quá nhỏ, cuối cùng gây tràn bộ đệm heap trong một engine JavaScript.
CVE-2021-43537: Việc ép chuyển từ số nguyên không dấu 64 bit sang 32 bit có thể góp phần gây tràn số nguyên và hỏng bộ nhớ heap trong trình duyệt web.
CVE-2007-4268: Lỗi về dấu của số nguyên cho phép phép so sánh vượt qua kiểm tra và dẫn đến tràn heap.
CVE-2009-2523: Không xử lý chuỗi đầu vào không được kết thúc bằng giá trị null dẫn đến đọc vượt bộ đệm hoặc tràn bộ đệm dựa trên heap.
CVE-2021-29529: Việc tính giới hạn liên quan đến số nguyên bằng ceiling và floor trên giá trị dấu phẩy động có thể gây tràn bộ đệm heap trong một sản phẩm máy học.
CVE-2010-1866: Tràn số nguyên tạo ra giá trị có dấu âm, vượt qua kiểm tra chỉ giới hạn tối đa và dẫn đến tràn bộ đệm dựa trên heap.

Dữ liệu MITRE CWE chính thức

Dưới đây là các lỗ hổng tiêu biểu liên quan đến CWE-122, dựa theo mức độ ưu tiên

Nguồn (14)

MITRE CWE

CWE Terms of Use The CLASP Application Security Process

microsoftpressstore.com

Segment Address Offset Randomization (D3-SAOR)

cisa.gov

clang.llvm.org

CWE-122: Tràn bộ đệm dựa trên heap

CWE-122 là gì?

Thống kê dữ liệu

Số lượng lỗ hổng nằm trong CWE-122

Số lượng lỗ hổng trong CISA KEV của CWE-122

Định nghĩa chính thức

Chi tiết kỹ thuật

Đặc điểm

Hậu quả thường gặp

Biện pháp giảm thiểu rủi ro

Cách phát hiện trong hệ thống

Lỗ hổng điển hình

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện