Method and system for off-by-one vulnerability detection facing executable files

Abstract

The application discloses an off-by-one vulnerability detection method and system for executable files, and the method comprises the following steps: decompiling an executable file to form an intermediate language; performing static analysis on the executable file to detect a pointer set pointing to an allocated heap block and suspicious path information; performing global variable tracking analysis to find out a memory address pointed to by a global pointer and read-write operations on a memory space; screening functions with the same allocation behavior, and if the same pointer is referenced, the functions are combined in a pointer data set to remove redundant functions; performing dynamic symbolic execution, selecting suspicious branches and paths according to path selection rules, and when a function with an allocation behavior is called, recording the size and address of the allocated heap block; continuing to detect the operation of allocating the heap block, recording the length of the write information when read-write operations are performed on the address, and judging the vulnerability. The method can effectively locate the vulnerability position and realize full coverage of the automatic detection of off-by-one vulnerabilities.

Description

Technical Field

[0001] This invention relates to an off-by-one vulnerability detection method and system for executable files, belonging to the field of network security technology. Background Technology

[0002] Off-by-one vulnerabilities are a common type of vulnerability in information security attack and defense competitions, offering a wealth of flexible exploitation methods related to buffers. In the stack, this vulnerability can be used to overwrite the LSB of the ebp, thereby modifying the EIP pointer. In the heap, it can overwrite the inuse bit of the heap block size field, combining it with the unlink mechanism to hijack control flow; it can also modify the heap block size, expanding or shrinking the heap block to read and write target memory space. Furthermore, its exploitation in actual software and operating system components is also frequently seen. The diverse exploitation methods of off-by-one vulnerabilities across different scenarios make automated detection of these vulnerabilities difficult to fully cover.

[0003] Currently, scholars have proposed various solutions to the vulnerability detection problem. (I) In 2013, Bugalyze.com partially decompiled the executable file into intermediate language and used data flow analysis to detect whether there were pointers to freed heap blocks. If so, it would indicate the presence of a UAF (Usage-Based Default). However, it did not perform alias analysis or path reachability analysis, which could lead to false positives and false negatives. (II) GUEB uses dedicated value analysis to track heap operations and address transfers, while also considering alias issues. It then uses the above results to statically identify UAF vulnerabilities and finally extracts a subgraph for the UAF to describe the location of dangling pointers, including their placement, release, and use. However, it does not verify the path reachability during actual operation. Although the off-by-one vulnerability that this invention focuses on is a type of UAF, it changes the content of free heap blocks by writing to allocated heap blocks. Therefore, UAF detection is generally not applicable to off-by-one vulnerabilities targeting heap exploitation. (III) In 2015, the China Academy of Engineering Physics published a paper in ICCC proposing a highly automated off-by-one vulnerability assessment technique for executable files. By repeatedly inputting samples and using WinDbg to check if the format of the EBP value in the crashed program is correct and whether the EIP is corrupted by crash instructions, the vulnerability is considered to be triggered and highly exploitable, thus generating Proof-of-Concept (POC) code. This method only targets off-by-one stack-related exploits and is more suitable for 32-bit environments. In 64-bit operating systems, the first seven parameters are preferentially stored in registers rather than on the stack, making stack-related off-by-one vulnerabilities more difficult to trigger.

[0004] The aforementioned traditional methods are all insufficient for effectively locating vulnerabilities and solving the problem of comprehensive automated detection coverage for off-by-one vulnerabilities. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes an off-by-one vulnerability detection method and system for executable files. It can effectively locate vulnerability positions and achieve comprehensive automated detection of off-by-one vulnerabilities.

[0006] The technical solution adopted by this invention to solve its technical problem is as follows:

[0007] On one hand, the present invention provides an off-by-one vulnerability detection method for executable files, comprising the following steps:

[0008] Decompiling the executable file's machine code yields assembly language, which is then divided into six semantic rules to form an intermediate language.

[0009] Static analysis of the executable file is performed using intermediate language to detect the set of pointers to allocated heap blocks and suspected path information;

[0010] The global variables of the executable file are traced and analyzed to find the memory addresses pointed to by global pointers and the read and write operations on the memory space;

[0011] Filter functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, merge them in the pointer dataset and remove redundant functions.

[0012] Perform dynamic symbolic execution on the executable file, select suspicious branches and paths according to path selection rules, and record the size and address of the allocated heap block when a function call involves allocation.

[0013] Continue to examine operations on allocated heap blocks. When reading or writing to this address, record the length of the written information to determine if an off-by-one vulnerability exists.

[0014] As one possible implementation of this embodiment, the division of the assembly language into six semantic rules includes:

[0015] The MOV rule means updating the target with the original information;

[0016] The NOP rule means that neither the source nor the target information will be processed.

[0017] The ADD rule indicates that source taint information is added to the target information;

[0018] LEA rules are used to indicate the case where the instruction lea calculates a pointer;

[0019] CHA rules represent the interchangeable values ​​of source taint information and target taint information;

[0020] CLE rules clearly indicate target taint information.

[0021] As one possible implementation of this embodiment, the step of using intermediate language to perform static analysis on the executable file and detect the set of pointers to allocated heap blocks and suspected path information includes:

[0022] Find the assignment operation from the known reverse path, check if the left side of the assignment operation belongs to the unchecked pointer variable set ToCheckedPtr, and if so, add the pointer on the right side to the pointer variable set ToCheckedPtr.

[0023] Check if the pointer on the right is in the already checked pointer variable set CheckedPtr. If not, put it into the pointer variable set MallocChunkPtr that points to allocated heap blocks.

[0024] Move the pointer of the check assignment operation into the already checked pointer variable set CheckedPtr;

[0025] Find the forward path that is in the same direction as the control flow, and check if there is an operation that dereferences the pointers to this pointer set. If so, consider it as a suspected path.

[0026] As one possible implementation of this embodiment, the step of tracking and analyzing the global variables of the executable file to find the memory address pointed to by the global pointer and the read / write operations on the memory space includes:

[0027] The global variable analysis algorithm is used to capture assignment statements containing combinations of DS register and offset, and the offset addresses are recorded to form a global pointer dataset;

[0028] The global pointer dataset is merged into the set of pointer variables that point to allocated heap blocks, MallocChunkPtr.

[0029] As one possible implementation of this embodiment, the step of filtering functions with the same allocation behavior from functions with allocation behavior, merging functions that reference the same pointer within the pointer dataset, and removing redundant functions includes:

[0030] Obtain the address and parameter information of the known function BaseFunc that has allocation behavior and the function TagFunc that calls the function BaseFunc;

[0031] If the parameters of two functions have an alias relationship, and the TagFunc parameter contains a pointer to an allocated heap block, then the TagFunc function is placed into the set of pointer variables of the allocated heap block, and the function address, name and parameter information are stored.

[0032] Repeat the above process iteratively to find all functions with allocation behavior and pointers to free heap blocks.

[0033] As one possible implementation of this embodiment, the step of selecting suspicious branches and paths based on path selection rules includes:

[0034] During the branch selection process, prioritize branches containing the suspected path;

[0035] Choose the path closest to the allocation point before the allocation point;

[0036] When branching between the allocation point and the set of pointer variables MallocChunkPtr that points to already allocated heap blocks, the path closer to the pointer to the allocated heap block is selected.

[0037] In other cases, the path is selected randomly.

[0038] As one possible implementation of this embodiment, the step of continuing to detect the operation on the allocated heap block, recording the length of the written information when performing read and write operations on the address, and determining whether there is an off-by-one vulnerability includes: if the size of the written information is one byte more than the user data space of the heap block, then an overflow is reported, an off-by-one vulnerability exists, and an error report is generated.

[0039] On the other hand, an off-by-one vulnerability detection system for executable files provided by embodiments of the present invention includes:

[0040] The decompilation module is used to decompile the machine code of executable files to obtain assembly language, and then divides the assembly language into six semantic rules to form an intermediate language.

[0041] The heap block detection module is used to perform static analysis on the executable file using intermediate language to detect the set of pointers pointing to allocated heap blocks and suspected path information;

[0042] The global pointer tracing module is used to trace and analyze the global variables of the executable file, find the memory addresses pointed to by global pointers and the read and write operations on the memory space;

[0043] The function filtering module filters functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, they are merged in the pointer dataset to remove redundant functions.

[0044] The dynamic symbolic execution module performs dynamic symbolic execution on the executable file, selects suspicious branches and paths based on path selection rules, and records the size and address of the allocated heap block when a function call involves allocation.

[0045] The vulnerability detection module continues to detect operations on allocated heap blocks. When reading or writing to this address, it records the length of the written information to determine whether an off-by-one vulnerability exists.

[0046] As one possible implementation of this embodiment, the off-by-one vulnerability detection system uses the S2E symbolic execution tool.

[0047] Thirdly, an embodiment of the present invention provides a computer device including a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the AGV simulation device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the above-described off-by-one vulnerability detection method for any executable file.

[0048] Fourthly, embodiments of the present invention provide a storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described off-by-one vulnerability detection method for any executable file.

[0049] The technical solutions of the embodiments of the present invention can have the following beneficial effects:

[0050] A new static analysis scheme is proposed. During the static analysis process, allocation point and usage point information are collected, and functions with release behavior and a set of pointers to allocated heap blocks are found. This information is used as the basis for dynamic analysis path selection, eliminating irrelevant paths and improving the efficiency of dynamic symbolic execution.

[0051] This invention utilizes static analysis to filter and record suspicious paths, identifying all pointers pointing to allocated heap blocks. Simultaneously, it leverages symbolic execution path exploration to monitor heap block allocation for executable files and combines taint analysis to trace pointer propagation, thereby effectively locating vulnerability positions and achieving full coverage of automated detection for off-by-one vulnerabilities. Attached Figure Description

[0052] Figure 1 This is a flowchart illustrating an off-by-one vulnerability detection method for executable files according to an exemplary embodiment;

[0053] Figure 2 This is a schematic diagram of an off-by-one vulnerability detection system for executable files, according to an exemplary embodiment. Detailed Implementation

[0054] The present invention will be further described below with reference to the accompanying drawings and embodiments:

[0055] To clearly illustrate the technical features of this solution, the invention will be described in detail below through specific embodiments and in conjunction with the accompanying drawings. The following disclosure provides many different embodiments or examples for implementing different structures of the invention. To simplify the disclosure of the invention, components and arrangements of specific examples are described below. Furthermore, reference numerals and / or letters may be repeated in different examples. This repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. It should be noted that the components illustrated in the drawings are not necessarily drawn to scale. Descriptions of well-known components, processing techniques, and processes are omitted in this invention to avoid unnecessarily limiting the invention.

[0056] like Figure 1 As shown, the off-by-one vulnerability detection method for executable files provided in this embodiment of the invention includes the following steps:

[0057] Decompiling the executable file's machine code yields assembly language, which is then divided into six semantic rules to form an intermediate language.

[0058] Static analysis of the executable file is performed using intermediate language to detect the set of pointers to allocated heap blocks and suspected path information;

[0059] The global variables of the executable file are traced and analyzed to find the memory addresses pointed to by global pointers and the read and write operations on the memory space;

[0060] Filter functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, merge them in the pointer dataset and remove redundant functions.

[0061] Perform dynamic symbolic execution on the executable file, select suspicious branches and paths according to path selection rules, and record the size and address of the allocated heap block when a function call involves allocation.

[0062] Continue to examine operations on allocated heap blocks. When reading or writing to this address, record the length of the written information to determine if an off-by-one vulnerability exists.

[0063] As one possible implementation of this embodiment, the off-by-one vulnerability detection process is divided into static analysis and dynamic analysis. It searches for functions with release behavior and a set of pointers to allocated heap blocks, which serve as the basis for dynamic analysis path selection, eliminating irrelevant paths and improving the efficiency of dynamic symbolic execution. During dynamic analysis, the dynamic symbolic execution approach is adopted to explore according to the selected path, record the size of the allocated heap block, and compare it with the length of the written data. If they do not match and differ by one byte, an off-by-one vulnerability is detected, and an error report is generated.

