Binary program heap vulnerability available path exploration method

Abstract

The invention discloses a binary program heap vulnerability available path exploration method, and belongs to the technical field of computer information security. The method comprises the steps of inputting a pseudo code of a target program into a large language model (LLM), generating input related to heap operation in the target program, completing heap primitive extraction, verifying correctness of the input generated by the LLM by using a mixed symbolic execution technology, and establishing a mapping relation between the input and the heap primitive; combining PoC input according to a heap vulnerability behavior mode based on the mapping relationship, inputting target program execution, and determining a heap vulnerability type by updating a memory state; a derived program is generated based on a sequence template by using an adaptive utilization mode guide algorithm, whether a certain execution path in a target program reaches a utilization state or not is verified, and an available path is explored. According to the method, the heap operation primitive in the program can be found more accurately, the heap vulnerability type can be confirmed more quickly, and the accuracy of heap vulnerability availability verification is improved.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, relates to information security technology, and particularly relates to a method for exploring exploitable paths of binary program heap vulnerabilities. Background Art

[0002] With the development of information technology, the code structure of software programs has become increasingly complex, and the number of vulnerabilities existing in software has increased sharply. Attackers can write exploit codes that cause damage by taking advantage of software vulnerabilities and carry out malicious behaviors, which will cause heavy losses to industry information security, network security, etc. The heap memory, as a key area for program dynamic memory allocation, its security status is directly related to the security of the entire system. Heap vulnerabilities such as buffer overflows, memory leaks, data tampering, and remote code execution have become the main sources of system security threats. Automatic Exploit Generation (AEG) is an automated technology that automatically generates exploit codes or attacks against known or unknown vulnerabilities through computer programs or tools. The AEG technology has been evolving on the battlefield of vulnerability attack and defense. It not only enables developers to quickly evaluate the severity of potential vulnerabilities in programs, but also allows security experts to learn from them and then deploy effective defense strategies.

[0003] Although existing AEG technologies perform well in dealing with stack-based and format string vulnerabilities, when facing the complexity of heap allocators, it is particularly difficult to construct successful heap vulnerability exploitation strategies. In fact, triggering a heap vulnerability is only the first step of an attack. An attacker needs to carefully manipulate the heap memory layout and cleverly bypass security mechanisms in order to gain control of the memory area and achieve their attack goals. These challenges not only increase the difficulty of heap vulnerability exploitation, but also delay the assessment of heap vulnerability threats and the timely response to related risks. In order to manipulate the heap memory layout, it is necessary to find heap operations that can interact with the heap allocator, and then, combined with the type of heap vulnerability, carefully assemble these heap operations under the guidance of expert knowledge.

[0004] The purpose of the automatic generation technology for heap vulnerability exploitation is to automatically generate an input or a script for interacting with the target program. These inputs or scripts can directly trigger the heap vulnerability of the target program and achieve exploitation, such as arbitrary code execution. The automatic generation technology for heap vulnerability exploitation includes several key links: heap primitive recognition; confirmation of heap vulnerability types; and selection of appropriate exploitation technologies based on the previously determined heap primitives and heap vulnerability types to complete the automatic generation of heap vulnerability exploitation.

[0005] The purpose of heap primitive recognition is to find heap operations that can interact with heap allocation, such as malloc, free, etc. These heap operations are often not directly exposed to users. Therefore, it is necessary to determine which heap operations can be triggered by user input to indirectly interact with the heap allocator. Existing methods for recognizing heap primitives mainly rely on static and dynamic recognition techniques. Static recognition identifies heap primitives in programs with loop structures and checks their operation dependencies and layouts. Dynamic recognition uses heap operation-guided fuzz testing to explore execution paths containing heap operations and combines them into a heap operation dependency graph (HODG) to identify heap operations and dependencies. Although static analysis methods are relatively practical, they cannot handle indirect jump problems, resulting in the loss of some heap operations, and maintaining a complete control flow graph is very resource-consuming. Dynamic analysis may miss certain paths during execution, thereby missing some heap operations, and it lacks the ability to accurately capture the semantics of heap operations, such as the size range allocated by the dynamic memory allocation malloc operation.

[0006] For different types of heap vulnerabilities, different exploitation schemes need to be adopted. Therefore, this step is also a key step in completing the exploration of exploitable paths. For the confirmation of heap vulnerability types, current methods usually assume that a PoC (Proof of Concept) has been obtained, and reproduce and analyze the heap vulnerability types by checking the order of heap operations and memory layout during the execution of the program guided by the PoC. The process of automatically generating a PoC usually involves fuzz testing or symbolic execution. First, these techniques are time-consuming. Second, they are designed to cause the program to crash rather than identify specific vulnerability types.

[0007] Heap vulnerability exploitable verification mainly includes two techniques: (1) Distance formula solving: This technique calculates the "distance formula" aiming to locate a specific target object (such as a function or data pointer) at the required heap memory location, inspired by heap feng shui. These target objects are used for control flow or data flow hijacking. However, if there are no available target objects, the distance formula cannot be established. In addition, the initial heap layout and noisy heap primitives of complex target programs make it challenging to verify the exploitable nature of vulnerabilities. (2) Heap exploitation pattern: The exploitation pattern method bypasses the need for specific pointers, thereby allowing broader memory control by corrupting heap metadata or exploiting design flaws in the heap allocator. For example, in the FireShell CTF competition, the babyheap exploitation technique achieved control by overwriting the atoi function pointer in the global offset table (GOT). However, although the method based on the heap exploitation pattern solves the problem of target objects in the distance formula method, it is still interfered by the initial heap layout and noisy heap operations. Summary of the Invention

[0008] The existing technologies mentioned above still have some problems in detecting heap vulnerabilities in software programs using exploit auto-generation techniques: when identifying heap primitives, static identification methods are very resource-consuming and have the problem of lost heap operations, while dynamic identification methods have the problem of lost semantics of heap operations; it is time-consuming to confirm the type of heap vulnerability based on PoC; and during the verification of exploitable heap vulnerabilities, it is interfered by the initial heap layout of the target program and noisy heap operations. The purpose of the present invention is to provide a method for exploring exploitable paths of heap vulnerabilities in binary programs, which simplifies the AEG technology and solves the above problems, but can also achieve the effect of verifying whether the heap vulnerabilities in the target program are exploitable.

[0009] A method for exploring exploitable paths of heap vulnerabilities in binary programs provided by the present invention includes the following steps:

[0010] Step 1: Decompile the binary source code of the target program to obtain pseudocode, input the pseudocode of the target program into a large language model (LLM) to generate inputs related to heap operations in the target program, complete heap primitive extraction, and use hybrid symbolic execution technology to verify the correctness of the inputs generated by the LLM. When the input is incorrect or the coverage requirement is not met, the LLM continues to generate inputs; record the execution trace of the target program through the Tracer technology, obtain the symbolic semantics of heap operation parameters, identify heap primitives, and establish a mapping relationship IN_MAP between the inputs and the heap primitives.

[0011] Step 2: Pre-obtain the heap vulnerability behavior patterns, generate LPoC (Likely Proof of Concept) based on IN_MAP. LPoC is the PoC input combined according to the heap vulnerability behavior patterns. Execute the target program using the LPoC, and determine the type of heap vulnerability by updating the memory state. Reassemble the inputs in IN_MAP according to the heap vulnerability behavior patterns to generate LPoC. Finally, record the type of heap vulnerability and the index VULN_INDEX of the abnormal heap operation in IN_MAP. The heap vulnerability behavior patterns record the behavior patterns of the heap operation sequences corresponding to various heap vulnerabilities.

[0012] Step 3: Based on IN_MAP, VULN_INDEX, and the exploitation sequence template, use the adaptive exploitation pattern guiding algorithm to generate a derived program, verify whether a certain execution path in the target program reaches the exploitation state, explore the exploitable path, and output the derived program.

[0013] In the said Step 2, according to the corresponding relationship of the same heap memory address p, for each type of heap vulnerability, enumerate the heap operations in the corresponding behavior pattern from IN_MAP, and then combine the inputs of the enumerated heap operations according to the heap operation sequence in the heap vulnerability behavior pattern to generate LPoC.

[0014] In the aforementioned step 2, determining the heap vulnerability type based on the memory tagging method includes: when allocating memory, the states of the heap pointer variable H and the heap memory area M it points to are both updated to Alloc, and when freeing memory, the states of H and M are both updated to Free; for the propagation of pointer variable values, assuming the new pointer variable is H1, since the address of the heap memory area is propagated, the state of H1 is correspondingly updated to the state of the heap memory area; when executing the target program using LPoC, if a triggering rule for a certain heap vulnerability is matched, record the heap vulnerability type and the index of the abnormal heap operation in IN_MAP; where the triggering rules for heap vulnerabilities are preset in advance, and the triggering points and triggering conditions for various heap vulnerabilities are recorded.

[0015] The method of the present invention sets five types of heap primitives: initial heap primitive, compaction heap primitive, critical heap primitive, noise heap primitive, and cleanup heap primitive. The initial heap primitive includes the heap operations that have been executed before the user interacts with the target program for input. The compaction heap primitive is the heap operation executed to mitigate the impact of the initial heap operation on the heap memory, with the purpose of restoring the heap memory to a state conducive to exploitation. The critical heap primitive is used to construct the critical heap operations required for the exploitation pattern. The noise heap primitive refers to other heap operations that affect the heap memory layout among the selected heap primitives when selecting heap primitives to construct critical heap operations. The cleanup heap primitive is used to eliminate the impact of the noise heap primitive on the heap memory.

[0016] In the aforementioned step 3, set in the exploitation sequence template: 1) the critical heap operations required to implement the exploitation technique, each heap operation includes heap operation parameters and an indication field for whether to set a checkpoint; the purpose of setting a checkpoint is to determine whether a noise heap primitive is introduced; 2) the constraint conditions for the heap operation parameters; 3) the requirements for the initial heap layout; 4) the verification conditions in the checkpoint; 5) the assertion operation to determine whether the exploitation state is reached.

[0017] In step 3 described above, generating a derived program using the adaptive exploitation pattern guidance algorithm includes: First, record the heap operations that the target program has executed before interacting with the user to obtain the initial heap primitives. Check whether the current heap memory layout meets the requirements for the initial heap layout in the current exploitation sequence template. If not, search and organize the heap primitives in IN_MAP so that the current heap memory layout meets the requirements. Then, continue to select key heap primitives according to the key heap operations in the current exploitation sequence template and execute them. After each key heap operation is executed, detect whether a checkpoint is set. If a checkpoint is set, verify the verification conditions of the checkpoint to determine whether a noisy heap operation is introduced. If so, find a cleaning heap primitive in IN_MAP to eliminate the impact of the noisy heap operation on the heap memory layout. After all the key heap operations in the current exploitation sequence template are executed, execute the assertion operation of the current exploitation sequence template to verify whether the exploitation state is reached. If so, output a derived program that reaches the exploitation state and has a single path. This derived program consists of the code of the initial heap primitives, organized heap primitives, key heap primitives, cleaning heap primitives, and assertion operations.

