CN109711167B - UAF vulnerability defense method based on multi-level pointers - Google Patents
UAF vulnerability defense method based on multi-level pointers Download PDFInfo
- Publication number
- CN109711167B CN109711167B CN201811573649.7A CN201811573649A CN109711167B CN 109711167 B CN109711167 B CN 109711167B CN 201811573649 A CN201811573649 A CN 201811573649A CN 109711167 B CN109711167 B CN 109711167B
- Authority
- CN
- China
- Prior art keywords
- pointer
- heap
- address
- node
- base
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Storage Device Security (AREA)
Abstract
The invention discloses a UAF vulnerability defense method based on a multistage pointer, which comprises the following steps: compiling the program to be defended into an intermediate language; performing instrumentation and/or replacement on operations related to the pointer and the heap object in the intermediate language to obtain a processed intermediate language file; constructing a dynamic UAF vulnerability defense component based on the multi-level pointer; linking dynamic UAF vulnerability defense components to the processed intermediate language files and compiling them into secure executable files. According to the UAF vulnerability defense mechanism based on the multi-level pointer, the first-level base pointer node is inserted into the original pointer and heap object relationship, the common pointer is expanded into the multi-level pointer, the original pointer and heap object relationship and the base pointer node and base pointer node needle relationship are maintained through the base pointer linked list, and the base pointer node on the base pointer linked list is disabled after the object is released, so that the pointer of the released object is prevented from accessing the memory, and the UAF vulnerability is prevented from being generated.
Description
Technical Field
The invention belongs to the field of software security, and particularly relates to a UAF vulnerability defense method based on a multi-level pointer.
Background
Memory error vulnerabilities generally fall into two categories: spatial memory errors (array out-of-bounds errors, uninitialized pointer dereferences, invalid type conversion errors, formatting string errors, etc.) and temporal memory errors (UAF, double release, etc.). The unreasonable use of pointers may cause wild pointers to exist in the program, and the wild pointers are also root causes of serious program bugs such as UAF.
The UAF (use-after-free) bug means that after the allocated memory is released, the pointer pointing to the region is not set to NULL, and then the released memory is read and written by the wild pointer. Such vulnerabilities can cause serious problems of information leakage and arbitrary code execution. And is likely to cause arbitrary code execution.
To solve the problem of UAF, it is not enough to simply set the pointer for releasing the heap object as a null pointer. In a real large program, the number of pointers is large, the life cycle is long, the function call stack is complex, pointer transfer among multiple threads and the like cause that the value of one pointer can have a plurality of different copies. This is one of the main reasons why it becomes very difficult to accurately solve the UAF. Secondly, the uncertainty of the multithread program in the operation causes that the value of the pointer can be determined only in the operation, so that the effect of accurately detecting the bug through static analysis is not good enough.
Disclosure of Invention
Aiming at the defects of the prior art, the invention aims to solve the technical problem that the UAF vulnerability is difficult to solve in the prior art.
In order to achieve the above object, in a first aspect, an embodiment of the present invention provides a UAF vulnerability defense method based on a multi-level pointer, where the method includes the following steps:
s1, compiling a program to be defended into an intermediate language;
s2, performing instrumentation and/or replacement on operations related to the pointer and the heap object in the intermediate language to obtain a processed intermediate language file;
s3, constructing a dynamic UAF vulnerability defense assembly based on the multistage pointer;
and S4, linking the dynamic UAF vulnerability defense component to the processed intermediate language file, and compiling the intermediate language file into a safe executable file.
Specifically, the operations associated with the pointer and heap object include: heap object allocation operations, pointer dereferencing operations, pointer assignment operations with pointer computations, and heap object release operations.
Specifically, step S2 includes the steps of:
s20, traversing each operation of the intermediate language, judging the type of the current operation, and if the current operation is a heap object allocation operation, entering the step S21; if the current operation is a pointer dereferencing operation, go to step S22; if the current operation is a pointer assignment operation with pointer calculation, the process goes to step S23; if the current operation is a heap object release operation, go to step S24; if the current operation is other operations, no processing is carried out;
s21, replacing the heap object allocation operation with a safe heap object allocation operation;
s22, inserting a check code by pointer dereferencing operation;
s23, replacing the inserted pile with a pointer assignment operation with tracking pointer calculation by the pointer assignment operation with the pointer calculation;
and S24, replacing the heap object release operation with a safe heap object release operation.
Specifically, step S3 includes the steps of:
s31, constructing a safe heap object allocation module for monitoring heap object allocation operation;
s32, constructing a pointer checker for monitoring pointer dereferencing operation;
s33, constructing a pointer tracker for monitoring pointer assignment operation with pointer calculation;
and S34, constructing a safe heap object release module for monitoring heap object release operation.
Specifically, the specific working mechanism of the secure heap object allocation module is as follows:
s310, if the heap object allocation operation is monitored, applying for a first heap memory for storing a head node of a base pointer linked list;
s311, applying for a second heap memory with the same size as the heap object application size, wherein the memory is used for meeting the memory request of the heap object;
s312, enabling a head node of the base pointer linked list to point to a first address of a second heap memory;
s313, marking the address of the head node of the base pointer linked list by inverting the highest bit of the memory address value of the first stack;
and S314, assigning the marked head node address to a pointer allocated to the heap object.
Specifically, the specific working mechanism of the pointer checker is as follows:
s320, if pointer dereferencing operation is monitored, judging whether the highest position of the address to be dereferenced is marked or not, if so, indicating that the pointer points to a base pointer, and entering S321, otherwise, indicating that the pointer points to a non-heap area and directly dereferencing;
s321, reversing the highest bit to remove the mark, dereferencing the address without the mark, reaching the base pointer node, and entering the step S322;
s322, judging whether the base pointer stores the heap object address, if so, dereferencing the address of the object stored by the base pointer once again to reach the heap object; otherwise, the invalid pointer is directly dereferenced, resulting in a program crash.
Specifically, the specific working mechanism of the pointer checker further includes: and S323, printing the related information triggering the UAF behavior dereferencing pointer and each node of the corresponding base pointer linked list.
Specifically, the specific working mechanism of the pointer tracker is as follows:
s330, if the pointer assignment operation with pointer calculation is monitored, setting a temporary variable, judging whether a pointer on the right of an equal sign in a pointer calculation expression points to a non-heap area or a base pointer node, and if the pointer points to the non-heap area, assigning a heap object address to the temporary variable; if the pointer is the base pointer node, dereferencing the pointer to reach the base pointer node, acquiring the heap object address stored in the base pointer node, and assigning a value to a temporary variable;
step S331, calculating an expression and a temporary variable according to the pointer, and calculating a new object address calculated by the expression;
s332, if the pointer on the right side of the equal sign in the pointer calculation expression points to a non-heap object, directly assigning a new object address to the pointer on the left side of the equal sign in the pointer calculation expression; if the pointer on the right of the equal sign in the pointer calculation expression points to the base pointer node, the step S333 is carried out;
s333, searching whether a node pointing to a new object address exists in the base pointer linked list, and if so, assigning the marked address of the node which exists to a pointer on the left side of the middle sign in the pointer calculation expression; otherwise, go to step S334;
and S334, creating a base pointer node pointing to the address of the new object, inserting the base pointer node into the base pointer linked list of the object, and assigning the marked address of the newly created node to the pointer on the left side of the equal sign in the pointer calculation expression.
Specifically, the specific working mechanism of the secure heap object release module is as follows:
step S340, if the heap object releasing operation is monitored, acquiring the address of the head node of the base pointer linked list, traversing the base pointer linked list, and juxtaposing all nodes on the linked list into an invalid value, and entering step S341;
and S341, releasing the corresponding heap object.
In a second aspect, an embodiment of the present invention provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program implements the UAF vulnerability defense method according to the first aspect.
Generally, compared with the prior art, the above technical solution conceived by the present invention has the following beneficial effects:
1. according to the UAF vulnerability defense mechanism based on the multi-level pointers, a first-level base pointer node is inserted into the original pointer and object relation, the common pointer and object relation is expanded into the multi-level pointers, the relation between the pointer and the heap object and the relation between the base pointer and the base pointer are maintained through the base pointer, and the base pointer on the base pointer node is disabled after the object is released, so that the pointer of the released object is prevented from accessing a memory, and the UAF vulnerability is prevented from being generated.
2. The invention forms the base pointer linked list corresponding to the objects one by separating the data structure for recording the relation between the pointer and the objects, reduces the need of finding the related data structure in the large data structure after the objects are released, and brings better performance.
Drawings
Fig. 1 is a flowchart of a UAF vulnerability defense method based on a multi-level pointer according to an embodiment of the present invention;
FIG. 2 is a flowchart of the operation of a secure heap object allocation module according to an embodiment of the present invention;
fig. 3 is a flowchart illustrating the operation of a pointer tracker according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
As shown in fig. 1, a UAF vulnerability defense method based on a multi-level pointer includes the following steps:
s1, compiling a program to be defended into an intermediate language;
s2, performing instrumentation and/or replacement on operations related to the pointer and the heap object in the intermediate language to obtain a processed intermediate language file;
s3, constructing a dynamic UAF vulnerability defense assembly based on the multistage pointer;
and S4, linking the dynamic UAF vulnerability defense component to the processed intermediate language file, and compiling the intermediate language file into a safe executable file.
S1, compiling the program to be defended into an intermediate language.
And compiling the program to be defended into an intermediate language through a compiler.
And S2, performing instrumentation and/or replacement on the operation related to the pointer and the heap object in the intermediate language to obtain a processed intermediate language file.
Operations associated with pointers and heap objects include: heap object allocation operations, pointer dereferencing operations, pointer assignment operations with pointer computations, and heap object release operations. Step S2 includes the following steps:
s20, traversing each operation of the intermediate language, judging the type of the current operation, and if the current operation is a heap object allocation operation, entering the step S21; if the current operation is a pointer dereferencing operation, go to step S22; if the current operation is a pointer assignment operation with pointer calculation, the process goes to step S23; if the current operation is a heap object release operation, go to step S24; if the current operation is other operation, no processing is performed.
Step S21, the heap object allocation operation is replaced by a safe heap object allocation operation.
For example, the heap object allocation operation call malloc (10) will be replaced with the secure heap object allocation operation callsecMalloc (10). The secured heap object allocation operation will be used as a secured heap object allocation module entry in the object manager during the defense phase.
And S22, inserting the check code by the pointer dereferencing operation.
For example, the pointer dereference operation p, after inserting the check code, becomes ptrcheck (p), where p is the pointer. The pointer dereferencing operation inserted into the inspection code will be used as a pointer checker entry in the defense phase.
And S23, replacing the inserted pile with the pointer assignment operation with the tracking pointer calculation.
For example, the pointer assignment operation q with pointer calculation is p +1, and the instrumented pointer assignment operation q with trace pointer calculation is replaced with getpttr (p, ptrcheck (p) +1), where p and q are pointers. The pointer assignment operation with trace pointer calculation will be used as an entry for the pointer tracker during the defense phase.
And S24, replacing the heap object release operation with a safe heap object release operation.
For example, the heap object release operation call free (p) will be replaced with a secure heap object release operation callsecfree (p), where p is a pointer. The secured heap object release operation will be used as a secured heap object release module entry in the heap object manager during the defense phase.
And S3, constructing a dynamic UAF vulnerability defense assembly based on the multi-stage pointer.
And the dynamic UAF vulnerability defense component is used for monitoring related operations of pointer and heap object distribution management in the execution process of the security executable file. The dynamic UAF vulnerability defense component comprises: the system comprises a secure heap object allocation module, a pointer checker, a pointer tracker and a secure heap object release module. The original pointer is made to become a multi-level pointer by inserting a base pointer between the original pointer and the heap object.
For heap object allocation operations, the secure heap object allocation module allocates a base pointer head node and a heap object first, and then establishes a relationship between the two. For the heap object releasing operation, the safe heap object releasing module firstly releases the heap object, then finds the linked list formed by all the base pointer nodes, and sets all the base pointers on the linked list as invalid. For pointer dereferencing operation, the pointer checker judges whether the current pointer is a multi-level pointer pointing to the heap area, if so, dereferencing once, and the reading or writing of the internal memory of the heap address of the original logic is realized; otherwise, the pointer is dereferenced normally. For pointer propagation operation, and the current pointer points to a heap area, a pointer tracker starts tracking, firstly, whether a base pointer linked list has reference to a new object address or not is searched, and if the base pointer linked list has reference to the new object address, the address of the existing base pointer node is directly obtained; if not, a base pointer node pointing to the new address is newly established.
Step S3 includes the following steps:
step S31, a secure heap object allocation module for monitoring heap object allocation operation is constructed, and the specific working mechanism of the secure heap object allocation module is as follows:
step S310, if the heap object distribution operation is monitored, applying for a first heap memory for storing the head node of the base pointer linked list.
As shown in fig. 2, a heap memory is applied by malloc (bp), which is a head node h for storing the base pointer chain table, to complete initialization of the base pointer chain table h.
Step s311, a second heap memory with the same size as the heap object request is applied, where the second heap memory is used to satisfy the memory request for the heap object.
As shown in fig. 2, a heap memory with a size as large as that of the heap object application is applied by malloc (size), and the heap memory is used to satisfy the memory request for the heap object 1, thereby completing the creation of the heap object 1.
Step S312, the head node of the base pointer linked list points to the first address of the second heap memory.
As shown in fig. 2, the relationship between the head node h of the base pointer and the heap object 1 is established by pointing the head node of the base pointer linked list to the head address of the second heap memory.
And S313, marking the address of the head node of the base pointer linked list by inverting the highest bit of the memory address value of the first stack.
In a 64-bit Linux system, only the lower 48 bits are used for the address space and the upper 16 bits are unused. Of the 64-bit addresses, the highest 16 bits are 0x0000 in the user mode and 0xffff in the kernel mode. Then, after inversion, the maximum 16 bits of the user mode address are 0x8000, and the kernel mode bit is 0x7 fff.
And S314, assigning the marked head node address to a pointer allocated to the heap object.
As shown in fig. 2, the marked head node address is assigned to the pointer allocated to the heap object by the return & base pointer head node h, & is the address character, and & base pointer head node h is the address of the base pointer head node h (the value is the address value marked by the inverted highest bit). In a program, an allocation function of a heap object generally returns an allocated heap memory initial address, and then a developer assigns the value to a pointer, such as p ═ malloc (size), which stores the initial address of the heap object; modified p ═ secmalloc (size), the p pointer holds the tagged radix pointer address.
The original heap object request applies for a memory through the malloc, the initial address of the memory is returned, and after the external calling of the malloc is finished, the returned address is assigned to a pointer. After the allocation processing of the safe heap object, the address of the base pointer node is returned, so that the base pointer exists between the original pointer and the heap object.
Step S32, constructing a pointer checker for monitoring pointer dereferencing operation, wherein the specific working mechanism of the pointer checker is as follows:
step S320, if the pointer dereferencing operation is monitored, whether the highest position of the address to be dereferenced is marked or not is judged, if so, the pointer points to the base pointer, and the step S321 is entered, otherwise, the pointer points to the non-heap area and is directly dereferenced.
Whether the most significant bit of the pointer's value is inverted determines whether the pointer is a multi-level pointer to a heap area. Because the program has pointers pointing to the stack area and pointers pointing to non-stack areas (stack areas, global variables and the like), because the invention only inserts the base pointer between the stack object and the pointers related to the stack object, when the pointers are dereferenced, the pointers which are not originally changed by the invention (originally pointing to the non-stack areas) or the pointers which point to the base pointer (originally pointing to the stack areas) need to be distinguished, thereby completing different dereferencing operations. Direct reference refers to a normal reference.
And S321, reversing the highest bit to remove the mark, dereferencing the address without the mark, reaching the base pointer node, and entering the step S322.
S322, judging whether the base pointer stores the heap object address, if so, dereferencing the address of the object stored by the base pointer once again to reach the heap object; otherwise, the invalid pointer is directly dereferenced, resulting in a program crash.
If an operation in the program attempts to dereference through the pointer, a released heap object (UAF bug) is accessed. Since these pointers are actually changed to multi-level pointers (pointing to the base pointer instead of the object itself), they all point to a certain base pointer node in a base pointer linked list, and after the release operation of the safe heap object is finished, all base pointer nodes on the base pointer linked list corresponding to the object are set to be invalid. When the released object is accessed through the pointer, the direct dereferencing of the invalid value can cause a program segment error, so that the program can directly crash, and the UAF vulnerability is prevented.
Further, step S32 may further include: and S323, printing the related information triggering the UAF behavior dereferencing pointer and each node of the corresponding base pointer linked list.
The relevant information is printed on the console to provide more information for the user or developer to perform vulnerability analysis and know which pointer generates the UAF behavior.
Step S33, constructing a pointer tracker for monitoring pointer propagation operation, wherein the specific working mechanism of the pointer tracker is as follows:
s330, if pointer propagation operation is monitored, setting a temporary variable tmp, judging whether a pointer on the right of the equal sign in the pointer calculation expression points to a non-heap area or a base pointer node, and if the pointer points to the non-heap area, assigning a heap object address to the temporary variable tmp; if the pointer is a base pointer node, the pointer is dereferenced to reach the base pointer node, and the heap object address stored in the base pointer node is obtained and assigned to the temporary variable tmp.
As shown in FIG. 3, a temporary variable tmp is set, and it is determined whether the right pointer (p1 or p2) in the pointer calculation expression points to a non-heap or base pointer node (which originally points to a heap). For example: the two expressions, q1 ═ p1+10 (heap area) or q2 ═ p2+10 (heap area), are used to distinguish between the case where the pointer points to the non-heap area and the base pointer.
If it is directed to a non-heap area, object 1 address (i.e. the value of p2, which is 0x321 as shown in the figure) is assigned a temporary variable tmp (tmp ═ p2, i.e. tmp has a value of 0x 321).
If it is a point to the base pointer node (e.g., base pointer h in the graph), the pointer is dereferenced to the base pointer node (base pointer h), and the heap object 2 address stored at the base pointer node (value of p1, which is 0x123 as shown in the graph) is obtained and assigned to a temporary variable tmp (tmp-p 1, i.e., tmp has a value of 0x 123).
And S331, calculating a new object address calculated by the expression according to the pointer calculation expression and the temporary variable tmp.
As shown in fig. 3, the new object address calculated from the pointer calculation expression (q1 ═ p1+10 or q2 ═ p2+10) and the temporary variable tmp calculation expression (tmp +10, for q1 ═ p1+10, tmp ═ p1 ═ 0x 123; for q2 ═ p2+10, tmp ═ p2 ═ 0x 321).
S332, if the pointer on the right side of the equal sign in the pointer calculation expression points to a non-heap object, directly assigning a new object address to the pointer on the left side of the equal sign in the pointer calculation expression; if the pointer to the right of the equal sign in the pointer calculation expression points to the base pointer node, the process proceeds to step S333.
As shown in FIG. 3, if the pointer to the right of the expression (p2) points to object 2, then the new object address (tmp +10, where tmp is 0x321 and tmp +10 is 0x32b) is directly assigned (returned) to the pointer to the left of the equal sign in the computational expression (q2, which is 0x32b as shown). If the pointer to the right of the expression (p1) points to the base pointer node, step S333 is performed.
S333, searching whether a node pointing to a new object address exists in the base pointer linked list, and if so, assigning the marked address of the node which exists to a pointer on the left side of the middle sign in the pointer calculation expression; otherwise, the process proceeds to step S334.
As shown in FIG. 3, the linked list of base pointers is looked up for whether there is a node pointing to the address of new object 1 (tmp +1, where tmp is 0x123 and tmp +10 is 0x12 d). If the node exists (the node is the base pointer 1 as shown in the figure), copying (returning) the marked address of the existing node to the original pointer (q 1); otherwise, step S334 is executed.
And S334, creating a base pointer node pointing to the address of the new object, inserting the base pointer node into the base pointer linked list of the object, and assigning the marked address of the newly created node to the pointer on the left side of the equal sign in the pointer calculation expression.
As shown in fig. 3, a base pointer node pointing to the address of the new object 1 (tmp +10, where tmp is 0x123 and tmp +10 is 0x12d) is first created and inserted into the base pointer chain table of this object (base pointer 1 node is inserted after base pointer h node), and then the address of the newly created node after marking is assigned (returned) to the pointer (q1) to the left of the middle sign in the calculation expression (a new address of the base pointer after marking, i.e., & base pointer 1). By the mechanism, nodes of the base pointer linked list are added, and 1 heap object corresponds to one base pointer linked list.
Step S34, a secure heap object release module for monitoring heap object release operation is constructed, and the specific working mechanism of the secure heap object release module is as follows:
step S340. if the heap object releasing operation is monitored, the address of the head node of the base pointer linked list is obtained, the base pointer linked list is traversed, all the nodes on the linked list are juxtaposed to be invalid values, and the step S341 is entered.
Because the assignment (propagation) of the pointer is tracked by the pointer tracker, the parameter (pointer) passed to the release of the secured heap object in the object manager must point to a base pointer head node. Since pointers may point to one address range of an object and there is pointer computation expression pointer propagation, all pointers of one object may point to different addresses. Since the pointer tracker will generate different base pointers for different addresses pointing to the same heap object and link them in a linked list. Therefore, the base pointer linked list of an object has a plurality of base pointer nodes and at least one base pointer head node.
And S341, releasing the corresponding heap object.
And S4, linking the dynamic UAF vulnerability defense component to the processed intermediate language file, and compiling the intermediate language file into a safe executable file.
In the verification stage of UAF vulnerability defense, when a program runs (namely a security executable file is loaded), the program continuously judges the operation type when executing each operation, and if the program executes the original operation (the operation which is not replaced by the inserted pile), the program is normally executed; if the secure heap object allocation operation in the object manager is executed, entering a secure heap object allocation module in the object manager for defense; if the pointer dereferencing operation with the pointer checker is executed, entering the pointer checker for defense; if the operation of the pointer tracker is executed, entering the pointer tracker for defense; if the operation of releasing the safe heap object is executed, entering a safe heap object releasing module in an object manager for defense; and if all the execution is finished, normally exiting.
The above description is only for the preferred embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present application should be covered within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (9)
1. A UAF vulnerability defense method based on a multi-level pointer is characterized by comprising the following steps:
s1, compiling a program to be defended into an intermediate language;
s2, performing instrumentation and/or replacement on operations related to the pointer and the heap object in the intermediate language to obtain a processed intermediate language file;
s3, constructing a dynamic UAF vulnerability defense assembly based on the multistage pointer;
s4, linking the dynamic UAF vulnerability defense component to the processed intermediate language file, and compiling the intermediate language file into a safe executable file;
step S3 includes the following steps:
s31, constructing a safe heap object allocation module for monitoring heap object allocation operation;
s32, constructing a pointer checker for monitoring pointer dereferencing operation;
s33, constructing a pointer tracker for monitoring pointer assignment operation with pointer calculation;
and S34, constructing a safe heap object release module for monitoring heap object release operation.
2. The UAF vulnerability defense method of claim 1, wherein the operations related to pointers and heap objects include: heap object allocation operations, pointer dereferencing operations, pointer assignment operations with pointer computations, and heap object release operations.
3. The UAF vulnerability defense method of claim 1, wherein step S2 includes the steps of:
s20, traversing each operation of the intermediate language, judging the type of the current operation, and if the current operation is a heap object allocation operation, entering the step S21; if the current operation is a pointer dereferencing operation, go to step S22; if the current operation is a pointer assignment operation with pointer calculation, the process goes to step S23; if the current operation is a heap object release operation, go to step S24; if the current operation is other operations, no processing is carried out;
s21, replacing the heap object allocation operation with a safe heap object allocation operation;
s22, inserting a check code by pointer dereferencing operation;
s23, replacing the inserted pile with a pointer assignment operation with tracking pointer calculation by the pointer assignment operation with the pointer calculation;
and S24, replacing the heap object release operation with a safe heap object release operation.
4. The UAF vulnerability defense method according to claim 1, wherein the specific working mechanism of the secure heap object allocation module is as follows:
s310, if the heap object allocation operation is monitored, applying for a first heap memory for storing a head node of a base pointer linked list;
s311, applying for a second heap memory with the same size as the heap object application size, wherein the memory is used for meeting the memory request of the heap object;
s312, enabling a head node of the base pointer linked list to point to a first address of a second heap memory;
s313, marking the address of the head node of the base pointer linked list by inverting the highest bit of the memory address value of the first stack;
and S314, assigning the marked head node address to a pointer allocated to the heap object.
5. The UAF vulnerability defense method according to claim 1, characterized in that the specific working mechanism of the pointer checker is as follows:
s320, if pointer dereferencing operation is monitored, judging whether the highest position of the address to be dereferenced is marked or not, if so, indicating that the pointer points to a base pointer, and entering S321, otherwise, indicating that the pointer points to a non-heap area and directly dereferencing;
s321, reversing the highest bit to remove the mark, dereferencing the address without the mark, reaching the base pointer node, and entering the step S322;
s322, judging whether the base pointer stores the heap object address, if so, dereferencing the address of the object stored by the base pointer once again to reach the heap object; otherwise, the invalid pointer is directly dereferenced, resulting in a program crash.
6. The UAF vulnerability defense method of claim 5, wherein the specific working mechanism of the pointer checker further comprises: and S323, printing the related information triggering the UAF behavior dereferencing pointer and each node of the corresponding base pointer linked list.
7. The UAF vulnerability defense method according to claim 1, characterized in that the specific working mechanism of the pointer tracker is as follows:
s330, if the pointer assignment operation with pointer calculation is monitored, setting a temporary variable, judging whether a pointer on the right of an equal sign in a pointer calculation expression points to a non-heap area or a base pointer node, and if the pointer points to the non-heap area, assigning a heap object address to the temporary variable; if the pointer is the base pointer node, dereferencing the pointer to reach the base pointer node, acquiring the heap object address stored in the base pointer node, and assigning a value to a temporary variable;
step S331, calculating an expression and a temporary variable according to the pointer, and calculating a new object address calculated by the expression;
s332, if the pointer on the right side of the equal sign in the pointer calculation expression points to a non-heap object, directly assigning a new object address to the pointer on the left side of the equal sign in the pointer calculation expression; if the pointer on the right of the equal sign in the pointer calculation expression points to the base pointer node, the step S333 is carried out;
s333, searching whether a node pointing to a new object address exists in the base pointer linked list, and if so, assigning the marked address of the node which exists to a pointer on the left side of the middle sign in the pointer calculation expression; otherwise, go to step S334;
and S334, creating a base pointer node pointing to the address of the new object, inserting the base pointer node into the base pointer linked list of the object, and assigning the marked address of the newly created node to the pointer on the left side of the equal sign in the pointer calculation expression.
8. The UAF vulnerability defense method according to claim 1, wherein the specific working mechanism of the secure heap object release module is as follows:
step S340, if the heap object releasing operation is monitored, acquiring the address of the head node of the base pointer linked list, traversing the base pointer linked list, and juxtaposing all nodes on the linked list into an invalid value, and entering step S341;
and S341, releasing the corresponding heap object.
9. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a computer program which, when executed by a processor, implements the UAF vulnerability defense method of any of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811573649.7A CN109711167B (en) | 2018-12-21 | 2018-12-21 | UAF vulnerability defense method based on multi-level pointers |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811573649.7A CN109711167B (en) | 2018-12-21 | 2018-12-21 | UAF vulnerability defense method based on multi-level pointers |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109711167A CN109711167A (en) | 2019-05-03 |
| CN109711167B true CN109711167B (en) | 2020-08-18 |
Family
ID=66257170
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811573649.7A Active CN109711167B (en) | 2018-12-21 | 2018-12-21 | UAF vulnerability defense method based on multi-level pointers |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109711167B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112487438B (en) * | 2020-12-12 | 2022-11-04 | 南京理工大学 | Heap object Use-After-Free vulnerability detection method based on identifier consistency |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1129070C (en) * | 1998-02-06 | 2003-11-26 | 华为技术有限公司 | Recognition method for internal stored operation error in programming |
| CN102662825B (en) * | 2012-02-22 | 2014-07-16 | 中国人民解放军国防科学技术大学 | Method for detecting memory leakage of heap operational program |
-
2018
- 2018-12-21 CN CN201811573649.7A patent/CN109711167B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN109711167A (en) | 2019-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10241894B2 (en) | Data-scoped dynamic data race detection | |
| US7962901B2 (en) | Using dynamic analysis to improve model checking | |
| US6892286B2 (en) | Shared memory multiprocessor memory model verification system and method | |
| US8352921B2 (en) | Static analysis defect detection in the presence of virtual function calls | |
| Feldman et al. | A wait-free multi-word compare-and-swap operation | |
| US20040205302A1 (en) | Method and system for postmortem identification of falsely shared memory objects | |
| JPH10254716A (en) | Detection of concurrent error in multi-threaded program | |
| JP2008276763A (en) | Memory error detection method | |
| US20130219367A9 (en) | Atomicity violation detection using access interleaving invariants | |
| US20190220403A1 (en) | Decoupling trace data streams using cache coherence protocol data | |
| Fang et al. | Perfblower: Quickly detecting memory-related performance problems via amplification | |
| US9965402B2 (en) | Memory initialization detection system | |
| CN109711167B (en) | UAF vulnerability defense method based on multi-level pointers | |
| Payer | The fuzzing hype-train: How random testing triggers thousands of crashes | |
| Hück et al. | Compiler-aided type tracking for correctness checking of MPI applications | |
| EP2645249A1 (en) | Information processing apparatus, and method of controlling information processing apparatus | |
| Meyer et al. | Decoupling lock-free data structures from memory reclamation for static analysis | |
| Swain et al. | OpenRace: An open source framework for statically detecting data races | |
| Schemmel et al. | A Deterministic Memory Allocator for Dynamic Symbolic Execution | |
| Nowack | Fine-grain memory object representation in symbolic execution | |
| CN116502239B (en) | Memory vulnerability detection method, device, equipment and medium for binary program | |
| CN114153451A (en) | Method for analyzing memory security in C code by using data flow analysis algorithm | |
| Jain et al. | Memory leakage testing using aspects | |
| US20160232074A1 (en) | Detecting uninitialized memory references | |
| Qiang et al. | Mpchecker: Use-after-free vulnerabilities protection based on multi-level pointers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |