Vulnerability nondestructive detection method based on patch association behavior exploration

Abstract

The invention relates to a vulnerability nondestructive detection method based on patch association behavior exploration, and belongs to the technical field of network security. According to the method, the software behavior difference introduced by the bug patch is explored by comparing and analyzing the bug version and the patch version of the binary software, so that the nondestructive detection sample is generated. According to the method, the existence of known vulnerabilities can be accurately detected on the premise of ensuring normal operation of a software system.

Description

Technical Field

[0001] The present invention belongs to the technical field of network security, and in particular relates to a non-destructive vulnerability detection method based on patch association behavior exploration. Background Art

[0002] The purpose of nondestructive vulnerability detection technology is to determine whether a software system has a specified vulnerability by observing its behavior, while avoiding the destructiveness of the vulnerability. Traditional vulnerability detection methods often rely on the crash or abnormal behavior of the software system, which may cause system unavailability or data loss. Therefore, it is of great significance to develop a technology that can accurately detect vulnerabilities while ensuring the normal operation of the system.

[0003] Existing vulnerability detection technologies usually rely on specific versions of software or specific vulnerability features, which makes it difficult to cope with complex software systems and diverse vulnerability types. In addition, traditional detection methods often require manual intervention, are inefficient, and difficult to adapt to the rapidly changing network security environment. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] The technical problem to be solved by the present invention is to design a non-destructive vulnerability detection method to accurately detect the existence of known vulnerabilities while ensuring the normal operation of the software system.

[0006] (II) Technical solution

[0007] In order to solve the above technical problems, the present invention provides a vulnerability non-destructive detection method based on patch association behavior exploration, comprising the following steps:

[0008] Step 1: Prepare input information: receive the vulnerable version software, patch version software, vulnerability crash sample PoC, and the instruction records of the vulnerability crash sample executed on the two versions of software;

[0009] Step 2: Execute the lossless process:

[0010] The Crash-Free module monitors the buffer allocation and filling process of the target software system through dynamic analysis technology, extracts vulnerability element information, identifies allocation and filling pairs directly related to buffer overflow, and passes this information to the sample generation module;

[0011] The sample generation module uses symbolic execution technology and constraint solving technology to generate lossless samples, ensuring that the overflow length is controlled within a reasonable range that does not cause abnormal crashes;

[0012] The first detection determination module: determines whether the non-destructive sample has detection capability; if so, directly outputs the non-destructive sample as a non-destructive detection sample; otherwise, enters the detection process;

[0013] Step 3: Execute the detection process:

[0014] The patch identification module locates the specific location of the vulnerability patch code in the binary program;

[0015] The branch exploration module explores alternative branches that may cause behavioral differences between two versions of the software;

[0016] The sample generation module generates new nondestructive detection samples based on the candidate branches;

[0017] The second detection determination module determines whether the new nondestructive detection sample has the nondestructive detection capability, and outputs the nondestructive detection sample if it has the capability, otherwise it continues to generate new nondestructive detection samples.

[0018] Preferably, in step 1, the instruction execution records when the PoC is executed on the vulnerable version software and the patch version software are obtained by a dynamic instrumentation tool.

[0019] Preferably, in step 2, the Crash-Free module uses a dynamic analysis tool to monitor the memory allocation and padding behavior of OpenSSL when processing PoC, and extracts vulnerability element information such as buffer allocation address, allocation length, padding address, and padding length related to the Heartbleed vulnerability.

[0020] Preferably, in step 2, the sample generation module uses a symbolic execution tool to perform symbolic execution on the Heartbeat request processing function of OpenSSL to extract symbolic expressions related to buffer overflow; uses a constraint solver to solve the symbolic expression to ensure that the overflow length is controlled within a reasonable range that does not cause a crash; and generates a modified Heartbeat request sample, i.e., a lossless sample, which can trigger the vulnerability but will not cause the system to crash.