[0018] In step 3 described above, during the process of generating a derived program according to the current exploitation sequence template, if no compliant organized heap primitive and cleaning heap primitive can be found in IN_MAP, stop searching the execution path for the current exploitation sequence template and continue to search the execution path for the next exploitation sequence template.

[0019] Compared with the prior art, the advantages and positive effects of the present invention are as follows: The method of the present invention can more accurately discover the heap operation primitives in a program, confirm the type of heap vulnerability faster, and solve the impact brought by the initial heap operation and the noisy heap operation during the exploitation verification process, thereby improving the accuracy rate of verifying the exploitability of heap vulnerabilities. The method of the present invention solves the current problems of resource consumption and loss of heap operation semantics, and achieves the purpose of verifying whether the heap vulnerability of the target program is exploitable on the basis of simplifying the AEG technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is an overall flowchart of the method for exploring the exploitable path of the binary program heap vulnerability of the present invention;

[0021] Figure 2 is a diagram showing the change of the heap memory state during the exploration of Example Program 2 in an embodiment of the present invention;

[0022] Figure 3 is a diagram showing an example of a derived program generated in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] The present invention will be further described in detail below with reference to the drawings and embodiments.

[0024] A method for exploring exploitable paths of binary program heap vulnerabilities in the present invention solves the problems existing in the above prior art through the following improvements:

[0025] (1) In the heap primitive recognition stage, the method of the present invention proposes a dynamic recognition method guided by heap operation-related inputs to ensure comprehensive coverage of heap primitives and improve recognition efficiency, solving the problems of resource consumption and loss of heap operations in static recognition methods, as well as the problem of loss of heap operation semantics in other dynamic recognition methods. The method of the present invention uses the code analysis function of a large language model (LLM) to obtain heap operation-related inputs, which is the first application of LLM in heap primitive recognition. The present invention uses LLM to generate inputs that can guide the execution of the target program. During the process of dynamically executing the target program based on angr, heap operations are collected. It can be determined in angr which heap operations in the target program have not been covered, and the LLM is fed back to regenerate the inputs. With the program analysis ability of LLM, the problem of loss of heap operations is solved without exploring all execution paths of the program, and resource waste is reduced.

[0026] (2) In the heap primitive recognition stage, the method of the present invention establishes an association between heap operation-related inputs and the corresponding heap primitives. This allows the determination of the type of heap vulnerability without the need for a PoC. For example, by analyzing the previously obtained association relationship, inputs for allocation, release, reading, or writing at the same heap memory address can be assembled according to the behavior pattern of the heap vulnerability. Based on these carefully designed inputs, a memory tagging-based method is applied to confirm whether the input can trigger a heap vulnerability and to confirm the type of the heap vulnerability.

[0027] (3) In the heap vulnerability exploitability verification stage, the method of the present invention continues to use exploitation patterns to guide the exploitable path exploration process because these patterns reveal a wider range of exploitation types than distance formulas. The method of the present invention proposes an adaptive exploitation pattern-guided algorithm to dynamically adjust the heap primitive assembly strategy in real time to counteract the effects of initial heap operations and noisy heap operations. This adaptive algorithm enhances the reliability of exploitable path exploration under different heap layout conditions.

[0028] Such as Figure 1As shown in the figure, the method for exploring exploitable paths of binary program heap vulnerabilities in the present invention mainly includes: (1) generating a mapping relationship IN_MAP between inputs and heap primitives during the heap primitive recognition stage; (2) using IN_MAP in combination with the heap vulnerability behavior pattern HEAP_VULN_PATTERN to generate possible proof-of-concepts LPoC, that is, obtaining PoC inputs combined according to the behavior patterns of heap vulnerabilities. Based on the LPoC, a method based on memory marking is used to determine the type of heap vulnerability and determine the index VULN_INDEX of the abnormal heap operation in IN_MAP; (3) verifying the exploitability of the heap vulnerability based on IN_MAP, VULN_INDEX, and the exploitation sequence template SEQUENCE_TEMPLATE, and outputting a derived program DERIVE_CODE used to verify whether a certain path of the target program reaches the exploited state. In order to explore exploitable paths, the method of the present invention uses a derived program to replace the execution path of the target program. Figure 1 BINARY in Figure 1 represents the binary source code of the target program. During the heap primitive recognition stage, the present invention will decompile the source code to obtain the pseudo-code of the program for subsequent processing.

[0029] The heap vulnerability behavior pattern HEAP_VULN_PATTERN and the exploitation sequence template SEQUENCE_TEMPLATE are obtained from human experts in the embodiments of the present invention. The heap vulnerability behavior pattern records the behavior patterns of heap operation sequences corresponding to different types of heap vulnerabilities. The HEAP_VULN_PATTERN in the embodiments of the present invention is shown in Table 1.

[0030] Table 1 Heap vulnerability behavior pattern

[0031] Vulnerability type Behavior pattern Use-After-Free(UAF) Malloc(p)->Free(p)->Use(p) DoubleFree(DBF) Malloc(p)->Free(p)->Free(p) HeapOverflow(HOF) Malloc(p,size)->Write(p), p+offset>p+size

