A detection method and device for heap memory errors

Abstract

The present invention discloses a method and device for detecting heap memory errors, including: after selecting input parameters, performing concolic execution on the program under test; when tracing each execution trace path in concolic execution, generating corresponding branch constraints for each branch, detecting vulnerabilities for each code block related to heap operations, and generating vulnerability constraints for the code blocks with heap-related vulnerabilities; generating test cases for each execution trace path based on the branch constraints and vulnerability constraints corresponding to each execution trace path; inputting each test case into the program under test respectively to obtain the heap memory errors of the verified program under test. The present invention can effectively increase program coverage and find the target points to be analyzed as soon as possible, and minimize the system performance overhead on the premise of maintaining strong consistency with the real running environment of the program, and can detect different types of heap memory errors.

Description

Technical Field

[0001] The present invention relates to software security testing, and particularly to a detection method and device for heap memory errors. Background Art

[0002] Memory errors occur during program execution when the content rewritten in memory exceeds the original intention of the programmer (https: / / en.wikipedia.org / wiki / Memory_corruption). Modern programming languages, such as C and C++, have powerful memory management and pointer arithmetic features, which also bring potential risks to memory security (L. Szekeres, M. Payer, T. Wei and D. Song, "SoK: Eternal War in Memory," 2013 IEEE Symposium on Security and Privacy, 2013, pp. 48 - 62, doi:10.1109 / SP.2013.13).

[0003] Vulnerabilities caused by memory errors are mainly divided into stack-based memory vulnerabilities and heap-based memory vulnerabilities. They can lead to very serious risks, such as system crashes, denial of service, arbitrary code execution, and data leakage, etc. Among them, stack-based memory vulnerabilities used to be the most common and popular. With the deployment of effective defense technologies against stack vulnerability exploitation (Gregory J.Duck and Lorenzo Yap,Cavallaro.Stack Bounds Protection withLow Fat Pointers.In NDSS,2017), heap-based memory vulnerabilities have become increasingly common. For example, 25% of the exploits on the Windows 7 system are based on heap memory vulnerabilities (Microsoft.Software vulnerabilityexploitation trends:Exploring the impact of software mitigations on patternsof vulnerability exploitation(2013).http: / / download.microsoft.com / download / F / D / F / FDFBE532-91F2-4216-9916-2620967CEAF4 / Software%20Vulnerability%20Exploita-tion%20Trends.pdf), and CVE-2021-3156 is a heap memory overflow caused by off-by-one, which can lead to privilege escalation and exists in most Linux systems.

[0004] Currently, many methods have been proposed to protect memory safety on the heap. They are mainly divided into two categories. One is to strengthen software protection through measures such as terminating the software's operation when a vulnerability occurs. The other is to conduct a large number of extensive tests before the software is released. Although the first method can effectively prevent the exploitation of program vulnerabilities, it does not eliminate memory vulnerabilities and will bring huge performance overhead and lead to denial of service, such as the literature Emery D Berger and Benjamin G Zorn. Diehard: probabilistic memory safety for unsafe languages. In ACM SIGPLAN Notices, volume 41, pages 158–168, 2006, the literature Gene Novark and Emery D Berger. Dieharder: securing the heap. In CCS, pages 573–584. ACM, 2010, the literature Nick Nikiforakis, Frank Piessens, and Wouter Joosen. Heapsentry: Kernel-assisted protection against heap overflows. In DIMVA, 2013, and the literature Qiang Zeng, Mingyi Zhao, and Peng Liu. Heaptherapy: An efficient end-to-end solution against heap buffer overflows. In 2015 45th Annual IEEE / IFIP International Conference on Dependable Systems and Networks, pages 485–496. IEEE, 2015. Therefore, it is necessary to detect memory-related vulnerabilities before the software is released.

[0005] Currently, there are mainly static analysis and dynamic analysis methods to detect heap-based memory vulnerabilities. The static analysis method discovers vulnerabilities hidden in the program by scanning the program source code, such as the literature "Yuhan Gao, Liwei Chen, Gang Shi, Fei Zhang. A Comprehensive Detection of Memory Corruption Vulnerabilities for C / C++ Programs [C] / / 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA / IUCC / BDCloud / SocialCom / SustainCom). IEEE, 2018" and the literature "Peng Luo, Dz A, Yd B, et al. Static detection of real-world buffer overflow induced by loop - ScienceDirect [J]. Computers & Security, 89". Although this static analysis method can achieve high coverage. However, since the static detection does not actually run the program, its results will contain a large number of potential false positives, and confirming these potential false positives requires a large amount of human resources for source code review. And since heap-based memory is dynamically allocated and recycled, currently the corresponding detection methods mainly adopt dynamic detection.

[0006] However, existing dynamic analysis tools are all targeted at a certain type of heap memory-related vulnerability detection, rather than comprehensively detecting all heap memory-related vulnerabilities. On the other hand, existing heap memory-related detection tools cannot automatically traverse the paths of programs and generate their corresponding test cases, and they incur a huge system performance overhead. For example, LeakFix can only detect heap memory-based memory leak-related vulnerabilities (Qing Gao, Yingfei Xiong, Yaqing Mi, Lu Zhang, Weikun Yang, Zhaoping Zhou, Bing Xie, and Hong Mei. 2015. Safe memory-leak fixing for C programs. In Proceedings of the 37th International Conference on Software Engineering - Volume 1 (ICSE'15). IEEE Press, 459–470), Heaptherapy (Qiang Zeng, Mingyi Zhao, and Peng Liu. Heaptherapy: An efficient end-to-end solution against heap buffer overflows. In 2015 45th Annual IEEE / IFIP International Conference on Dependable Systems and Networks, pages 485–496. IEEE, 2015), and Hotracer (Xiangkun Jia, Chao Zhang, Purui Su, Yi Yang, Huafeng Huang, Dengguo Feng: Towards Efficient Heap Overflow Discovery. USENIX Security Symposium 2017: 989-1006), which can detect heap memory-based buffer overflow vulnerabilities.AddressSanitizer (Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitry Vyukov. 2012. AddressSanitizer: a fast address sanity checker. In Proceedings of the 2012 USENIX conference on Annual Technical Conference (USENIX ATC'12). USENIX Association, USA, 28) can comprehensively detect all heap memory-related vulnerabilities, but it incurs a 73% system performance overhead and cannot automatically traverse the program paths and generate corresponding test cases.

[0007] To some extent, the existing detection tools combined offline can also achieve the effect of dynamic detection. However, this offline combination method usually uses existing dynamic analysis tools to automatically traverse different paths of the program and generate corresponding test inputs. Then, while running the program under test on the memory detection tool, the test inputs generated in the previous step are injected in sequence, and the detection results are checked. For example: Dowser (Istvan Haller, Asia Slowinska, Matthias Neugschwandtner, and Herbert Bos. 2013. Dowsing for overflows: a guided fuzzer to find buffer boundary violations. In Proceedings of the 22nd USENIX conference on Security (SEC'13). USENIX Association, USA, 49–64) and BORG (Matthias Neugschwandtner, Paolo Milani Comparetti, Istvan Haller, and Herbert Bos. The borg: Nanoprobing binaries for buffer overreads. In Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, CODASPY’15, 2015). BORG is an offline combination of S2E and AddressSanitizer. This simple combination not only generates some false negatives due to the use of inconsistent memory models in the processes of dynamic symbolic execution and heap-based memory vulnerability detection, but also, from the perspective of system performance overhead, this simple combination doubles the number of runs for each path of the program, resulting in a waste of a large amount of system resources and an increase in the system overhead burden. Summary of the Invention

[0008] The present invention proposes a dynamic detection method CTHM and device for heap memory errors. Based on the type and quantity of input parameters, CTHM selects initial inputs using a heuristic method, which can effectively increase program coverage and quickly find the target points to be analyzed. CTHM adopts a custom dynamic symbolic execution memory model, minimizing system performance overhead while maintaining strong consistency with the actual program running environment. CTHM provides a comprehensive analysis engine that can not only comprehensively detect all vulnerabilities related to heap memory errors, but also give full play to the characteristics of these three detection engines to reduce system performance overhead.

[0009] The technical solution of the present invention includes:

[0010] A dynamic detection method for heap memory errors, the steps of which include:

[0011] 1) After selecting input parameters, perform concolic execution on the program under test;

[0012] 2) When tracing each execution trace path in concolic execution, generate corresponding branch constraints for each branch, detect vulnerabilities for each code block related to heap operations, and generate vulnerability constraints for the code blocks with heap-related vulnerabilities;

