A vulnerability lossless detection method based on patch correlation behavior exploration

Abstract

This invention relates to a non-destructive vulnerability detection method based on patch-related behavior exploration, belonging to the field of network security technology. This invention compares and analyzes the vulnerable versions and patch versions of binary software to explore the differences in software behavior introduced by the vulnerability patches, thereby generating non-destructive detection samples. This method can accurately detect the existence of known vulnerabilities while ensuring the normal operation of the software system.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a non-destructive vulnerability detection method based on patch association behavior exploration. Background Technology

[0002] Non-destructive vulnerability detection technology aims to determine the presence of specified vulnerabilities by observing the behavior of software systems, while simultaneously preventing the destructive potential of these vulnerabilities. Traditional vulnerability detection methods often rely on software system crashes or abnormal behavior, which can lead to system unavailability or data loss. Therefore, developing a technology that can accurately detect vulnerabilities while ensuring the normal operation of the system is of great significance.

[0003] Existing vulnerability detection technologies typically rely on specific software versions or specific vulnerability characteristics, making them ill-suited for complex software systems and diverse vulnerability types. Furthermore, traditional detection methods often require manual intervention, resulting in inefficiency and difficulty adapting to rapidly changing cybersecurity environments. Summary of the Invention

[0004] (a) Technical problems to be solved

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

[0006] (II) Technical Solution

[0007] To address the aforementioned technical problems, this invention provides a non-destructive vulnerability detection method based on patch association behavior exploration, comprising the following steps:

[0008] Step 1, Input Information Preparation: Receive the vulnerable version software, the patched version software, the vulnerability crash sample PoC, and the instruction records executed by the vulnerability crash sample on both versions of the software;

[0009] Step 2: Perform the non-destructive 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 and constraint solving techniques to generate lossless samples, ensuring that the overflow length is controlled within a reasonable range that does not cause abnormal crashes.

[0012] First detection and determination module: Determines whether the non-destructive sample has detection capability; if it does, directly outputs the non-destructive sample as the non-destructive detection sample; otherwise, proceeds to the detection process.

[0013] Step 3: Execute the detection process:

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

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

[0016] The sample generation module generates new non-destructive testing samples based on the alternative branches;

[0017] The second detection and determination module determines whether the new non-destructive testing sample has non-destructive testing capability. If it does, it outputs the non-destructive testing sample; otherwise, it continues to generate new non-destructive testing samples.

[0018] Preferably, in step 1, the instruction execution records when executing the PoC on the vulnerable version software and the patched version software are obtained through a dynamic instrumentation tool.

[0019] Preferably, 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.

[0020] Preferably, in step 2, the sample generation module uses a symbolic execution tool to perform symbolic execution on the Heartbeat request handling function of OpenSSL, extracts symbolic expressions related to buffer overflow, solves the symbolic expressions using a constraint solver 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 determination module executes the lossless sample on the vulnerable version software and the patched version software respectively, and compares the behavioral differences between the two versions. If the behavior of the two versions is different, the lossless sample is determined to have detection capability 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 non-destructive samples on the vulnerable version software and the patched version software respectively, and records the instruction execution trajectory; it uses a dynamic taint analysis tool to analyze the instructions near the patch code, identifies which branches are affected by both the patch and the externally input non-destructive samples, records these branches affected by both as candidate branches, and passes them to the sample generation module.

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

[0025] Preferably, in step 3, the second detection and determination module executes new non-destructive detection samples on the vulnerability version software and the patch version software respectively, and compares the behavioral differences between the two versions. If the behavior of the two versions is different, the new non-destructive detection sample is determined to have detection capability and is directly output; otherwise, new non-destructive detection samples continue to be generated.

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

[0027] (III) Beneficial Effects

[0028] This invention generates lossless detection samples by comparing and analyzing the differences in software behavior between vulnerable versions and patched versions. This allows for accurate detection of known vulnerabilities without causing abnormal crashes in the software system. Specifically, this method has the following advantages:

[0029] Non-destructive testing: By generating test samples that do not cause system crashes, the software system is ensured to operate normally during the testing process.

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

[0031] Automated generation: Using symbolic execution and constraint solving techniques, non-destructive testing samples are generated automatically, reducing human intervention.

[0032] Wide applicability: It does not depend on the software source code and is applicable to various software systems and vulnerability types. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the detection subsystem of the present invention;

[0034] Figure 2 This is a typical business process diagram of the system of the present invention. Detailed Implementation

[0035] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0036] This invention proposes a non-destructive vulnerability detection method based on patch-related behavior exploration. By comparing and analyzing the vulnerable version and patch version of binary software, it explores the differences in software behavior introduced by the vulnerability patch, and then generates non-destructive detection samples. This method can accurately detect the existence of known vulnerabilities while ensuring the normal operation of the software system.

[0037] Non-destructive probing technology based on patch-related behavior exploration comprises two core capabilities: non-destructive capability and probing capability. The non-destructive capability aims to generate samples that avoid the destructive effects of vulnerabilities. Its core design idea is to modify crash samples to obtain non-destructive samples that trigger vulnerabilities without causing crashes. The probing capability aims to generate samples that determine the existence of vulnerabilities. Its core design idea is to screen branch conditions affected by vulnerability patches and non-destructive samples, modify non-destructive samples to induce execution of different branch paths, analyze the potential behavioral differences, and thus generate non-destructive probing samples.

[0038] The system comprises two key processes: a non-destructive process (indicated by the red arrow in the diagram above) and a detection process (…). Figure 1 The system (with the green arrow pointing to the process) consists of five core modules: Crash-Free, Sample Generation, Detection and Judgment, Patch Identification, and Branch Exploration. The system receives multiple inputs, including the vulnerable software version, the patched software version, a vulnerability crash sample (PoC), and the instruction records executed by the crash sample on both versions. The system returns a non-destructive detection sample. Input information first enters the non-destructive process, where it is analyzed by the Crash-Free, Sample Generation, and Detection and Judgment modules. If the non-destructive sample is determined to have detection capabilities, it is directly output as a non-destructive detection sample; otherwise, it enters the detection process, where it is analyzed by the Patch Identification, Branch Exploration, Sample Generation, and Detection and Judgment modules, ultimately outputting a non-destructive detection sample.

[0039] process Figure 2 As shown, the process begins with the input data first being processed by the crash-free module to generate vulnerability element information. The sample generation module receives the vulnerability element information and generates a non-destructive sample. If the non-destructive sample has non-destructive testing capabilities, it immediately outputs a non-destructive testing sample, and the process ends. If the non-destructive sample does not have non-destructive testing capabilities, the patch identification module receives the non-destructive sample and generates vulnerability patch location information, the branch exploration module receives the vulnerability patch location information and generates alternative branch information, and the sample generation module receives the alternative branch information and generates a non-destructive testing sample, and the process ends.

[0040] The input information first enters the "lossless process" as indicated by the red arrow in the image. This process is handled by the Crash-Free module, the sample generation module, and the detection and judgment module, generating a lossless sample. The Crash-Free module uses dynamic analysis technology to monitor the target software system's buffer allocation and buffer filling, extracting vulnerability elements such as buffer allocation address, allocation length, filling address, and filling length. Based on the HOTracer technology, it identifies allocation and filling pairs directly related to buffer overflows and transmits this information to the sample generation module. The sample generation module receives the vulnerability element information identified by the Crash-Free module, uses symbolic execution technology to extract symbolic expressions that control the overflow length, and uses constraint solving technology to solve the expressions, ensuring the overflow length is controlled within a reasonable range that does not cause abnormal crashes, thus obtaining a lossless sample. Subsequently, the detection and judgment module receives this lossless sample and determines whether to enter the "detection process" based on the execution status of the lossless sample. Figure 1 The green arrow indicates the process. When a lossless sample executes on both the vulnerable and patched versions of the software and causes them to exhibit different observable behaviors (different output content, different data packet return content, etc.), the lossless sample already possesses detection capabilities and does not need to enter the detection process; it directly outputs the lossless detection sample and the behavioral characteristics characterizing the existence of the vulnerability. When a lossless sample executes on both the vulnerable and patched versions of the software and fails to cause them to exhibit different observable behaviors, it enters the "detection process," as shown below. Figure 2 As shown.

