What are the dangers of secondary release of C language source code?

1. Secondary release

The simple understanding of secondary release is that the memory pointed to by the same pointer is released twice. For C language source code, the same pointer is released twice. A free() operation may result in a secondary release. The defective code in Chapter 3.1 of this article describes this type of situation. In C language, improper shallow copy operation is one of the common causes of secondary release. For example: calling the assignment operator or copy constructor once will cause the data members of the two objects to point to the same dynamic memory. At this time, the reference counting mechanism becomes very important. When the reference counting is improper and an object goes out of scope, the destructor will release the memory shared by the two objects. The corresponding data member in another object will point to the memory address that has been released. When this object also goes out of scope, its destructor tries to release the memory again, causing a secondary release problem. Please see CWE ID 415: Double Free for details.

2. The harm of secondary release

Second release of memory may lead to application crashes, denial of service attacks and other problems. It is one of the common vulnerabilities in C/C one. From January to November 2018, there were a total of 38 vulnerability information related to it in CVE. Some of the vulnerabilities are as follows:

##CVE NumberOverviewCVE-2018-18751The 'defaultaddmessage' function of the read-catalog.c file in GNU gettext version 0.19.8 has a secondary free vulnerability. CVE-2018-17097Olli Parviainen SoundTouch version 2.0 has a security vulnerability in the WavFileBase class of the WavFile.cpp file. A remote attacker can exploit this vulnerability to cause a denial of service. Service (secondary release). CVE-2018-16425The 'scpkcs15emuschsminit' function of the libopensc/pkcs15-sc-hsm.c file in versions before OpenSC 0.19.0-rc1 exists twice. release vulnerability. An attacker could exploit this vulnerability to cause a denial of service (application crash) using a specially crafted smart card. CVE-2018-16402The libelf/elf_end.c file in elfutils version 0.173 has a security issue. A remote attacker can exploit this vulnerability to cause a denial of service (2) release and application crash).

3. Sample code

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

3.1 Defect code

In the above example code,

malloc() is used on line 32 Perform memory allocation and use free() on line 36 to release the allocated memory. In the for loop statement on line 38, the already released memory is released. Memory data was released once, causing a secondary release problem.

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

Figure 1: Secondary release detection example

3.2 Repair code

In the above repair code, the repair method given by Samate is: use

malloc() on line 32 for memory allocation, and on line 36 Use free() to release, and the memory will not be released after release.

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

Figure 2: Detection results after repair

4. How to avoid secondary release

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

(1) Wild pointers are one of the important reasons for secondary release and use after release. Eliminating the effectiveness of wild pointers The way is to set it to

NULL immediately after releasing the pointer or set it to point to another legal object.

(2) For the secondary release problem caused by C shallow copy, always performing deep copy is a good solution.

(3) Using source code static analysis tools, you can automatically discover possible secondary release problems in the program.

The above is the detailed content of What are the dangers of secondary release of C language source code?. For more information, please follow other related articles on the PHP Chinese website!