[0064] As one possible implementation of this embodiment, the division of the assembly language into six semantic rules includes:

[0065] The MOV rule means that the original information is updated to the target, src = des, and the taint information in src overwrites the information in des;

[0066] The NOP rule means that no processing is done on the source and destination information, i.e., src=src, des=des. It is usually applicable to jump instructions such as cmp and jz.

[0067] The ADD rule means adding source taint information to the target information, i.e.: des = des + src;

[0068] The LEA rule, because the lea process is relatively complex, is used separately to represent the case where the instruction lea calculates the pointer;

[0069] The CHA rule represents the exchange of source taint information and target taint information, i.e.: tmp = src, src

[0070] =des,des=t. This is equivalent to two MOV rules;

[0071] CLE rule indicates that the target taint information is cleared, i.e., des = 0.

[0072] As one possible implementation of this embodiment, the machine code of the executable file is decompiled using the tool IDA to obtain the assembly language. To focus on pointer propagation-related instructions, the assembly language is divided into six semantic rules, which simplifies the difficulty of assembly language analysis and the scope of the target code, forming an intermediate language that is convenient for further analysis.

[0073] As one possible implementation of this embodiment, the step of using intermediate language to perform static analysis on the executable file and detect the set of pointers to allocated heap blocks and suspected path information includes:

[0074] Find the assignment operation from the known reverse path, check if the left side of the assignment operation belongs to the unchecked pointer variable set ToCheckedPtr, and if so, add the pointer on the right side to the pointer variable set ToCheckedPtr.

[0075] Check if the pointer on the right is in the already checked pointer variable set CheckedPtr. If not, put it into the pointer variable set MallocChunkPtr that points to allocated heap blocks.

[0076] Move the pointer of the check assignment operation into the already checked pointer variable set CheckedPtr;

[0077] Find the forward path that is in the same direction as the control flow, and check if there is any operation that dereferences the pointers to this pointer set. Dereferencing means that there is reading and writing of free heap blocks. If so, it is considered as suspected path information.

[0078] As one possible implementation of this embodiment, the step of tracking and analyzing the global variables of the executable file to find the memory address pointed to by the global pointer and the read / write operations on the memory space includes:

[0079] The global variable analysis algorithm is used to capture assignment statements containing combinations of DS register and offset, and the offset addresses are recorded to form a global pointer dataset;

[0080] The global pointer dataset is merged into the set of pointer variables that point to allocated heap blocks, MallocChunkPtr.

[0081] Global variables are declared outside functions, their addresses are allocated in the BSS segment, and they remain largely unchanged during program execution. To reduce the complexity of static analysis, a different lookup method is used compared to that for local variables.

[0082] As one possible implementation of this embodiment, the step of filtering functions with the same allocation behavior from functions with allocation behavior, merging functions that reference the same pointer within the pointer dataset, and removing redundant functions includes:

[0083] Obtain the address and parameter information of the known function BaseFunc that has allocation behavior and the function TagFunc that calls the function BaseFunc;

[0084] If the parameters of two functions have an alias relationship, and the TagFunc parameter contains a pointer to an allocated heap block, then the TagFunc function is placed into the set of pointer variables of the allocated heap block, and the function address, name and parameter information are stored.

[0085] Repeat the above process iteratively to find all functions with allocation behavior and pointers to free heap blocks.

[0086] As one possible implementation of this embodiment, the step of selecting suspicious branches and paths based on path selection rules includes:

[0087] During the branch selection process, prioritize branches containing the suspected path;

[0088] Choose the path closest to the allocation point before the allocation point;

[0089] When branching between the allocation point and the set of pointer variables MallocChunkPtr that points to already allocated heap blocks, the path closer to the pointer to the allocated heap block is selected.

[0090] In other cases, the path is selected randomly.

[0091] To quantize the distance between code blocks, this invention analyzes the path and uses a single-source path shortest algorithm to quantize the path.

[0092] As one possible implementation of this embodiment, the step of continuing to detect the operation on the allocated heap block, recording the length of the written information when performing read and write operations on the address, and determining whether there is an off-by-one vulnerability includes: if the size of the written information is one byte more than the user data space of the heap block, then an overflow is reported, an off-by-one vulnerability exists, and an error report is generated.

[0093] like Figure 2 As shown, the off-by-one vulnerability detection system for executable files provided in this embodiment of the invention includes:

[0094] The decompilation module is used to decompile the machine code of executable files to obtain assembly language, and then divides the assembly language into six semantic rules to form an intermediate language.

[0095] The heap block detection module is used to perform static analysis on the executable file using intermediate language to detect the set of pointers pointing to allocated heap blocks and suspected path information;

[0096] The global pointer tracing module is used to trace and analyze the global variables of the executable file, find the memory addresses pointed to by global pointers and the read and write operations on the memory space;

[0097] The function filtering module filters functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, they are merged in the pointer dataset to remove redundant functions.

[0098] The dynamic symbolic execution module performs dynamic symbolic execution on the executable file, selects suspicious branches and paths based on path selection rules, and records the size and address of the allocated heap block when a function call involves allocation.

[0099] The vulnerability detection module continues to detect operations on allocated heap blocks. When reading or writing to this address, it records the length of the written information to determine whether an off-by-one vulnerability exists.

[0100] As one possible implementation of this embodiment, the off-by-one vulnerability detection system uses the S2E symbolic execution tool.

[0101] As one possible implementation of this embodiment, the assembly language obtained by decompiling the executable machine code is divided into six semantic rules to form an intermediate language. The BeaEngine decompilation engine is selected to decompile the machine instructions into assembly code for semantic analysis. Several important functions and structures are reimplemented and encapsulated. The REASM structure stores instruction-related information generated during and at the end of the decompilation process, such as instruction address and assembly language type. The INSTR structure records detailed information of the assembly instructions, serving as key information for the subsequent taint analysis module. The ARGUMENT structure stores operand information. `read_instr` is a key function for instruction parsing. It reads the REASM instruction information from the address `addr`. Storage space is allocated for the instruction, i.e., values ​​are assigned to the REASM structure variables `baddr` and `addr` to determine the assembly instruction storage address. The `reasm()` function is called to analyze the machine code and output REASM type assembly information.

[0102] As one possible implementation of this embodiment, the operation of detecting and allocating heap blocks is performed using the plugin FunctionMonitor provided by S2E. FunctionMonitor can capture machine instructions of call / ret and call the corresponding handlers to monitor the heap block allocation status of the target function. Therefore, the plugin can be used to hook heap-related operation functions to obtain parameter information and return values, thereby obtaining the pointer pointer and the size of the user input data.

[0103] As one possible implementation of this embodiment, recording the size and address of the allocated heap block includes: constructing a structure and forming a queue to store the address and size of the allocated heap block. The queue data structure adopts klee::ImmutableMap, which is implemented by klee, allowing multi-threaded access and instantiating shareable objects. A reverse queue also needs to be constructed to record all pointers pointing to the same allocated heap block, facilitating information backtracking, and used to store information such as the address and size of the allocated memory space.

[0104] As one possible implementation of this embodiment, the step of selecting suspicious branches and paths based on rules, using ksc to generate a Lua parser for the input file, and embedding this parser into the S2E configuration file so that it can be accessed by S2E. By selectively applying the s2e_make_symbolic processing specification in the input definition, more targeted symbolic execution can be achieved.

[0105] As one possible implementation of this embodiment, the tracking of pointers to allocated heap blocks includes: marking user input as taints, tracking the propagation of taints during the dynamic operation of the program, and indicating safe propagation when the propagation of taints conforms to a pre-defined information flow strategy.

[0106] Thirdly, a computer device includes a processor, a memory, and a bus, the memory storing machine-readable instructions executable by the processor, wherein when the computer device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the tire sidewall cord threshold segmentation method based on any of the above descriptions.

[0107] An embodiment of the present invention provides a computer device including a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of any of the above-described methods for threshold segmentation of tire sidewall cords based on local adaptive windows.

[0108] Specifically, the aforementioned memory and processor can be general-purpose memory and processor, without any specific limitations. When the processor runs the computer program stored in the memory, it can execute the aforementioned tire sidewall cord threshold segmentation method based on local adaptive windows.

[0109] Those skilled in the art will understand that the structure of the computer device does not constitute a limitation on the computer device, and may include more or fewer components than shown in the figure, or combine some components, or split some components, or have different component arrangements.

[0110] In some embodiments, the computer device may further include a touchscreen for displaying a graphical user interface (e.g., an application launch screen) and receiving user actions on the graphical user interface (e.g., launching an application). Specifically, the touchscreen may include a display panel and a touch panel. The display panel may be configured as an LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or similar type. The touch panel can collect user touch or non-touch operations on or near it and generate pre-set operation instructions, such as user actions using fingers, styluses, or any suitable object or accessory on or near the touch panel. Additionally, the touch panel may include a touch detection device and a touch controller. The touch detection device detects the user's touch orientation and posture, and detects the signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives touch information from the touch detection device, converts it into information that the processor can process, sends it to the processor, and can also receive and execute commands from the processor. Furthermore, touch panels can be implemented using various types of sensors, including resistive, capacitive, infrared, and surface acoustic wave sensors, as well as any future technologies. Moreover, the touch panel can cover the display panel. Users can operate on or near the touch panel, which is covered by the graphical user interface displayed on the display panel. After detecting the operation on or near the touch panel, the touch panel transmits it to the processor to determine the user input. The processor then responds to the user input by providing corresponding visual output on the display panel. Additionally, the touch panel and display panel can be implemented as two separate components or integrated together.

[0111] Corresponding to the above application startup method, this embodiment of the invention also provides a storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described sidewall cord threshold segmentation method based on any local adaptive window.

[0112] The application launch device provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The device provided in this application embodiment has the same implementation principle and technical effects as the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0113] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0114] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0115] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0116] In addition, the functional modules in the embodiments provided in this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0117] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0120] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An off-by-one vulnerability detection method for an executable file, characterized by, Includes the following steps: The machine code of the executable file is decompiled to obtain assembly language, which is then divided into six semantic rules to form an intermediate language; the six semantic rules for dividing the assembly language include: The MOV rule means updating the target with the original information; The NOP rule means that neither the source nor the target information will be processed. The ADD rule indicates that source taint information is added to the target information; LEA rules are used to indicate the case where the instruction lea calculates a pointer; CHA rules represent the interchangeable values ​​of source taint information and target taint information; CLE rules clearly indicate the target taint information; Static analysis of the executable file is performed using intermediate language to detect the set of pointers to allocated heap blocks and suspected path information; The global variables of the executable file are traced and analyzed to find the memory addresses pointed to by global pointers and the read and write operations on the memory space; Filter functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, merge them in the pointer dataset and remove redundant functions. Perform dynamic symbolic execution on the executable file, select suspicious branches and paths according to path selection rules, and record the size and address of the allocated heap block when a function call involves allocation. Continue to examine operations on allocated heap blocks. When reading or writing to this address, record the length of the written information to determine if an off-by-one vulnerability exists.

2. The method of claim 1, wherein the off-by-one vulnerability detection method is executable file oriented, and The static analysis of the executable file using intermediate language to detect the set of pointers to allocated heap blocks and suspected path information includes: Find the assignment operation from the known reverse path, check if the left side of the assignment operation belongs to the unchecked pointer variable set ToCheckedPtr, and if so, add the pointer on the right side to the pointer variable set ToCheckedPtr. Check if the pointer on the right is in the already checked pointer variable set CheckedPtr. If not, put it into the pointer variable set MallocChunkPtr that points to allocated heap blocks. Move the pointer of the check assignment operation into the already checked pointer variable set CheckedPtr; Find the forward path that is in the same direction as the control flow, and check if there is an operation that dereferences the pointers to this pointer set. If so, consider it as a suspected path.