[0032] Table 1 shows all types of heap vulnerabilities that can be detected in the embodiments of the present invention, including use-after-free (UAF), double-free (DBF), and heap overflow (HOF) vulnerabilities. Among them, p represents the address returned by the allocation, size is the size of the allocation request, Malloc represents the allocation operation, free represents the free operation, Use represents the operation of using a heap memory object, both write and read operations belong to the Use operation, Write represents the operation of writing to a heap memory object, and offset represents the number of bytes written to the heap memory.

[0033] Each derived program is a single-path program that combines normal and abnormal heap operations. It not only preserves the heap operation semantics of the target program but also bypasses the complex execution logic of the target program, thereby tracking the intermediate heap memory state of the target program. Randomly combining normal and abnormal heap operations may generate an astonishing number of derived programs. To alleviate this situation, the method of the present invention pre-sets the use of a sequence template SEQUENCE_TEMPLATE. First, combinations that cannot lead to exploitation are filtered out according to the heap operation conditions recorded in the use sequence template. In addition, the target program often calls heap operations during initialization, and the identified heap primitives usually lack atomicity, that is, they contain multiple heap operations. To solve this problem, the present invention introduces an adaptive exploitation pattern guiding algorithm that guides the generation of the derived program DERIVE_CODE, and the ultimate goal is to determine whether a DERIVE_CODE that can reach the exploitation state can be generated.

[0034] The following Example Program 1 is a pre-set use sequence template SEQUENCE_TEMPLATE for Fastbin dup.

[0035]

[0036] Fastbin dup is a technique for attacking by exploiting vulnerabilities in the glibc memory management mechanism. It mainly bypasses the glibc detection mechanism by releasing and reallocating memory blocks of the same size twice, and can forge memory blocks to link to the fastbin linked list, thereby achieving arbitrary writing to memory or executing arbitrary code. The use sequence template in the above example mainly includes:

[0037] (1) Specify the key heap operations required to implement the current exploitation technique in key_heap_prims. For the fastbindup exploitation technique, its key operations are fixed, including first_allocate (the first allocation), second_allocate (the second allocation), free_first (release the first application), free_second (release the second application), free_first_again (release the first application again), first_reallocate (re-apply to get the same address as the first time), second_reallocate (re-apply to get the same address as the second application), trigger_aoc_allocate (apply to get the same address as first_reallocate). Each operation contains the parameter arg of the heap operation and the field set_check_point indicating whether to set a checkpoint. In the operation of free_first_again in the above example, a checkpoint is set.

[0038] (2) Constraints on parameters are defined in arg_constraint. In the above example, the block size allocated for heap operations is constrained to fall within the range of 0x20 to 0x80.

[0039] (3) Prerequisites for the initial heap layout are set in layout_require. In the above example, it is required that the initial heap memory layout should be filled with tcache bin linked lists corresponding to the specified block sizes.

[0040] (4) Conditions to be verified by the checkpoint are set in check_point. As set in check1 above, it is verified whether the block returned by the current first_allocate is the first block in the associated linked list fastbin. If so, it indicates the existence of noisy heap operations and the verification of the checkpoint fails.

[0041] (5) Verification conditions for whether the exploitation state is reached are set in exp_assert_code. As above, if the memory addresses obtained by the operations first_reallocate and trigger_aoc_allocate are the same, it indicates that the exploitation state of allocating overlapping blocks is reached.

[0042] The above template is only an exploitation sequence template for the Fastbin dup exploitation technique. Users can preset exploitation sequence templates according to other heap exploitation techniques in advance.

[0043] Step 1: Implement heap primitive recognition. Use the LLM to generate inputs related to heap operations in the target program, use angr to verify the accuracy of the inputs, record the execution trace of the target program, identify heap primitives, and establish a mapping between the inputs and the heap primitives.

[0044] Large language models have advantages in identifying control flow structures in code, and their ability to understand, generate, and debug code has been proven. The method of the present invention sends the pseudocode of the binary target program to the LLM to let the LLM generate inputs related to heap operations in the target program. The prompt of the present invention stipulates that the role played by the LLM is a program analysis expert and provides guidance on a small amount of input and output to unify the output format generated by the LLM.

[0045] In addition, to address the problem that the LLM generates incorrect results due to hallucination and randomness issues, the present invention resorts to angr, a hybrid symbolic execution tool that always maintains the following characteristics during execution:

[0046] 1) If the standard input has not been read to the end during program execution, the program will always execute along a single path;

[0047] 2) If the end of the standard input is reached, since there is no guidance for more input, the program will fork when encountering a branch path related to the input;

[0048] 3) If a path fork occurs before reaching the end during the reading of the standard input, the current input can be considered incorrect.

[0049] Due to this feature, the present invention uses angr to ensure the correctness of the generated input. When an incorrect fork situation is encountered, the function position where the exception occurs can be determined and fed back to the LLM to regenerate the input. For the problem of heap operation coverage, if the set coverage is not reached, angr will feed back to the LLM the functions where the unexplored heap operations are located, and the LLM will regenerate the input.

[0050] Since the input generated by the LLM is specific, it will cause the symbolic semantics of the parameters of the heap operation to be lost during dynamic execution. To solve this problem, the present invention first executes the target program using the generated input while retaining the execution trace. Then, the Tracer mechanism of angr is used to replay the trace, intercept (hook) all heap operations, and restore the symbolic semantics of the heap operation parameters. A mapping relationship IN_MAP between the input and the heap primitives is established. Due to the dependency of the heap operations, some heap operations need to be executed simultaneously, so the heap primitives are a set of heap operations with dependencies to be executed simultaneously, either all executed successfully or none of them executed. The mapping relationship IN_MAP records the corresponding relationship between different inputs and the heap primitives. The following is an example of the established mapping relationship between the input and the heap primitives.

