CWE-121 là gì?
Điều kiện tràn bộ đệm dựa trên ngăn xếp xảy ra khi bộ đệm bị ghi đè được cấp phát trên ngăn xếp, thường là biến cục bộ và đôi khi là tham số của hàm.
CWE-121: Tràn bộ đệm dựa trên ngăn xếp
Thống kê dữ liệu
TỔNG SỐ CVE LIÊN QUAN (365 NGÀY)699
MỨC TRỪU TƯỢNGBiến thể
KHẢ NĂNG KHAI THÁCCao
Số lượng lỗ hổng nằm trong CWE-121
699 lỗ hổngTăng 161,8% so với cùng kỳ
Số lượng lỗ hổng trong CISA KEV của CWE-121
2 lỗ hổngGiảm 50% so với cùng kỳ
Chi tiết kỹ thuật
Khi dữ liệu vượt quá kích thước bộ đệm trên ngăn xếp, nó có thể ghi đè các dữ liệu lân cận thuộc khung gọi hàm. Trong số đó, địa chỉ trả về có thể bị thay đổi, khiến chương trình chuyển tiếp việc thực thi đến một địa chỉ khác; con trỏ ngăn xếp hoặc con trỏ khung bị sửa đổi cũng có thể làm sai lệch việc tính toán địa chỉ và thao tác bộ nhớ. Vì vậy, lỗi này không chỉ gây hỏng dữ liệu hoặc làm chương trình dừng, mà trong một số tình huống còn có thể dẫn đến thực thi mã trái phép và vượt qua các cơ chế bảo vệ của chương trình.
Đặc điểm
Điểm yếu này ảnh hưởng đến bộ đệm nằm trên ngăn xếp, thường là biến cục bộ trong một hàm. Dữ liệu bảo mật quan trọng trên ngăn xếp có thể bị ghi đè, bao gồm địa chỉ trả về, con trỏ ngăn xếp và con trỏ khung; việc thay đổi chúng có thể làm chương trình chuyển hướng thực thi, sửa đổi bộ nhớ hoặc tạo điều kiện cho thao tác ghi dữ liệu đến vị trí do kẻ tấn công kiểm soát. Điểm yếu thường gặp trong các ngôn ngữ không an toàn về bộ nhớ, đặc biệt là C và C++.
Hậu quả thường gặp
Hậu quả trực tiếp thường là suy giảm tính sẵn sàng do chương trình bị lỗi, kết thúc hoặc khởi động lại, tiêu thụ quá mức CPU hoặc bộ nhớ, hoặc gây từ chối dịch vụ theo cách khác như tạo vòng lặp vô hạn. Tùy dữ liệu trên ngăn xếp bị ghi đè, điểm yếu có thể cho phép sửa đổi bộ nhớ, thực thi mã hoặc lệnh trái phép và vượt qua cơ chế bảo vệ, ảnh hưởng đến tính toàn vẹn, tính bí mật, tính sẵn sàng và kiểm soát truy cập. Nếu đạt được thực thi mã tùy ý, kẻ tấn công thường có thể tiếp tục 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 |
|---|---|---|
| Thay đổi bộ nhớ, 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. |
| Thay đổi bộ nhớ, Thực thi mã hoặc lệnh trái phép, Vượt qua cơ chế bảo vệ | 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. |
| Thay đổi bộ nhớ, 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
Thực hiện kiểm tra giới hạn đối với dữ liệu đầu vào và tránh các hàm nguy hiểm như gets; thay bằng các hàm tương đương an toàn hơn có kiểm tra lỗi vượt giới hạn. Có thể dùng thư viện trừu tượng hóa để che giấu các API rủi ro, nhưng đây không phải giải pháp hoàn chỉnh.
Phòng thủ nhiều lớp: Bật các cơ chế bảo vệ 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 Microsoft Visual Studio /GS, Fedora/Red Hat FORTIFY_SOURCE, StackGuard hoặc ProPolice. Các cơ chế này có thể dùng canary cùng kiểm tra phạm vi hoặc chỉ mục để phát hiện một số dạng tràn, nhưng không bao phủ mọi loại tràn và phản ứng thông thường vẫn có thể là kết thúc ứng dụng, dẫn đến từ chối dịch vụ.
Ngoài ra, sử dụng Address Space Layout Randomization (ASLR), Position-Independent Executables (PIE), và khi phù hợp thì thực hiện rebasing hoặc prelinking mô-đun để làm cho địa chỉ của mã thực thi và thư viện khó dự đoán hơn. Đây chỉ là biện pháp phòng thủ bổ sung: việc làm lộ địa chỉ bộ nhớ hoặc tấn công kênh bên có thể vượt qua ASLR; hơn nữa, không thể dùng ASLR cho thư viện đồng thời với prelinking.
Dữ liệu MITRE CWE chính thức
- 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.
- Kiến trúc và thiết kếUse an abstraction library to abstract away risky APIs. Not a complete solution.
- Hiện thực hóaImplement and perform bounds checking on input.
- Hiện thực hóaDo not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.
- 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].
Cách phát hiện trong hệ thống
Có thể phát hiện điểm yếu này bằng fuzzing để tạo nhiều đầu vào đa dạng và tìm lỗi như sự cố, hỏng bộ nhớ hoặc tiêu thụ tài nguyên. Phân tích tĩnh tự động có thể phát hiện 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 kết nối nguồn dữ liệu với nơi sử dụng dữ liệu. Phân tích động tự động có thể chèn cơ chế kiểm tra an toàn bộ nhớ trong quá trình biên dịch, chẳng hạn AddressSanitizer cho C/C++; phương pháp này cần đầu vào đủ để đi tới mã lỗi, có thể làm giảm hiệu năng và thường chỉ báo điều kiện lỗi chứ không chỉ ra sai sót ban đầu.
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 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á |
Lỗ hổng điển hình
Ví dụ đại diện được ghi nhận là CVE-2021-35395, liên quan đến các lỗi tràn bộ đệm dựa trên ngăn xếp trong SFK dành cho chipset Wi-Fi dùng trong thiết bị IoT và thiết bị nhúng; lỗi này được CISA KEV ghi nhận là đã bị khai thác ngoài thực tế. Đây là ví dụ đại diện, không phải danh sách đầy đủ mọi lỗ hổng thuộc loại này.
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-121, 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.
Tìm hiểu thêm
Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện
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.
Khám phá CyStack VulnScan