[0041] When the system enters the "probing process," the probing and judgment module provides the previously generated lossless samples to the patch identification module. The patch identification module's role is to locate the specific position of the vulnerability patch code within the binary program. Therefore, it first needs to record the instruction execution records of the vulnerable version software and the patched version software executing the lossless samples. Using the static analysis tool Bindiff, it locates the actual patch content executed and provides its location information to the branch exploration module. The branch exploration module's role is to explore alternative branches that might cause behavioral differences between the two software versions. After obtaining the patch location information, the branch exploration module performs a batch branch search in the instruction execution records. Using dynamic taint propagation technology, it determines whether a branch is affected by both the patch and external input information. The branch exploration module records branches that meet the conditions as alternative branches and sends them to the sample generation module. The sample generation module's role in the "probing process" differs from its role in the "lossless process." Its role is to perform dynamic symbolic execution on the software based on the received alternative branches, causing the software to deviate from its original trajectory in the corresponding branches. For branches appearing in both the vulnerability version and the patch version, the module needs to construct constraints that cause the two versions of the software to take different paths on that branch, thereby exploring the branches that contribute to behavioral differences to the greatest extent. For each candidate branch, the sample generation module generates a new sample, and the detection and judgment module determines whether each new sample has the capability for non-destructive testing. When a legitimate sample appears, the module stops judging and outputs the non-destructive testing sample and the behavioral characteristics that characterize the existence of the vulnerability.

[0042] The two processes and five modules described above constitute a non-destructive testing sample generation system. Based on the principles of "cautious overflow" (constructing samples with controllable overflow length) and "branch exploration" (changing the predetermined direction of branches), it maximizes the exploration of behavioral differences between two versions of software. Furthermore, since all explored branches are "vulnerability patch related," the occurrence of behavioral differences depends solely on the presence or absence of vulnerabilities, ensuring that vulnerability detection does not degenerate into version detection.

[0043] When using a non-destructive testing sample, users only need to run the non-destructive testing sample on the software system according to the established method of running the original crash sample, and observe the behavior of the software system. Compare this behavior with the behavioral characteristics that indicate the existence of a vulnerability. If the behavior matches the behavior of a 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 to conventional methods such as version detection and side-channel detection, the advantages of the method of this invention are as follows: First, this solution does not require users to have information on the existence of vulnerabilities in different software versions. When the software system exhibits specific behavior under the detection sample, it indicates that it has vulnerabilities. This also enables the system to better cope with scenarios such as backward porting where users directly modify the software system. Second, this method is universally applicable to various software systems and does not depend on the software source code. It solves the key problem that side-channel detection and other solutions are highly specific and rely on the professional knowledge of researchers.

[0045] Typical example:

[0046] The following uses a specific open-source network protocol stack (such as OpenSSL) as an example to illustrate the detailed implementation of this invention. OpenSSL is a widely used open-source network protocol stack, commonly used to implement the SSL / TLS protocol, and has been found to have several serious vulnerabilities in the past (such as the Heartbleed vulnerability). This invention generates lossless detection samples by comparing and analyzing vulnerable versions and patched versions of OpenSSL, accurately detecting the existence of vulnerabilities.

[0047] 1. Input Information Preparation

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

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

[0050] ●PoC (Proof of Concept): A malicious data packet that can trigger the Heartbleed vulnerability (e.g., sending a Heartbeat request in a specific format).