[0051]

[0052] Among them, the inner - layer input is an input generated by the LLM, and primitive is the heap primitive. The first primitive contains two allocation operations malloc and one write operation read. The malloc heap operation records the allocated return address ret_addr and the requested allocation size size.

[0053] Step two, confirm the type of heap vulnerability based on LPoC.

[0054] In the previous stage, IN_MAP was generated to represent the relationship between the input and heap primitives (heap operations). With the help of the heap vulnerability behavior patterns in Table 1, the input in IN_MAP is reassembled to obtain the input LPoC. Under the guidance of LPoC, the target program is executed using the assembled input, and the vulnerability type is determined by updating the memory state. During the execution, the memory tags are updated through the instrumentation of heap-related operations. When allocating memory, it is assumed that the states of both the heap pointer variable H and the memory area M it points to are updated to Alloc (memory allocation). When freeing memory, the states of both are updated to Free (memory free). For the propagation of the pointer variable value, assuming the new pointer variable is H1, since the address of the heap memory area is propagated, the state of H1 can be updated accordingly to the state of the heap memory area. Table 2 defines the rules for triggering heap vulnerabilities. Meeting rules V1, V2, and V3 trigger UAF, DBF, and HOF vulnerabilities respectively. The actual size of the heap block in rule V3 can be obtained using the malloc_usable_size API. When the target program matches a certain vulnerability trigger rule under the specific execution guided by LPoC, the present invention records the vulnerability type and the index VULN_INDEX of the abnormal heap operation in IN_MAP.

[0055] Table 2 Heap Vulnerability Trigger Rules

[0056] Rule Vulnerability type Trigger point Trigger condition Vl Use-After-Free Read or write heap object M.status == Free or H.status == Free V2 Double Free Free heap object M.status == Free or H.statuss === Free V3 HeapOverflow Write N bytes to heap object N > M.actual_size

[0057] In Table 2, M represents the memory area; H represents the heap pointer variable, pointing to M; actual_size represents the actual size. When the trigger conditions at the trigger points in Table 2 occur, it means that the corresponding heap vulnerability is triggered.

[0058] In the embodiments of the present invention, IN_MAP provides the input required to generate the LPoC, and for the same heap memory address p, according to different vulnerability types, the input is combined to generate the corresponding LPoC. (1) Generation of LPoC for UAF vulnerability: According to the behavior pattern of UAF, enumerate all allocation operations, free operations, heap memory write operations, and heap memory read operations in IN_MAP according to the corresponding relationship of the heap memory address p; according to the heap operation sequence of the UAF vulnerability Malloc(p)->Free(p)->Use(p), combine the input of the corresponding heap operations to generate the LPoC. (2) Generation of LPoC for DBF vulnerability: Enumerate all allocation operations and free operations in IN_MAP according to the corresponding relationship of the heap memory address p; according to the behavior pattern of DBF Malloc(p)->Free(p)->Free(p), combine the input of the corresponding heap operations to generate the LPoC. (3) Generation of LPoC for HOF vulnerability: Enumerate all allocation operations and heap memory write operations in IN_MAP according to the corresponding relationship of the heap memory address P; compare the byte ranges of the allocation and write operations to determine whether the overflow condition is met. If not, it is determined that it is not a HOF. Otherwise, according to the behavior pattern of the overflow vulnerability Malloc(p,size)->Write(p), combine the input of the corresponding heap operations to generate the LPoC.

[0059] Step 3: Verify the exploitability of the heap vulnerability, and use the adaptive exploitation mode guiding algorithm to explore the exploitable path.

[0060] The present invention verifies the exploitability of the heap vulnerability by exploring an execution path to the exploitation state in the target program. The specific exploitation states set in the embodiments of the present invention are shown in Table 3. Although these states do not directly achieve arbitrary code execution, they can be further implemented on this basis. For example, by arbitrarily writing the exploitation state to overwrite the atoi function pointer in the Global Offset Table (GOT) with the address of other functions, arbitrary code execution can be achieved.

[0061] Table 3 Classification of exploitation states explored by the present invention

[0062]

[0063] In order to address the problem that existing methods cannot handle initial heap operations and noisy heap operations well, the method of the present invention defines the following five types of heap primitives:

[0064] (1) Initial heap primitives, which include heap operations that have been executed before the user interacts with the target program, causing the heap memory to become fragmented and occupying the free list.

[0065] (2) Defragmentation heap primitive. Initial heap primitives may impede the construction of the expected utilization pattern. The defragmentation heap primitive aims to mitigate the impact of these initial operations and restore the heap memory to a state conducive to utilization.

[0066] (3) Critical heap primitives. These primitives include the critical heap operations required to build a complete utilization pattern, such as allocation, release, and memory writing, as well as the abnormal heap operations identified in the previous stage, such as heap overflow, use-after-free, and double-free.

[0067] (4) Noise heap primitives. The heap primitives in IN_MAP may not be atomic, which means that when selecting heap primitives to build critical heap operations, other heap operations in the selected heap primitives will affect the heap memory layout. These inevitable heap operations that may affect the heap memory layout belong to the noise heap primitives. For example, if only one malloc operation is needed, but the heap primitive associated with the input in IN_MAP also includes subsequent malloc and read operations, and these two heap operations affect the heap memory layout, they are considered noise.

[0068] (5) Clean-up heap primitives. These primitives are used to eliminate the impact of noise heap primitives on the heap memory layout.