[0013] 3) Based on the branch constraints and vulnerability constraints corresponding to each execution trace path, generate test cases for this execution trace path;

[0014] 4) Input each test case into the program under test respectively to obtain the verified heap memory errors of the program under test.

[0015] Further, when performing concolic execution on the program under test, input parameters of different types and quantities are replaced regularly or irregularly.

[0016] Further, different types and quantities of input parameters are obtained through the following strategies:

[0017] 1) For the program under test with known types and quantities of input parameters, select different types and quantities of input parameters from the test set of the released program software package;

[0018] 2) For the program under test with unknown types and quantities of input parameters, after using a fuzzer to generate a series of input parameters, use a heuristic method to obtain different types and quantities of input parameters.

[0019] Further, the following steps are used to find the branches and code blocks related to heap operations:

[0020] 1) Execute the program to be tested in a custom memory model to generate memory objects, where the memory model is an extension based on the existing dynamic symbolic execution memory model, which uses a memory allocator to generate memory objects. The variables of the memory objects include: memory object index, memory object start address, memory object size, and memory object attributes;

[0021] 2) The execution engine searches for the code blocks of the branches and heap-related operations based on the variables of the memory objects.

[0022] Furthermore, according to the symbolic flag bit Sym-flag in the memory object, it flags whether the stored value is a concrete value or a symbolic value.

[0023] Furthermore, the memory object attributes include: attribute A indicating whether the memory address is searchable and attribute V indicating whether the memory block is initialized.

[0024] Furthermore, the memory blocks in the process address space are in bytes, and each byte is assigned a bit of A bit and a bit of V bit.

[0025] Furthermore, the heap-related vulnerabilities include: buffer overflow vulnerability, uninitialized heap memory vulnerability, illegal access to heap memory vulnerability, and heap errors of memory leakage and double free.

[0026] Furthermore, the buffer overflow vulnerability is detected through the following steps:

[0027] 1) When a process accesses a certain memory object, use the address reverse method to find the domain where the memory object is located;

[0028] 2) Use the accessed offset to check whether the address of the domain exceeds the boundary of the memory object: if so, the buffer overflow vulnerability is detected, where the boundary of the memory object is obtained from the memory object start address and the memory object size.

[0029] Furthermore, the uninitialized heap memory vulnerability is detected through the following steps:

[0030] 1) For the memory area to be read or written, find the corresponding shadow memory of the memory area;

[0031] 2) Obtain the memory object attributes corresponding to the shadow memory block;

[0032] 3) After loading the value of the accessed memory into the CPU, based on the attribute V indicating whether the memory block is initialized, obtain the detection result of the uninitialized heap memory vulnerability.

[0033] Furthermore, the illegal access to heap memory vulnerability is detected through the following steps:

[0034] 1) For the memory area to be read or written, find the corresponding shadow memory of the memory area;

[0035] 2) Obtain the memory object attributes corresponding to the shadow memory block;

[0036] 3) Based on the attribute A of whether the memory address can be searched, obtain the detection result of the heap memory illegal access vulnerability.

[0037] Furthermore, detect heap errors of memory leakage and double free through the following steps:

[0038] 1) String together the memory objects allocated and freed on each execution trace path in the form of a linked list, where the head of the linked list is the execution trace path name;

[0039] 2) When allocating a new memory object, hang the corresponding memory object index on the linked list; when freeing a memory object, delete its corresponding memory object index from the linked list;

[0040] 3) After an execution trace path is executed, if the linked list corresponding to the execution trace path is not NULL, a heap error of memory leakage is detected; at the same time, when freeing a memory object, if the corresponding memory object index cannot be found on the corresponding linked list, a heap error of double free is detected.

[0041] Furthermore, detect heap-related vulnerabilities through the method of shadow memory search and judgment.

