How to implement vulnerability analysis caused by use after release of C++ program

1. Use after release

When dynamically allocated memory is released, the content of the memory is uncertain and may remain intact and accessible, because when it is re- It is the memory manager's decision to allocate or deallocate a freed memory block, but it is possible that the contents of that memory have been changed, causing unexpected program behavior. Therefore, when the memory is released, it is guaranteed that it will no longer be written to or read from.

2. Hazards of use after release

Problems caused by improper memory management are common vulnerabilities in C/C programs. Use after free can lead to potential exploitable risks, including abnormal program termination, arbitrary code execution, and denial of service attacks. From January to November 2018, there were a total of 134 vulnerability information related to it in CVE. Some of the vulnerabilities are as follows:

#CVEVulnerability OverviewCVE-2018-1000051 A use-after-free vulnerability exists in the Artifex Mupdf version of fz_keep_key_storable that could lead to a denial of service or code execution issue. The vulnerability could be exploited by tricking a victim into opening a specially crafted PDF file. CVE-2018-17474There is a use-after-free vulnerability in the HTMLImportsController of the Blink engine in versions prior to Google Chrome 70.0.3538.67, which is likely to lead to remote attacks The author exploits the heap corruption issue through a specially constructed HTML page. CVE-2018-15924A release exists in Adobe Acrobat and Reader 2018.011.20063 and earlier versions, 2017.011.30102 and earlier versions, 2015.006.30452 and earlier versions Later use of vulnerabilities. A remote attacker could exploit this vulnerability to execute arbitrary code.

3. Sample code

The example comes from Samate Juliet TestSuite for C/C v1.3 (https://samate .nist.gov/SARD/testsuite.php), source file name: CWE416_Use_After_Free__malloc_free_char_01.c.

3.1 Defect code

Use 360 ​​Code Guard to detect the above sample code, you can detect the "use after release" defect , the display level is high. As shown in Figure 1:

Figure 1: Use after release detection example

3.2 Repair code

In the above repair code, the repair method given by Samate is: use malloc() on line 30 for memory allocation, and use free() on line 36 for release. After release No other operations are performed on this memory.

Use 360 ​​Code Guard to detect the repaired code, and you can see that there is no "use after release" defect. As shown in Figure 2:

Figure 2: Detection results after repair

4, how to avoid using after release

To avoid using after release, you need to pay attention to the following points:

(1) Be sure to set a null pointer when releasing memory. Although this method has limited effectiveness for utilizing multiple or complex data structures, But some problems can be avoided to a certain extent.

(2) When allocating or releasing memory in a loop statement, you need to carefully confirm whether there is a problem.

(3) Use source code static analysis tools for automated detection, which can effectively discover post-release usage issues in the source code.

The above is the detailed content of How to implement vulnerability analysis caused by use after release of C++ program. For more information, please follow other related articles on the PHP Chinese website!