[0069] The method of the present invention proposes an adaptive utilization pattern-guided algorithm to generate a derived program to verify whether a certain path reaches an exploitable state. Before this, the present invention has recorded the vulnerability type, VULN_INDEX, and IN_MAP. Directly combining heap primitives to generate a derived program will generate a large number of combination possibilities. Therefore, the present invention combines heap primitives under the guidance of SEQUENCE_TEMPLATE. The adaptive utilization pattern-guided algorithm of the present invention will try all possible exploitation techniques. First, use the tool HeapTrace that can record the heap operations of the target program to record the heap operations executed by the target program before interacting with the user, that is, the initial heap primitives. According to the layout_require of the template, check whether the heap layout after the execution of the current initial heap primitives meets the requirements. If it does not meet the requirements, it is necessary to search and organize the heap primitives in IN_MAP so that the current layout meets the requirements. Subsequently, execute the key heap primitives required for the current exploitation technique according to the key_heap_prims of the key heap operations, and after each key heap operation is executed, it is necessary to check whether the set_check_point is set. The purpose of this check is to determine whether a noisy heap primitive is introduced. If the verification condition is met, it means that the verification fails, indicating that a noisy heap primitive is detected. Then, it is necessary to find a clearing heap primitive in IN_MAP to pass the noise check, that is, find the input of a new heap primitive in IN_MAP to execute to offset the impact of the noisy heap operation on the heap memory layout. After all the key heap operations of the current exploitation sequence template are executed, execute the assertion operation exp_assert_code of HeapTrace to verify whether the exploitable state is reached, such as the allocated overlapping block AOC state in the exploitation sequence template of Fastbin dup above.

[0070] In the above process, if no suitable organizing heap primitive and clearing heap primitive can be found in IN_MAP, the adaptive utilization pattern-guided algorithm will try other exploitation templates. Using different exploitation technique templates can search for execution paths to different exploitable states. If a certain exploitation template is satisfied, a derived program DERIVE_CODE that reaches the exploitable state and is a single path will be generated. This derived program consists of the five heap primitives and assertion code defined above.

[0071] Use the method of the present invention to explore the exploitable path of the following example program 2, adopting the Fastbin dup exploitation technique.

[0072]

[0073] In the embodiment of the present invention, the sample program 2 is run on a Linux system containing glibc version 2.27, with a focus on the Double Free vulnerability included in the delete_heap function. The sample program 2 defines a global pointer array *heap to save the heap memory addresses applied by users, includes a main function. The main function first applies for 6 pieces of memory with a size of 0x68 and then releases them. The while loop is used to perform operations that can be triggered by users. Entering 1 is to apply for memory using create_heap, and the input content content and the index of the pointer array need to be specified; entering 2 is delete_heap, which is used to release the heap memory, and index is the index of the pointer array. In addition, no nulling operation is performed after the free() operation in this function, resulting in a dangling pointer. Entering 3 executes process_init(), which includes a calloc application and a release operation.

[0074] For the sample program 2, first, through the heap operation primitive recognition stage, it can be determined that the create_heap function contains a calloc operation with a size of 0x68; delete_heap corresponds to the release operation of the heap object allocated by the create_heap function. In addition, if delete_heap releases the heap object with an index of 1, there will also be an allocation of a noise object at this time, with a size of 0x68. The present invention uses angr to record the missing heap allocation to remind the LLM of this special situation; the process_init method contains a calloc operation and a free operation, and the size of calloc is 0x68.

[0075] By constructing an input LPoC that allocates and releases an object twice, as shown in the sample program 3, to guide the execution of the target program. Through the memory marking-based method, it is found that the rule V2 in Table 2 is satisfied, so it is determined to be a Double Free vulnerability. The sample program 3 is as follows:

[0076]

[0077] Next, the core content of the present invention is carried out. The adaptive exploitation pattern guiding algorithm is used to generate a derived program to verify whether a certain path reaches an exploitable state. The sample program can reach the AOC state under the Fastbin dup template.

[0078] Figure 2Describes the change of the heap memory state during the exploitable path exploration of the example program 2 using the method of the present invention. In the figure, the tcache bin and the Fastbin are free block management linked lists. The specific process is as follows: First, through HeapTrace, it is determined that the initial heap layout of the example program 2 has 6 chunks in the tcache bin 0x70 chain, that is, (a) init state. However, the Fastbin dup template of the example program 1 requires 7 chunks. At this time, the algorithm will search for the heap consolidation primitive, and a 0x70 block can be allocated through calloc and then freed (calloc will not take out free blocks from the tcache bin chain). The execution of process_init meets this condition, so that the requirements of layout_require can be met. Subsequently, the key heap primitives key_heap_prims are started to be executed. Ideally, after the execution of free_second, it is necessary to reach (b) ideal state. However, when releasing the chunk with index 1, a new chunk is reallocated, that is, there is a noisy heap operation, resulting in chunk1 being allocated, that is, (c) actual state. If free_first_again is executed at this time, it will cause the program to crash, which stems from the Double Free detection mechanism on the fastbin chain. At the same time, the template also sets a check_point checkpoint to check whether chunk0 is the first chunk in the linked list. If so, it cannot pass the check. At this time, the algorithm will search for the heap cleaning primitive to make the target program reach the (d) final state. At this time, executing the key heap operation free_first_again will not cause the program to crash, and other key heap operations can be correctly executed subsequently. The arg_constraint in the template restricts the range of the allocation parameter size that is advisable in the Fastbin dup exploitation technique. The derived program generated during the whole process is as Figure 3 shown.

[0079] Figure 3 In it, lines 1 to 7 correspond to the initial heap primitives. Lines 8 and 9 correspond to the heap consolidation primitives. Lines 10 to 20 correspond to the key heap primitives, where line 16 represents the noisy heap primitive, and lines 12 and 14 represent the heap cleaning primitives, which are used to offset the impact of the noisy heap operation. This derived program runs on a Linux system with glibc version 2.27. The assertion operation in line 21 will not trigger an error, confirming that the algorithm has explored the execution path leading to the AOC exploitation state.

[0080] Compare the heap vulnerability exploitable path exploration tool implemented by the method of the present invention with the existing Rex(R), GDBExploitable(G), Maze(M), and HAEPG(H) tools. The path exploration effects are shown in Table 4. The dataset selects programs containing heap vulnerabilities in CTF competitions.

[0081] Table 4 Comparison of the effects of different tools on exploring the exploitable paths of heap vulnerabilities in the same dataset

[0082]

[0083] In Table 4, the Tech column lists all the exploitation techniques implemented in the embodiments of the present invention, including: Fastbin Dup (FD), triggering a double-free vulnerability by freeing the same allocated block twice; Tcachebin_poison (TP), writing the target address to the fd field of the Tcache block by modifying the pointer in the Tcache linked list, thereby achieving arbitrary address writing; Unsortedbin into stack (UBIS), bypassing the fast check mechanism by putting the unsortedbin block on the stack to achieve arbitrary address writing;

[0084] Fastbin dup consolidate (FDC), triggering a double-free vulnerability by putting the allocated block into the unsortedbin, freeing it, and then applying for a block of the same size, so that it exists in both the fastbin and the unsortedbin at the same time; Unsortedbin attack (UBA), writing the target address to its fd field by modifying the pointer of the unsortedbin block to achieve arbitrary address writing;

[0085] Tcache stashing unlink attack (TSUA), after leaking the libc address, using a largebin attack to modify the free_hook to point to the address controlled by the attacker, bypassing the check of the Tcache mechanism; Overlapping chunks (OC), by forging the chunk size or pointer, making the chunk applied in the user area overlap with the adjacent chunk, thereby achieving overflow to modify other chunks;

[0086] House-of-force (HOF) achieves arbitrary address writing by forging heap blocks and controlling the heap pointer to point to the memory area of the forged heap block; Poison Null Byte (PNB) bypasses the security check of the heap manager by adding a null byte at the end of the heap block to forge the heap block size; Unsafe unlink (UU) achieves arbitrary address writing by modifying the pointer of the heap block to point to the memory area controlled by the attacker; Fs Overlappingchunks (FSOC) achieves overflow to modify other chunks by forging the chunk size or pointer to make the chunk in the file descriptor area overlap with other chunks.

[0087] In Table 4, Program is the name of the CTF target program; Vul.type is the vulnerability type; Glibc vers. is the version of glibc; Exp.state is the exploitation state; followed by four comparison tools, F represents failed verification, T represents successful verification, and M represents meeting the layout. The present invention successfully verified 31 out of the selected 42 CTF target programs. Rex was not successful, GDB Exploitable successfully verified 11, Maze successfully verified 10, and HAEPG successfully verified 14. It can be seen from this the effectiveness of the method of the present invention when used on CTF programs and that it is superior to the existing four tools.

[0088] In addition, in order to further verify that the adaptive exploitation pattern guiding algorithm can effectively handle the impact brought by the initial heap layout and noisy heap operations, the present invention selected Python, PHP, and Perl as target programs because the underlying layers of these target programs are developed based on the C language. HeapTrace was used to extract the initial heap operations of these target programs to determine the initial heap layout, and the present invention constructed primitives containing noisy heap operations. The implementation effect is shown in Table 5:

[0089] Table 5 Effectiveness of the adaptive exploitation pattern guiding algorithm on a complex test set

[0090]

[0091] In Table 5, Prog is the target program, Exp Tech is the exploitation technique. Only five exploitation techniques, namely FD, TP, UBA, UU, and OC, are selected for verification. Key Heap Ops is the number of key heap primitives, Noise Heap Ops is the primitives with noise, Pre.Jdg is the number after an initial path screening (without considering noise), Fin.Jdg is the number of reaching the exploitation state, [N] represents the number including noise, and Time Cost is the overall time consumed. It can be proved from Table 5 the effectiveness of the method of the present invention in dealing with the initial heap layout and the noisy heap operations.

[0092] It should be noted that the various example embodiments of the present disclosure can be implemented in hardware or a dedicated circuit, software, firmware, logic, or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software executed by a controller, a microprocessor, or other computing devices. When aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flowcharts, or using some other graphical representation, it will be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, a dedicated circuit or logic, general hardware or a controller or other computing devices, or some combination thereof.

[0093] Except for the technical features described in the specification, they are all well-known technologies to those skilled in the art. The present invention omits the description of well-known components and well-known technologies to avoid redundancy and unnecessarily limiting the present invention. The implementation manners described in the above embodiments do not represent all the implementation manners consistent with the present application. Based on the technical solution of the present invention, various modifications or deformations that can be made by those skilled in the art without creative labor are still within the protection scope of the present invention.

Claims