[0051] ● Command Log: Command execution logs when executing PoC samples on vulnerable and patched versions (obtained via dynamic instrumentation tools such as Pin or DynamoRIO).

[0052] 2. Non-destructive process

[0053] 2.1 Crash-Free Module

[0054] ●Objective: Extract vulnerability information to ensure that the generated sample does not cause system crashes.

[0055] ●Operating steps:

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

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

[0058] 2. Extract vulnerability information related to the Heartbleed vulnerability, such as buffer allocation address, allocation length, padding address, and padding length.

[0059] 3. Identify allocation and padding pairs directly related to buffer overflow and pass this information to the sample generation module.

[0060] 2.2 Sample Generation Module

[0061] ●Objective: Generate lossless samples that do not cause crashes.

[0062] ●Operating steps:

[0063] 1. Use symbolic execution tools (such as KLEE or Angr) to perform symbolic execution on the OpenSSL Heartbeat request handling function to extract symbolic expressions related to buffer overflow.

[0064] 2. Use a constraint solver (such as Z3) to solve symbolic expressions to ensure that the overflow length is kept within a reasonable range that will not cause a crash.

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

[0066] 2.3 Detection and Judgment Module

[0067] ●Objective: To determine whether a non-destructive sample has detection capabilities.

[0068] ●Operating steps:

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

[0070] Non-destructive samples were executed on 1.0.1g.

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

[0072] ■ Vulnerable Version: May return additional memory data

[0073] (Characteristics of the Heartbleed vulnerability.)

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

[0075] If the two versions have significantly different behaviors (e.g., different returned data lengths), the lossless sample is determined to have probing capabilities and is directly output as a lossless probing sample; otherwise, the probing process begins.

[0076] 3. Detection Process

[0077] 3.1 Patch Identification Module

[0078] ●Objective: Locate the specific position of the vulnerability patch code within the binary program.

[0079] ●Operating steps:

[0080] 1. Use static analysis tools (such as BinDiff) to compare vulnerability versions and patches.

[0081] This involves accessing the OpenSSL binary and locating the patch code related to the Heartbleed vulnerability.

[0082] 2. Record the location information of the patch code (such as function address and instruction offset) and pass it to the branch exploration module.

[0083] 3.2 Branch Exploration Module

[0084] ●Objective: Explore alternative branches that may cause behavioral differences between the two versions.

[0085] ●Operating steps:

[0086] 1. Execute the non-destructive sample on both the vulnerable version and the patched version, and record the instruction execution trajectory.

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

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

[0089] 3.3 Sample Generation Module

[0090] ●Objective: Generate new non-destructive testing samples based on the alternative branches.

[0091] ●Operating steps:

[0092] 1. Perform dynamic symbolic execution on each candidate branch and construct constraints that cause the vulnerability version and the patch version to take different paths on that branch.

[0093] 2. Generate new Heartbeat request samples, ensuring that the samples can trigger the behavioral differences of the alternative branches.

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

[0095] 3.4 Detection and Judgment Module

[0096] ●Objective: To determine whether a new sample has non-destructive testing capabilities.

[0097] ●Operating steps:

[0098] 1. Run the new sample on both the vulnerable version and the patched version.

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

[0100] ■ Vulnerable version: May trigger additional memory read operations.

[0101] ■ Patch version: Will not trigger additional memory read operations.

[0102] If the behavioral differences are significant, the new sample is determined to have non-destructive testing capabilities, and the output is a non-destructive testing sample; otherwise, new samples continue to be generated.

[0103] 4. Use of non-destructive testing samples

[0104] ●How to use:

[0105] 1. Send the generated non-destructive testing sample (modified Heartbeat request) to the target OpenSSL server.

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

[0107] ■ If the server returns additional memory data (e.g., a response longer than expected), it indicates that the target system has a Heartbleed vulnerability.

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

[0109] ●Advantages:

[0110] ○ Non-destructive: The probing process will not cause server crashes or data loss.

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