[0021] Preferably, in step 2, the first detection and judgment module executes the lossless sample on the vulnerability version software and the patch version software respectively, and compares the behavioral differences between the two versions. If there are certain differences in the behaviors of the two versions, it is determined that the lossless sample has detection capabilities and is directly output as a lossless detection sample; otherwise, the detection process is entered.

[0022] Preferably, in step 3, the patch identification module uses a static analysis tool to compare the OpenSSL binary files of the vulnerable version software and the patch version software, locates the patch code related to the Heartbleed vulnerability, records the location information of the patch code, and passes it to the branch exploration module.

[0023] Preferably, in step 3, the branch exploration module executes lossless samples on the vulnerable version software and the patch version software respectively, and records the instruction execution trajectory; uses a dynamic taint analysis tool to analyze the instructions near the patch code, identifies which branches are doubly affected by the patch and the external input lossless sample, records these doubly affected branches as alternative branches, and passes them to the sample generation module.

[0024] Preferably, in step 3, the sample generation module performs dynamic symbolic execution on each alternative branch, constructs constraints so that the vulnerability version and the patch version produce different directions on the branch; generates a new Heartbeat request sample, that is, a new non-destructive detection sample, to ensure that the new non-destructive detection sample can trigger the behavioral differences of the alternative branches; and passes the new non-destructive detection sample to the second detection judgment module.

[0025] Preferably, in step 3, the second detection and judgment module executes new nondestructive detection samples on the vulnerability version software and the patch version software respectively, and compares the behavioral differences between the two versions. If there are certain differences in the behaviors of the two versions, it is determined that the new nondestructive detection sample has detection capabilities and is directly output; otherwise, it continues to generate new nondestructive detection samples.

[0026] The invention also provides a system for implementing the method.

[0027] (III) Beneficial effects

[0028] The present invention generates non-destructive detection samples by comparing and analyzing the differences in software behavior between the vulnerable version and the patched version. It can accurately detect the existence of known vulnerabilities while ensuring that the software system does not crash abnormally. Specifically, this method has the following advantages:

[0029] Nondestructive detection: By generating detection samples that do not cause system crashes, it ensures that the software system runs normally during the detection process.

[0030] Accurate detection: By comparing the behavioral differences between the vulnerable version and the patched version, the existence of the vulnerability can be accurately determined.

[0031] Automatic generation: Use symbolic execution and constraint solving technology to automatically generate non-destructive detection samples and reduce manual intervention.

[0032] Wide applicability: It does not rely on software source code and is applicable to various software systems and vulnerability types. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a framework diagram of the detection subsystem of the present invention;

[0034] Figure 2 This is a typical business flow chart of the system of the present invention. DETAILED DESCRIPTION

[0035] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0036] This paper proposes a nondestructive vulnerability detection method based on patch-related behavior exploration, which compares and analyzes the vulnerability version and patch version of binary software, explores the software behavior differences introduced by the vulnerability patch, and then generates nondestructive detection samples. This method can accurately detect the existence of known vulnerabilities while ensuring the normal operation of the software system.

[0037] The non-destructive detection technology based on patch-related behavior exploration includes two core capabilities: non-destructive capability and detection capability. The non-destructive capability aims to generate samples that avoid the destructiveness of vulnerabilities. Its core design idea is to modify crash samples to obtain non-destructive samples that trigger vulnerabilities without crashing. The detection capability aims to generate samples to determine the existence of vulnerabilities. Its core design idea is to screen branch conditions affected by vulnerability patches and non-destructive samples, promote the execution of different branch directions by modifying non-destructive samples, analyze the potential behavioral differences, and then generate non-destructive detection samples.

[0038] The system consists of two key processes: the non-destructive process (the process pointed to by the red arrow in the figure above) and the detection process ( Figure 1 The green arrow points to the process), and five core modules, Crash-Free module, sample generation module, detection and judgment module, patch identification module, and branch exploration module. The system receives the following multiple input information, including the vulnerable version software, patch version software, vulnerable crash sample (PoC), and the instruction record of the crash sample executed on the two versions; the system returns the lossless detection sample. The input information first enters the lossless process, and after analysis by the Crash-Free module, sample generation module, and detection and judgment module, when it is determined that the lossless sample has detection capability, the lossless sample is directly output as a lossless detection sample; otherwise, it enters the detection process, and after analysis by the patch identification module, branch exploration module, sample generation module, and detection and judgment module, the lossless detection sample is output.

[0039] process Figure 2 As shown in the figure, at the beginning of the process, the input data first outputs vulnerability element information through the crash-free module, and the sample generation module receives the vulnerability element information to generate a lossless sample. After determination, if the lossless sample has the lossless detection capability, the lossless detection sample is immediately output, and the process ends; if the lossless sample does not have the lossless detection capability, the patch recognition module receives the lossless sample to output the vulnerability patch location information, the branch exploration module receives the vulnerability patch location information to output the alternative branch information, the sample generation module receives the alternative branch information to generate a lossless detection sample, and the process ends.

[0040] The input information first enters the "lossless process" as indicated by the red arrow in the figure, and is processed by the Crash-Free module, the sample generation module, and the detection and judgment module. This process generates a lossless sample. The Crash-Free module uses dynamic analysis technology to monitor the buffer allocation and buffer filling of the target software system to extract vulnerability element information including buffer allocation address, allocation length, filling address, filling length, etc., and identifies the allocation and filling pairs directly related to buffer overflow based on the HOTracer technical solution, and passes the relevant information to the sample generation module. The sample generation module receives the vulnerability element information identified by the Crash-Free module, and uses symbolic execution technology to extract symbolic expressions that make the overflow length controllable, and uses constraint solving technology to solve the expression so that the overflow length is controlled within a reasonable range that does not cause abnormal crashes, thereby obtaining a lossless sample. Subsequently, the detection and judgment module receives the lossless sample and determines whether to enter the "detection process" based on the execution of the lossless sample, that is, Figure 1 The process indicated by the green arrow is shown. When the lossless sample is executed in the vulnerable version software and the patch version software, it can make the two versions show different observable behaviors (different output behavior output content, different data packet return data content, etc.), then the lossless sample already has detection capabilities and does not need to enter the detection process. It directly outputs the lossless detection sample and the behavioral characteristics that characterize the existence of the vulnerability. When the lossless sample is executed in the vulnerable version software and the patch version software, it cannot make the two versions show different observable behaviors, then it enters the "detection process", such as Figure 2 shown.

[0041] When the system enters the "detection process", the detection and judgment module provides the lossless samples generated in the early stage to the patch identification module. The role of the patch identification module is to locate the specific location of the vulnerability patch code in the binary program. Therefore, it first needs to record the instruction execution records of the vulnerability version software and the patch version software executing the lossless sample, and combine the static analysis tool Bindiff to locate the actual executed patch content and provide its location information to the branch exploration module. The role of the branch exploration module is to explore alternative branches that may cause behavioral differences between the two versions of the software. After the branch exploration module obtains the patch location information, it performs batch branch search in the instruction execution record, and uses the dynamic taint propagation technology to determine whether the branch is affected by both the patch and the external input information. The branch exploration module will record the branches that meet the conditions as alternative branches and send them to the sample generation module. The role of the sample generation module in the "detection process" is different from that in the "lossless process". Its role is to perform dynamic symbolic execution on the software according to the received alternative branches, so that the software deviates from the original direction in the corresponding branch. For branches that appear in both the vulnerability version and the patch version, the module needs to construct constraints so that the two versions of the software have different directions on the branch, thereby exploring the branches that cause behavioral differences to the greatest extent. For each candidate branch, the sample generation module will generate a new sample, and the detection and judgment module will determine whether the new samples have the ability of non-destructive detection one by one. When a legitimate sample appears, the module will stop judging and output the non-destructive detection sample and the behavioral characteristics that characterize the existence of the vulnerability.