3. The method of claim 1, wherein the off-by-one vulnerability detection method is executable file oriented, and The process of tracing and analyzing the global variables of the executable file to find the memory addresses pointed to by global pointers and the read and write operations on the memory space includes: The global variable analysis algorithm is used to capture assignment statements containing combinations of DS register and offset, and the offset addresses are recorded to form a global pointer dataset; The global pointer dataset is merged into the set of pointer variables that point to allocated heap blocks, MallocChunkPtr.

4. The method of claim 1, wherein the off-by-one vulnerability detection method is executable file oriented, and The process of filtering functions with the same allocation behavior from those with allocation behavior, merging functions that reference the same pointer within the pointer dataset, and removing redundant functions includes: Obtain the address and parameter information of the known function BaseFunc that has allocation behavior and the function TagFunc that calls the function BaseFunc; If the parameters of two functions have an alias relationship, and the TagFunc parameter contains a pointer to an allocated heap block, then the TagFunc function is placed into the set of pointer variables of the allocated heap block, and the function address, name and parameter information are stored. Repeat the above two steps iteratively to find all functions with allocation behavior and pointers to free heap blocks.

5. The method of claim 1, wherein the off-by-one vulnerability detection method is executable file oriented, and The selection of suspicious branches and paths based on path selection rules includes: During the branch selection process, prioritize branches containing the suspected path; Choose the path closest to the allocation point before the allocation point; When branching between the allocation point and the set of pointer variables MallocChunkPtr that points to already allocated heap blocks, the path closer to the pointer to the allocated heap block is selected. In other cases, the path is selected randomly.

6. The method of claim 1, wherein the off-by-one vulnerability detection method is executable file oriented. The continued detection of operations on the allocated heap block, when performing read and write operations on the address, records the length of the written information and determines whether an off-by-one vulnerability exists. This includes: if the size of the written information is one byte larger than the user data space of the heap block, an overflow is reported, an off-by-one vulnerability exists, and an error report is generated.

7. An off-by-one vulnerability detection system oriented to executable files, characterized in that, include: The decompilation module is used to decompile the machine code of an executable file to obtain assembly language, and then divides the assembly language into six semantic rules to form an intermediate language; the division of the assembly language into six semantic rules includes: The MOV rule means updating the target with the original information; The NOP rule means that neither the source nor the target information will be processed. The ADD rule indicates that source taint information is added to the target information; LEA rules are used to indicate the case where the instruction lea calculates a pointer; CHA rules represent the interchangeable values ​​of source taint information and target taint information; CLE rules clearly indicate the target taint information; The heap block detection module is used to perform static analysis on the executable file using intermediate language to detect the set of pointers pointing to allocated heap blocks and suspected path information; The global pointer tracing module is used to trace and analyze the global variables of the executable file, find the memory addresses pointed to by global pointers and the read and write operations on the memory space; The function filtering module filters functions with the same allocation behavior from those with allocation behavior. If they reference the same pointer, they are merged in the pointer dataset to remove redundant functions. The dynamic symbolic execution module performs dynamic symbolic execution on the executable file, selects suspicious branches and paths based on path selection rules, and records the size and address of the allocated heap block when a function call involves allocation. The vulnerability detection module continues to detect operations on allocated heap blocks. When reading or writing to this address, it records the length of the written information to determine whether an off-by-one vulnerability exists.

8. The executable file oriented off-by-one vulnerability detection system of claim 7, wherein, The off-by-one vulnerability detection system uses the S2E symbolic execution tool.

9. A computer device, comprising: The computer device comprises a processor, a memory and a bus, the memory stores machine readable instructions executable by the processor, when the computer device is running, the processor communicates with the memory through the bus, the processor executes the machine readable instructions to execute the steps of the executable file-oriented off-by-one vulnerability detection method as any one of claims 1-6.

Images