[0112] ○Automation: No human intervention required, suitable for large-scale vulnerability scanning.

[0113] As can be seen, through the above steps, this invention successfully achieved lossless detection of the Heartbleed vulnerability in OpenSSL. This method is not only applicable to OpenSSL, but can also be extended to other network protocol stacks and software systems, demonstrating broad applicability and high practical value.

[0114] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A vulnerability lossless detection method based on patch association behavior exploration, characterized in that, Includes the following steps: Step 1, Input Information Preparation: Receive the vulnerable version software, the patched version software, the vulnerability crash sample PoC, and the instruction records executed by the vulnerability crash sample on both versions of the software; Step 2: Perform the non-destructive 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 and constraint solving techniques to generate lossless samples, ensuring that the overflow length is controlled within a reasonable range that does not cause abnormal crashes. First detection and determination module: Determines whether the non-destructive sample has detection capability; if it does, directly outputs the non-destructive sample as the non-destructive detection sample; otherwise, proceeds to the detection process. Step 3: Execute the detection process: The patch identification module locates the specific position of the vulnerability patch code within the binary program; The branch exploration module explores alternative branches that may lead to behavioral differences between two versions of the software. The sample generation module generates new non-destructive testing samples based on the alternative branches; The second detection and determination module determines whether the new non-destructive testing sample has non-destructive testing capability. If it does, it outputs the non-destructive testing sample; otherwise, it continues to generate a new non-destructive testing sample. In step 2, the Crash-Free module uses dynamic analysis tools to monitor OpenSSL's memory allocation and padding behavior 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; In step 2, the sample generation module uses a symbolic execution tool to perform symbolic execution on the OpenSSL Heartbeat request handling function, extracting symbolic expressions related to buffer overflow; it uses a constraint solver to solve the symbolic expressions to ensure that the overflow length is controlled within a reasonable range that will not cause a crash; and it generates a modified Heartbeat request sample. This modified Heartbeat request sample is a lossless sample that can trigger the vulnerability but will not cause the system to crash.

2. The method of claim 1, wherein, In step 1, the instruction execution records when executing the PoC on the vulnerable version software and the patched version software are obtained through dynamic instrumentation tools.

3. The method of claim 1, wherein, In step 2, the first detection and judgment module executes the lossless sample on the vulnerable version software and the patched version software respectively, and compares the behavioral differences between the two versions. If the behavior of the two versions is different, the lossless sample is determined to have detection capability and is directly output as a lossless detection sample; otherwise, the detection process is entered.

4. The method of claim 3, wherein, In step 3, the patch identification module uses static analysis tools to compare the OpenSSL binaries of the vulnerable version software and the patched version software, locate the patch code related to the Heartbleed vulnerability, record the location information of the patch code, and pass it to the branch exploration module.

5. The method of claim 4, wherein, In step 3, the branch exploration module executes non-destructive samples on both the vulnerable version of the software and the patched version of the software, and records the instruction execution trajectory. It uses a dynamic taint analysis tool to analyze the instructions near the patch code, identify which branches are affected by both the patch and the externally input non-destructive samples, record these branches as candidate branches, and pass them to the sample generation module.

6. The method of claim 5, wherein, In step 3, the sample generation module performs dynamic symbolic execution on each candidate branch, constructs constraints to cause the vulnerability version and patch version to take different paths on the branch; generates a new Heartbeat request sample, which is a new non-destructive probe sample, ensuring that the new non-destructive probe sample can trigger the behavioral differences of the candidate branches; and passes the new non-destructive probe sample to the second probe judgment module.

7. The method of claim 6, wherein, In step 3, the second detection and judgment module executes new non-destructive detection samples on the vulnerable version software and the patched version software respectively, and compares the behavioral differences between the two versions. If the behavior of the two versions is different, the new non-destructive detection sample is determined to have detection capability and is directly output; otherwise, new non-destructive detection samples are generated.

Images