[0042] The above two processes and five modules constitute a non-destructive detection sample generation system, which maximizes the exploration of the behavioral differences between two versions of software based on the two principles of "cautious overflow" (constructing samples with controllable overflow length) and "branch exploration" (changing the established direction of the branch). At the same time, since the branches explored are all "vulnerability patch related", the occurrence of behavioral differences is only related to the existence of the vulnerability, which prevents vulnerability detection from degenerating into version detection.

[0043] When using nondestructive detection samples, users only need to run the nondestructive detection samples on the software system according to the established method of running the original crash samples, and observe the behavior of the software system, and compare this behavior with the behavioral characteristics that characterize the existence of vulnerabilities. If its behavior matches the behavior of the vulnerability, then it means that the software system has a known vulnerability, otherwise it means that the software system does not have a known vulnerability.

[0044] Compared with conventional methods such as version detection and side-channel detection, the advantages of the method of the present invention are: on the one hand, this solution does not require users to master the vulnerability existence information of different software versions. When the software system exhibits specific behavior under the detection sample, it indicates that it has a vulnerability, which also enables the system to better cope with scenarios such as backporting where users directly modify the software system; on the other hand, this method is generally applicable to various software systems and does not rely on software source code, which solves the key problem that solutions such as side-channel detection are highly specific and rely on the professional knowledge of researchers.

[0045] Typical examples:

[0046] The following takes a certain open source network protocol stack (such as OpenSSL) as an example to describe the specific implementation of the present invention in detail. OpenSSL is a widely used open source network protocol stack, commonly used to implement the SSL / TLS protocol, and has been exposed to serious vulnerabilities many times in history (such as the Heartbleed vulnerability). The present invention generates a lossless detection sample by comparing and analyzing the vulnerable version and the patched version of OpenSSL to accurately detect the existence of the vulnerability.

[0047] 1. Input information preparation

[0048] ●Vulnerable version software: for example, OpenSSL 1.0.1f (the version with the Heartbleed vulnerability).

[0049] ●Patched version software: for example, OpenSSL 1.0.1g (the version that fixes the Heartbleed vulnerability).

[0050] ●Vulnerability crash sample (PoC): A malicious data packet that can trigger the Heartbleed vulnerability (for example, sending a Heartbeat request in a specific format).

[0051] ●Instruction log: Instruction execution log when executing PoC samples on vulnerable versions and patched versions (obtained through dynamic instrumentation tools such as Pin or DynamoRIO).

[0052] 2. Lossless process

[0053] 2.1 Crash-Free Module

[0054] ●Objective: Extract vulnerability factor information and ensure that the generated samples will not cause system crashes.

[0055] ●Operation steps:

[0056] 1. Use dynamic analysis tools (such as Valgrind or AddressSanitizer)

[0057] Monitor OpenSSL's memory allocation and padding behavior when processing PoC samples.

[0059] 2. Extract vulnerability element information such as buffer allocation address, allocation length, padding address, padding length, etc. related to the Heartbleed vulnerability.

[0060] 3. Identify allocation, fill pairs that are directly related to buffer overflows and pass this information to the sample generation module.

[0061] 2.2 Sample Generation Module

[0062] ●Goal: Generate lossless samples that do not cause crashes.

[0063] ●Operation steps:

[0064] 1. Use symbolic execution tools (such as KLEE or Angr) to perform symbolic execution on OpenSSL's Heartbeat request processing function to extract symbolic expressions related to buffer overflow.

[0065] 2. Use a constraint solver (such as Z3) to solve the symbolic expression and ensure that the overflow length is within a reasonable range that does not cause a crash.

[0066] 3. Generate a modified Heartbeat request sample (lossless sample) that can trigger the vulnerability but will not cause the system to crash.

[0067] 2.3 Detection and judgment module

[0068] ●Objective: To determine whether a nondestructive sample has detection capability.

[0069] ●Operation steps:

[0070] 1. In the vulnerable version (OpenSSL 1.0.1f) and the patched version (OpenSSL

[0071] 1.0.1g) and executed the lossless samples separately.

[0072] 2. Compare the behavioral differences between the two versions:

[0073] ■Vulnerable version: Additional memory data may be returned

[0074] (Characteristics of the Heartbleed vulnerability).

[0075] ■Patch version: No additional memory data will be returned.

[0076] If the behaviors of the two versions are significantly different (for example, the lengths of the returned data are different), the lossless sample is determined to have detection capabilities and is directly output as a lossless detection sample; otherwise, the detection process is entered.

[0077] 3. Detection process

[0078] 3.1 Patch Identification Module

[0079] ●Goal: Locate the specific location of the vulnerability patch code in the binary program.

[0080] ●Operation steps:

[0081] 1. Use static analysis tools (such as BinDiff) to compare the vulnerable version and patch

[0082] Version of OpenSSL binary files, locating the patch code related to the Heartbleed vulnerability.

[0083] 2. Record the location information of the patch code (e.g., function address, instruction offset) and pass it to the branch exploration module.

[0084] 3.2 Branch Exploration Module

[0085] ●Goal: Explore alternative branches that might result in behavioral differences between the two versions.

[0086] ●Operation steps:

[0087] 1. Execute lossless samples on the vulnerable version and patch version respectively, and record the instruction execution trajectory.

[0088] 2. Use a dynamic taint analysis tool (such as TaintScope) to analyze instructions near the patch code and identify which branches are affected by both the patch and external input (lossless samples).

[0089] 3. Record these branches as alternative branches and pass them to the sample generation module.

[0090] 3.3 Sample Generation Module

[0091] ●Goal: Generate new non-destructive detection samples based on alternative branches.

[0092] ●Operation steps:

[0093] 1. Perform dynamic symbolic execution on each alternative branch and construct constraints so that the vulnerable version and the patch version will have different directions on the branch.

[0094] 2. Generate a new Heartbeat request sample to ensure that the sample can trigger the behavioral differences of the alternative branch.

[0095] 3. Pass the new sample to the detection and judgment module.

[0096] 3.4 Detection and judgment module

[0097] ●Objective: To determine whether new samples have the capability of non-destructive detection.

[0098] ●Operation steps:

[0099] 1. Execute the new sample on the vulnerable version and the patched version respectively.

[0100] 2. Compare the behavioral differences between the two versions:

[0101] ■Vulnerable version: may trigger additional memory read operations.

[0102] ■Patch version: does not trigger additional memory read operations.

[0103] If the behavior difference is obvious, the new sample is judged to have non-destructive detection capability and is output as a non-destructive detection sample; otherwise, new samples are generated.

[0104] 4. Use of non-destructive detection samples

[0105] ●How to use:

[0106] 1. Send the generated lossless detection sample (modified Heartbeat request) to the target OpenSSL server.

[0107] 2. Observe the server's response:

[0108] ■If the server returns additional memory data (such as a response that exceeds the expected length), it indicates that the target system has a Heartbleed vulnerability.

[0109] ■If the server returns a response of normal length, it means that the target system does not have the Heartbleed vulnerability.

[0110] ●Advantages:

[0111] ○ Non-destructive: The detection process will not cause server crash or data loss.

[0112] ○ Accuracy: By comparing behavioral differences, the existence of vulnerabilities can be accurately determined.

[0113] ○Automation: No manual intervention is required, suitable for large-scale vulnerability scanning.

[0114] It can be seen that through the above steps, the present invention successfully realizes the non-destructive detection of the Heartbleed vulnerability of OpenSSL. The method is not only applicable to OpenSSL, but can also be extended to other network protocol stacks and software systems, and has wide applicability and high practical value.