1. A method for exploring exploitable paths of binary program heap vulnerabilities, characterized in that: The steps include: Step 1, decompile the binary source code of the target program to obtain pseudo code, input the pseudo code of the target program into the large language model LLM, and the LLM generates input related to the heap operation in the target program; Use the hybrid symbolic execution tool angr to execute the target program based on the input generated by LLM to verify the correctness of the input; angr also detects whether the heap operation coverage meets the requirements; when the input is wrong or does not meet the coverage requirements, LLM continues to generate input; identify the heap primitive according to the execution trajectory of the target program, and establish the mapping relationship IN_MAP between the input and the heap primitive; Step 2, pre-acquire the heap vulnerability behavior pattern, reassemble the input in IN_MAP according to the heap vulnerability behavior pattern to generate a possible proof-of-concept input LPoC, use LPoC to execute the target program, determine the heap vulnerability type by updating the memory state, record the heap vulnerability type and the index VULN_INDEX of the abnormal heap operation in IN_MAP; the heap vulnerability behavior pattern records the behavior pattern of the heap operation sequence corresponding to each type of heap vulnerability; Step 3, based on IN_MAP, VULN_INDEX and the exploit sequence template, an adaptive exploit pattern guidance algorithm is used to generate a derivative program, verify whether a certain execution path in the target program reaches the exploit state, and output a derivative program that reaches the exploit state; The utilization sequence template is provided with: 1) key heap operations required for realizing the utilization technology, each heap operation including heap operation parameters and an indication field of whether to set a checkpoint; 2) constraints on the heap operation parameters; 3) requirements for the initial heap layout; 4) verification conditions for setting the checkpoint, the purpose of setting the checkpoint is to determine whether to introduce a noise heap operation; 5) Assert operation to determine whether the utilization state has been reached; The method of using an adaptive utilization pattern to guide an algorithm to generate a derived program includes: firstly recording the heap operations that have been executed by the target program before interacting with a user, obtaining an initial heap primitive, checking whether the current heap memory layout meets the requirements of the initial heap layout in the current utilization sequence template, and if not, searching for a tidying heap primitive from IN_MAP to make the current heap memory layout meet the requirements; continuing to select a key heap primitive to execute according to the key heap operation of the current utilization sequence template, and after executing each key heap operation, detecting whether a checkpoint is set, if a checkpoint is set, verifying the verification condition of the checkpoint, judging whether a noise heap operation is introduced, and if so, searching for a clearing heap primitive from IN_MAP to eliminate the influence of the noise heap operation on the heap memory layout; after executing all the key heap operations of the current utilization sequence template, executing the assertion operation of the current utilization sequence template to verify whether the utilization state is reached, and if so, outputting a derived program that reaches the utilization state and has a single path, the derived program consisting of the code of the initial heap primitive, the tidying heap primitive, the key heap primitive, the clearing heap primitive and the assertion operation.

2. The method according to claim 1, characterized in that In the step 1, when angr detects an input error, it feeds back the function where the exception occurs to LLM, and LLM regenerates the input; when it detects that the set heap operation coverage is not reached, it feeds back the function where the unexplored heap operation is located to LLM, and LLM continues to generate input.

3. The method according to claim 1, characterized in that In the step 1, the Tracer mechanism in angr is used to replay the execution trajectory of the target program, intercept all heap operations, restore the symbolic semantics of heap operation parameters, identify heap primitives, which include a set of heap operations to be executed simultaneously with dependencies and parameters of heap operations, and then establish a mapping relationship IN_MAP between the input and the heap primitive.

4. The method according to claim 1, characterized in that: In the step 2, the method of generating LPoC includes: according to the correspondence relationship of the same heap memory address p, for each heap vulnerability, enumerating the heap operations in the corresponding behavior pattern from IN_MAP, and then according to the heap operation sequence in the heap vulnerability behavior pattern, combining the enumerated heap operation inputs to generate LPoC.

5. The method according to claim 1 or 4, characterized in that: In the step 2, the heap vulnerability type is determined based on the memory marking method, including: assuming that when allocating memory, the states of the heap pointer variable H and the heap memory area M it points to are both updated to Alloc, and when releasing memory, the states of H and M are both updated to Free, Alloc represents memory allocation, and Free represents memory release; for the propagation of the pointer variable value, the new pointer variable is assumed to be H1, and since the address of the heap memory area is propagated, the state of H1 is correspondingly updated to the state of the heap memory area; when using LPoC to execute the target program, if a triggering rule of a certain heap vulnerability is matched, the heap vulnerability type and the index of the abnormal heap operation in IN_MAP are recorded; wherein the triggering rule of the heap vulnerability is pre-set, and the triggering points and triggering conditions of various types of heap vulnerabilities are recorded.

6. The method according to claim 1, characterized in that The method sets five types of heap primitives: initial heap primitive, cleanup heap primitive, critical heap primitive, noise heap primitive and clear heap primitive; initial heap primitive includes heap operations that have been executed before the user interacts with the target program; cleanup heap primitive is a heap operation executed to reduce the impact of initial heap operation on heap memory, with the purpose of restoring heap memory to a state conducive to utilization; critical heap primitive is used to construct critical heap operations required for utilization mode; noise heap primitive refers to other heap operations in the selected heap primitive that affect the heap memory layout when selecting heap primitives to construct critical heap operations; clear heap primitive is used to clear the impact of noise heap primitive on heap memory.

7. The method according to claim 1 or 6, characterized in that: In step 3, when generating a derived program according to the current sequence template, if no required heap cleanup primitives and heap clearing primitives are found in IN_MAP, the search for the execution path of the current sequence template is stopped, and the search for the execution path of the next sequence template is continued.

Images