[0042] A storage medium stores a computer program, wherein the computer program is set to execute the above method when running.

[0043] An electronic device includes a memory and a processor, wherein the memory stores a program for executing the above method.

[0044] Compared with the prior art, the present invention has achieved the following technical effects:

[0045] 1. The present invention selects the initial input by using a heuristic method based on the type and quantity of input parameters, which can effectively increase the program coverage rate and find the target point to be analyzed as soon as possible;

[0046] 2. The present invention adopts a custom dynamic symbolic execution memory model, which minimizes the system performance overhead on the premise of maintaining strong consistency with the actual program running environment;

[0047] 3. The present invention provides a comprehensive analysis engine, which can not only detect different types of heap memory errors, but also give full play to the characteristics of these three detection engines to reduce the system performance overhead. Description of the Drawings

[0048] Figure 1 This is a schematic diagram of the overall framework of the present invention.

[0049] Figure 2 This is a schematic diagram of a custom memory model;

[0050] Figure 3 This is a schematic diagram of the management of flag bits; Detailed implementation manners

[0051] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0052] In order to enable this combination to be effectively and practically applied in actual projects, we need to construct an accurate memory model for heap memory vulnerability detection and add a corresponding detection engine so that it can interact with the solver in real time during the dynamic program analysis process. We need to address the following challenges:

[0053] 1. The memory model is a very important part of dynamic program analysis. An accurate memory model can not only accurately detect specified types of memory errors on the premise of being consistent with the actual running environment of the program, but also reduce unnecessary memory overhead. CTHM solves the above problems by using a custom memory model.

[0054] 2. The analysis engine is crucial for the dynamic program analysis function to detect which types of errors and directly affects the system performance. CTHM is a comprehensive detection tool for heap memory errors. It adopts different analysis methods according to the characteristics of different heap memory errors, and effectively solves the problem of comprehensive detection of heap memory errors while minimizing the system performance overhead as much as possible.

[0055] To better illustrate the present invention, some of the existing technologies used in the present invention will now be described:

[0056] Memory Layout: The user space occupied by a program during execution is divided into five different memory regions according to the principle of "address spaces with consistent access attributes are stored together", namely the code segment memory region, the data segment memory region, the BSS segment memory region, the heap memory region, and the stack memory region. (1) The code segment memory region is used to store the code for program execution. This region can be shared. For example, a parent process shares the same code segment memory region with its child processes. To prevent the code segment memory region from being incorrectly overwritten, its attributes are usually set to read-only. (2) The data segment memory region stores the initialized global variables and static local variables. It can be further divided into a read-only data segment and a read-write data segment. For example, constant strings in a program are in the read-only data segment. (3) The BSS memory region is used to store global variables and static local variables that are not explicitly initialized. These variables are implicitly initialized to 0 before the program runs. (4) The heap memory region is dynamically allocated and deallocated during program execution. Its size is not fixed and can be dynamically increased or decreased. When the program calls a memory allocation function (such as: malloc()), it will allocate a block of memory in this region and return the starting address of the newly allocated memory. The memory regions for dynamic analysis are generally deallocated by the programmer (such as: free()). When the program ends and the programmer does not deallocate a certain allocated memory, it is usually reclaimed by the operating system. (5) The stack memory region is automatically allocated and deallocated by the compiler and mainly stores function call parameters, return values, and non-static local variables.

[0057] Memory Error Types: From the perspective of the life cycle of heap memory, vulnerabilities based on heap memory can be divided into the following four types. (1) Buffer overflow is caused by accessing a memory space that exceeds its allocated memory space. (2) Illegal access is mainly caused by accessing memory that does not belong to oneself. (3) Uninitialized access is caused by accessing an uninitialized memory space. (4) Incorrect memory management mainly includes memory leaks and double frees.