[0115] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A non-destructive vulnerability detection method based on patch association behavior exploration, characterized in that: The following steps are involved: Step 1: Prepare input information: receive the vulnerable version software, patch version software, vulnerability crash sample PoC, and the instruction records of the vulnerability crash sample executed on the two versions of software; Step 2: Execute the lossless process: The Crash-Free module monitors the buffer allocation and filling process of the target software system through dynamic analysis technology, extracts vulnerability element information, identifies allocation and filling pairs directly related to buffer overflow, and passes this information to the sample generation module; The sample generation module uses symbolic execution technology and constraint solving technology to generate lossless samples, ensuring that the overflow length is controlled within a reasonable range that does not cause abnormal crashes; The first detection determination module: determines whether the non-destructive sample has detection capability; if so, directly outputs the non-destructive sample as a non-destructive detection sample; otherwise, enters the detection process; Step 3: Execute the detection process: The patch identification module locates the specific location of the vulnerability patch code in the binary program; The branch exploration module explores alternative branches that may cause behavioral differences between two versions of the software; The sample generation module generates new nondestructive detection samples based on the candidate branches; The second detection determination module determines whether the new nondestructive detection sample has the nondestructive detection capability, and outputs the nondestructive detection sample if it has the capability, otherwise it continues to generate new nondestructive detection samples.

2. The method according to claim 1, characterized in that In step 1, the dynamic instrumentation tool is used to obtain the instruction execution records when executing PoC on the vulnerable version software and the patch version software.

3. The method according to claim 2, characterized in that In step 2, the Crash-Free module uses dynamic analysis tools to monitor the memory allocation and padding behavior of OpenSSL when processing PoC, and extracts vulnerability element information such as buffer allocation address, allocation length, padding address, and padding length related to the Heartbleed vulnerability.

4. The method according to claim 3, characterized in that In step 2, the sample generation module uses the symbolic execution tool to perform symbolic execution on the Heartbeat request processing function of OpenSSL to extract symbolic expressions related to buffer overflow; uses the constraint solver to solve the symbolic expression to ensure that the overflow length is controlled within a reasonable range that does not cause a crash; and generates a modified Heartbeat request sample, i.e., a lossless sample, which can trigger the vulnerability but will not cause the system to crash.

5. The method according to claim 4, characterized in that In step 2, the first detection and judgment module executes the lossless sample on the vulnerable version software and the patch version software respectively, and compares the behavioral differences between the two versions. If there are certain differences in the behaviors of the two versions, it is determined that the lossless sample has detection capabilities and is directly output as a lossless detection sample; otherwise, it enters the detection process.

6. The method according to claim 5, characterized in that In step 3, the patch identification module uses static analysis tools to compare the OpenSSL binary files of the vulnerable version software and the patch version software, locates the patch code related to the Heartbleed vulnerability, records the location information of the patch code, and passes it to the branch exploration module.

7. The method according to claim 6, characterized in that In step 3, the branch exploration module executes lossless samples on the vulnerable version software and the patch version software respectively, and records the instruction execution trajectory; uses the dynamic taint analysis tool to analyze the instructions near the patch code, identifies which branches are affected by both the patch and the external input lossless samples, records these branches that are affected by both as alternative branches, and passes them to the sample generation module.

8. The method according to claim 7, characterized in that In step 3, the sample generation module performs dynamic symbolic execution on each alternative branch, constructs constraints so that the vulnerability version and the patch version produce different directions on the branch; generates a new Heartbeat request sample, that is, a new non-destructive detection sample, to ensure that the new non-destructive detection sample can trigger the behavioral differences of the alternative branches; and passes the new non-destructive detection sample to the second detection judgment module.

9. The method according to claim 8, characterized in that In step 3, the second detection judgment module executes the new non-destructive detection sample on the vulnerable version software and the patch version software respectively, and compares the behavioral differences between the two versions. If there are certain differences in the behaviors of the two versions, it is determined that the new non-destructive detection sample has detection capabilities and is directly output; otherwise, it continues to generate new non-destructive detection samples.

10. A system for implementing the method according to any one of claims 1 to 9.

Images