[0058] Concolic Execution: The core idea of Concolic execution is to allow a running program to use symbolic values rather than just concrete values as the program's input. The program selectively runs on a symbolic execution engine and a concrete execution engine. It maintains the constraint information on each path and can automatically traverse different paths of the program while generating corresponding test inputs. Concolic execution combines dynamic symbolic execution and concrete execution. As is well known, one advantage of dynamic symbolic execution is to explore as many different paths of the program as possible. It can effectively avoid repeated exploration of the same path and reduce unnecessary memory overhead. Another advantage of dynamic symbolic execution is to automatically generate test inputs on different execution paths. Because of these advantages, dynamic symbolic execution is used in program error detection. However, the disadvantages of dynamic symbolic execution are the consumption of a large amount of memory resources due to path explosion during dynamic execution and the possible loss of symbolic parameters during program execution. To solve the above problems, concrete execution is introduced into dynamic symbolic execution to mitigate the above problems, that is, Concolic execution.

[0059] The overall framework diagram of CTHM for heap memory error detection according to the present invention is as Figure 1 shown

[0060] Step1: In the preprocessing stage, CTHM selects different types and numbers of program input parameters as the seeds for Concolic execution. These different seeds serve as the initial inputs for Concolic execution. CTHM will automatically change the seeds at regular intervals during Concolic execution. Each set of seed inputs generates an execution trace path during Concolic execution, and the subsequent operations of step2-step4 are performed on the generated execution trace path.

[0061] Step2: The program under test runs in a custom memory model execution, and this custom memory model is an extension based on the existing general dynamic symbolic execution memory model. During the execution of the program under test in the Concolic execution engine, a corresponding branch constraint is generated every time a branch is encountered. At the same time, when the execution engine encounters a code block related to heap operations, it throws it to the memory vulnerability detection engine, and the memory detection engine will generate corresponding vulnerability constraints.

[0062] Step3: At the end of each branch block, the branch constraints and vulnerability constraints generated in step2 are combined and thrown to the solver for solution. At the same time, it is judged whether the path passing through this branch ends. If it ends, execute step4. If it does not end, jump to step2 to continue collecting the vulnerability constraints and branch constraints of the next branch block.

[0063] Step4: When the analysis of a single path is completed, CTHM uses the testcase generated by the solver in step3 as the input to the program under test to verify the authenticity of the vulnerability and submits the results to the user in the form of a report (i.e., reports that a vulnerability (error) will occur in the program under this testcase input). At the same time, it interacts with the path selector to determine whether there are other relevant paths that need to be analyzed. If so, the path selector selects a new path and jumps to step2 for execution. If not, the process ends.

[0064] The specific implementation details of the present invention include:

[0065] 1. Preprocessing

[0066] For the analysis of the program under test, we may have many sample sets as the initial seeds for concolic execution. These input seeds mainly include different types and different numbers of input parameters. Some studies have shown that if only one input seed, or input parameters of the same type and the same number, are used, concolic execution may execute the same path after running for a certain period of time. Therefore, the present invention selects input parameters of different types and different numbers as the initial seeds, and automatically changes different seeds as the initial input after the program runs for a certain fixed time, so as to increase the program coverage rate and quickly reach the target point to be analyzed for heap memory operations.

[0067] For the program under test with known types and numbers of input parameters, we select input parameters of different types and numbers from the test set of the released program software package as input seeds. For the program under test with unknown types and numbers of input parameters, we use a fuzzer to generate a series of inputs, and then use a heuristic method to select input parameters of different types and numbers as the seeds for subsequent concolic execution.

[0068] 2. Custom memory model

[0069] Any program running on a computer uses a supposed memory model or needs to be extended in a certain program. For example: The X86 processor divides the flat 32 or 64-bit address space into memory pages, which is a memory model. During dynamic symbolic execution, the memory model is mainly responsible for tracking the symbolic state and being able to handle the semantics of memory-related instructions. Therefore, the memory model is the core of concolic execution and is a key component used to assist in memory error safety detection. At the same time, the accuracy of the memory model will affect the accuracy of the program analysis results. Different memory models are actually a balance between complexity and performance overhead. The memory model can be constructed using the linear address method or the array model method. The following is a detailed description using the linear address method:

[0070] The custom memory model in the present invention is an extension based on the existing dynamic symbolic execution memory model. It is a linear address space that adopts an improved array model. While ensuring that each memory object does not intersect in this space, it can provide efficient operations such as lookup, deletion, and modification. As Figure 2 shown. A memory object is generated by a memory allocator (such as ptmalloc in GNU) from the memory model. In the memory object, according to the symbolic flag Sym-flag, it is marked whether the stored value is a concrete value or a symbolic value. Now, the data structure of this custom memory object will be introduced. Each MemoryObject mainly has the following variables: (1) Index: used to mark the unique index of each MemoryObject; (2) S-address: the starting address of each MemoryObject; (3) size: the size of the MemoryObject; (4) A / V: used to mark the attributes of the MemoryObject. A indicates whether the memory address can be searched, and V indicates whether the memory block is initialized, which is used to detect the legality and integrity during memory access. For the memory blocks in the process address space, each byte is allocated one bit for the A bit and one bit for the V bit. In the present invention, for each byte in the memory block of each process address space, one bit is used to represent A and one bit is used to represent V.

[0071] The management of the A / V flag bits is as Figure 3 shown. CTHM uses a direct mapping method to map the attributes of the application program's addresses to the shadow memory. A complete application program address space is mapped to a single shadow memory space, which makes the shadow mapping very efficient. And by adopting a compact shadow encoding method, the size ratio of the shadow memory space to the application program memory space is 1:4.

[0072] The addresses returned by the memory allocation function malloc are all 8-byte aligned, and each byte has an A bit and a V bit (as Figure 3 ).

[0073] (1) The A bit: Each memory byte has an A bit to represent the legality of accessing the corresponding memory address. A = 0 represents an inaccessible byte, and A = 1 represents an accessible byte. When the program successfully applies for a memory space, the corresponding memory identifier A will be set to 1. When the program releases a memory address space, the corresponding A identifier bit will be set to 0. CTHM uses this identifier bit to detect illegal memory access errors.

[0074] (2) V-bit: Each memory byte has a V-bit to indicate whether the value of the byte has been defined. V = 1 indicates that the byte has been defined, and V = 0 indicates that the byte has not been defined. An undefined byte will cause an unknown error when accessed. CTHM uses this flag bit to detect uninitialized access errors.

[0075] 3. Memory Detection Engine

[0076] The memory vulnerability detection engine is used to detect heap memory-related vulnerabilities during program execution. This detection engine mainly includes three detection modules for detecting four types of heap-related vulnerabilities. (1) Buffer overflow detection module, which is used to detect out-of-bounds access to heap-oriented buffers. (2) Uninitialized & illegal access detection module, which is used to detect that the corresponding heap memory has not been initialized or that a heap memory space other than its own is accessed. (3) Error management detection module, which is used to detect heap errors such as memory leaks and double frees.

[0077] (1) Buffer overflow detection module: Adopting the address reverse lookup technique, when a process accesses a certain MemoryObject, the domain where the MemoryObject is located is found by using the address reverse lookup, and then whether its address exceeds the boundary (S-address + size) of the MemoryObject is found by using the accessed offset. MemoryObject adopts the red-black tree management method. In this way, when using the address reverse lookup technique to find a certain MemoryObject, its time complexity is O(h).

[0078] (2) Uninitialized & illegal access detection module: When the program reads or writes a certain memory area, CTHM first finds the corresponding shadow memory of the memory area, and then judges the A and V bits corresponding to the shadow memory of the block of memory. If A = 0, CTHM will report an illegal access error. After the value of the accessed memory is loaded into the CPU, CTHM judges whether the V is 0. If V = 0, CTHM will report that the block of memory has not been initialized.

[0079] (3) Error management detection module: To detect whether there are errors in heap memory management, we use a linked list structure to manage heap memory objects. During concolic execution, the memory objects allocated and freed on each path are strung together in a linked list. The head of the linked list is the path name. When a new memory object is allocated, its corresponding index is hung on this linked list. When a memory object is freed, its corresponding index is deleted from this linked list. After a path is executed, check whether the linked list corresponding to this path is NULL. If it is not NULL, a memory leak warning will be reported. At the same time, when a memory object is freed and its index cannot be found on the corresponding linked list, a double free warning will be reported.

[0080] In addition to the above three detection methods, the present invention can also solve the detection of memory vulnerabilities only through the method of shadow memory search and judgment.

[0081] The embodiments described above are only descriptions of specific instances of the present invention, and do not limit the scope of the present invention. Without departing from the design spirit of the present invention, various deformations and improvements made by those of ordinary skill in the art to the technical solutions of the present invention shall fall within the protection scope determined by the claims of the present invention.

Claims

1. A dynamic detection method for heap memory errors, the steps of which include: 1) After selecting input parameters, perform concolic execution on the program under test; 2) When tracing each execution trace path in concolic execution, generate corresponding branch constraints for each branch, perform vulnerability detection on each code block related to heap operations, and generate vulnerability constraints for the code blocks with heap-related vulnerabilities; 3) Based on the branch constraints and vulnerability constraints corresponding to each execution trace path, generate test cases for this execution trace path; 4) Input each test case into the program under test respectively to obtain the verified heap memory errors of the program under test.

2. The method according to claim 1, characterized in that, when performing concolic execution on the program under test, different types and quantities of input parameters are replaced regularly or irregularly; different types and quantities of input parameters are obtained through the following strategies: 1) For the program under test with known types and quantities of input parameters, select different types and quantities of input parameters from the test set of the released program software package; 2) For the program under test with the types and quantities of input parameters being positions, after using a fuzzer to generate a series of input parameters, use a heuristic method to obtain different types and quantities of input parameters.

3. The method according to claim 1, characterized in that, find the branches and the code blocks related to heap operations through the following steps: 1) Execute the program under test in a custom memory model to generate memory objects, where the memory model is an extension based on the existing dynamic symbolic execution memory model, which uses a memory allocator to generate memory objects, and the variables of the memory objects include: memory object index, memory object start address, memory object size, and memory object attributes, and the memory object attributes consist of attribute A and attribute V, where attribute A represents whether the memory address can be searched, and attribute V represents whether the memory block is initialized; 2) The execution engine searches for the branches and the code blocks related to heap operations according to the variables of the memory objects.

4. The method according to claim 3, characterized in that, heap-related vulnerabilities include: buffer overflow vulnerabilities, uninitialized heap memory vulnerabilities, illegal access to heap memory vulnerabilities, and heap errors of memory leakage and double free.

5. The method according to claim 4, characterized in that, detect buffer overflow vulnerabilities through the following steps: 1) When a process accesses a certain memory object, use the address reverse method to find the domain where the memory object is located; 2) Use the accessed offset to check whether the address of the domain exceeds the boundary of the memory object: if so, a buffer overflow vulnerability is detected, where the boundary of the memory object is obtained from the memory object start address and the memory object size.

6. The method according to claim 4, characterized in that, detect uninitialized heap memory vulnerabilities through the following steps: 1) For the memory area to be read or written, find the corresponding shadow memory of this memory area; 2) Obtain the memory object attributes corresponding to this shadow memory block; 3) After loading the value accessed from memory into the CPU, based on the attribute V of whether the memory block is initialized, obtain the detection result of the heap memory uninitialized vulnerability.

7. The method according to claim 4, wherein, detect the heap memory illegal access vulnerability through the following steps: 1) For the memory area to be read or written, find the corresponding shadow memory of this memory area; 2) Obtain the memory object attribute corresponding to this shadow memory block; 3) Based on the attribute A of whether the memory address can be found, obtain the detection result of the heap memory illegal access vulnerability.

8. The method according to claim 4, wherein, detect the heap errors of memory leak and double free through the following steps: 1) String together the memory objects allocated and freed on each execution trace path in the form of a linked list, where the head of the linked list is the execution trace path name; 2) When allocating a new memory object, hang the corresponding memory object index on this linked list; when freeing a memory object, delete its corresponding memory object index from this linked list; 3) After an execution trace path finishes execution, if the linked list corresponding to this execution trace path is not NULL, then detect the heap error of memory leak; meanwhile, when freeing a memory object, if the corresponding memory object index cannot be found on the corresponding linked list, then detect the heap error of double free.

9. The method according to claim 3, wherein, detect the heap-related vulnerabilities through the method of shadow memory search and judgment.

10. An electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the method according to any one of claims 1-9.

Images