Fuzz Testing Method for Embedded Device Programs

Abstract

The present invention provides a fuzz testing method for embedded device programs. The method includes: preprocessing a target binary program; running the program under test to obtain monitoring information, specifically including: performing correlation analysis on the context of sensitive APIs and input samples; monitoring the call sites of sensitive APIs; monitoring the call sites of subroutines; monitoring the context of sensitive APIs; selecting corresponding samples as seeds to be mutated according to the sensitive API pool and the subroutine pool; selecting a seed mutation strategy according to whether sensitive fields are detected, and mutating the seeds to be mutated using the selected seed mutation strategy to generate new test samples, and performing a new round of fuzz testing on the program under test using the new test samples. The present invention can improve the ability and efficiency of triggering various types of vulnerabilities, increase the code coverage of business logic, and expand the types of supported vulnerability mining.

Description

Technical Field

[0001] The present invention relates to the technical field of software security, and in particular to a fuzzy testing method for embedded device programs. Background Art

[0002] Embedded devices are often composed of multiple programs or different modules in the OS kernel working together to provide multiple functions. Almost all functions in embedded devices are often exposed to the outside world through a few service programs in the form of a network. Since the service program needs to interact with other backend modules when it is executed, the core code of the service program is often composed of multiple sub-processes and has a wide variety of vulnerabilities.

[0003] However, most existing fuzz testing methods are designed for desktop system software. Affected by the unique multi-stage workflow in firmware that combines a wide variety of vulnerability types (not limited to memory corruption), the most advanced code coverage-oriented fuzz testing methods have the following shortcomings: (1) It is difficult to focus testing resources on the core business logic code, which is manifested in the low coverage of the business logic code. (2) The ability to trigger multiple types of vulnerabilities is insufficient, resulting in a single type of vulnerability that can be mined. (3) The efficiency of triggering multiple types of vulnerabilities is low, resulting in weak vulnerability triggering ability and slow speed. Summary of the invention

[0004] In order to solve at least one of the above three problems of the existing code coverage-oriented fuzz testing methods, the present invention provides a fuzz testing method for embedded devices.

[0005] The present invention provides a fuzzy testing method for embedded devices, comprising:

[0006] Step 1: Preprocess the target binary program, the preprocessing includes: obtaining sensitive API information and sub-process information, and inserting monitoring code at the sensitive API and sub-process locations; wherein the target binary program after the monitoring code is inserted is called the program under test; the sub-process refers to the code for executing a single business process;

[0007] Step 2: Run the program under test and obtain monitoring information, including:

[0008] Step 2.1: Perform correlation analysis on the sensitive API context and input samples to determine whether there are sensitive fields;

[0009] Step 2.2: Monitor the call locations of sensitive APIs. If a sensitive API is hit during this operation, check whether it is a newly hit sensitive API in the sensitive API pool. If so, add it to the sensitive API pool.

[0010] Step 2.3: Monitor the call sites of the sub - processes. If the sub - process is hit during this run, check in the sub - process pool whether it is a newly hit sub - process. If so, add it to the sub - process pool.

[0011] Step 2.4: Monitor the sensitive API context. If the sensitive API context matches any one of the preset exception rules, throw an exception.

[0012] Step 3: Select corresponding samples as the seeds to be mutated according to the sensitive API pool and the sub - process pool.

[0013] Step 4: Select a seed mutation strategy according to whether sensitive fields are detected. Use the selected seed mutation strategy to mutate the seeds to be mutated to generate new test samples, and use the new test samples to perform a new round of fuzz testing on the program under test.

[0014] Further, in Step 1, a static analysis method is used to obtain sensitive API information and sub - process information; among them, the sub - processes are identified through two identification methods, including: identifying sub - processes in the form of a function pointer table and identifying sub - processes in the form of a registered callback function.

[0015] Further, in Step 1, a static instrumentation method is used to insert monitoring code at the positions of sensitive APIs and sub - processes.

[0016] Further, Step 2.1 specifically includes: using the longest common substring algorithm to compare the sensitive API context with the input sample to determine their longest common substring; judging whether the length of the longest common substring is greater than a set threshold. If so, the position where the longest common substring is located is the sensitive field, otherwise, it is considered that there is no sensitive field.

[0017] Further, Step 2.4 specifically includes:

[0018] Configure exception rules, including: pattern string rule, special character rule, and buffer size rule;

[0019] The pattern string rule means that if the sensitive API context contains a string with given rule details, an exception is thrown;

[0020] The special character rule means that if the sensitive API context contains special characters in the given rule details, an exception is thrown;

[0021] The buffer size rule means that if the length of the source address string in the sensitive API context is greater than the destination buffer size, an exception is thrown.

[0022] Further, Step 3 specifically includes:

[0023] Retain the samples corresponding to the sensitive APIs in the sensitive API pool as seeds, and retain the samples corresponding to the sub - processes in the sub - process pool as seeds to construct a seed pool;

[0024] Assign a test weight to the sample according to the number of sensitive APIs hit by the sample; among them, the more sensitive APIs are hit, the greater the test weight;

[0025] Select a seed from the seed pool as the seed to be mutated.

[0026] Furthermore, step 4 specifically includes:

[0027] If a sensitive field is detected, adopt a driving mutation strategy, that is, only replace the sensitive field;

[0028] If no sensitive field is detected, adopt an active mutation strategy, including byte flipping and bit flipping.

[0029] Advantages of the present invention:

[0030] (1) Aiming at the problem of insufficient ability to trigger multiple types of vulnerabilities, the present invention innovatively proposes a seed mutation strategy combining driving mutation and active mutation, which can implement precise mutation after detecting sensitive APIs hit, improving the ability and efficiency to trigger multiple types of vulnerabilities.

[0031] (2) Aiming at the problem of insufficient coverage of core business logic code, the present invention innovatively proposes a seed selection strategy guided by sub - processes and sensitive APIs, which can screen out seeds that hit sub - processes and sensitive APIs and allocate additional test resources to improve the coverage rate of business logic code.

[0032] (3) Aiming at the problem of single type of exploitable vulnerabilities, the present invention innovatively proposes a heuristic vulnerability determination mechanism, which can identify multiple non - Crash - type vulnerabilities and expand the supported types of vulnerability mining. Description of the Drawings

[0033] Figure 1 It is a schematic flow chart of the workflow of the embedded device program provided by the embodiment of the present invention;

[0034] Figure 2 It is a schematic flow chart of the fuzz testing method for the embedded device program provided by the embodiment of the present invention;

[0035] Figure 3 It is two types of identification methods for identifying sub - processes provided by the embodiment of the present invention. Detailed Embodiment

[0036] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0037] By observing the embedded device program, the inventors observed that the embedded device program has the following two key features: First, the embedded device program has a multi-stage workflow and vulnerabilities often occur in the sub-process execution stage; second, multiple types of vulnerabilities on the embedded device program are closely related to sensitive APIs.

[0038] As Figure 1 shown, the workflow of the embedded device program is mainly divided into five stages: network packet reception stage, network packet deserialization stage, sub-process distribution stage, sub-process execution stage, and result return stage.

[0039] Starting from the workflow and multiple types of vulnerability characteristics of the embedded device program, the present invention regards sensitive APIs in sub-processes as attack points and proposes a vulnerability pattern-oriented fuzz testing method for embedded device programs under a multi-stage workflow. Compared with the existing fuzz testing methods, the concept of the present invention starts from the inherent attributes of the embedded device program, models the workflow of the embedded device program, introduces the concept of "sub-process" to distinguish the core business code, and pays attention to the use of sensitive APIs. Subsequently, the fuzz testing method is divided into three stages, and respective strategies are adopted for each stage, including: sub-process coverage-oriented strategy, sensitive API utilization strategy, and multi-type vulnerability heuristic determination mechanism.

[0040] Among them, the core idea of the sub-process coverage-oriented strategy is to use the sub-process information extracted in static analysis to optimize seed mutation and use an evolutionary seed selection strategy to focus on testing sub-processes. The core idea of the sensitive API utilization strategy is to use the correlation analysis between the input and context of sensitive APIs to locate sensitive fields that control the context and accurately change the sensitive fields according to multiple types of vulnerability patterns to generate proof-of-concept (POC) inputs to trigger exceptions. The core idea of the multi-type vulnerability heuristic determination mechanism is to check whether an exception has occurred in the context of sensitive APIs with predefined rules at runtime to identify vulnerabilities.

[0041] Under the above inventive concept, as Figure 2 shown, the embodiments of the present invention provide a fuzz testing method for embedded device programs, including the following steps:

[0042] S101: Preprocess the target binary program. The preprocessing includes obtaining sensitive API information and sub - process information, and inserting monitoring code at the positions of sensitive APIs and sub - processes. Among them, the target binary program after inserting the monitoring code is called the program under test. The sub - process refers to the code that executes a single business process.

[0043] Specifically, a static analysis method is used to obtain sensitive API information (as shown in Table 1) and sub - process information. The sub - process refers to the code that specifically executes a certain business process after network data packet processing. Generally, in a binary program, the sub - process exists in the form of a function. Therefore, in the embodiments of the present invention, the sub - process is identified in two forms, as Figure 3 shown, including: Type 1, identifying the sub - process in the form of a function pointer table, and Type 2, identifying the sub - process in the form of a registered callback function.

[0044] The static instrumentation method is used to insert monitoring code at the positions of sensitive APIs and sub - processes.

[0045] S102: Run the program under test. When the program under test is running, the following four aspects of monitoring are performed to obtain monitoring information, specifically including:

[0046] S1021: Perform correlation analysis on the sensitive API context and the input sample to determine whether there is a sensitive field.

[0047] Specifically, in this embodiment, the longest common substring algorithm is used to compare the sensitive API context and the input sample to determine the longest common substring between the two. It is judged whether the length of the longest common substring is greater than the set threshold. If so, the position where the longest common substring is located is the sensitive field; otherwise, it is considered that there is no sensitive field.

[0048] S1022: Monitor the call location of the sensitive API. If the sensitive API is hit during this run, check whether it is a newly hit sensitive API in the sensitive API pool. If so, add it to the sensitive API pool and make a mark.

[0049] S1023: Monitor the call location of the sub - process. If the sub - process is hit during this run, check whether it is a newly hit sub - process in the sub - process pool. If so, add it to the sub - process pool and make a mark.

[0050] S1024: Monitor the sensitive API context. If the sensitive API context matches any one of the preset exception rules, an exception is thrown.

[0051] Specifically, exception rules are pre-configured, including: pattern string rule, special character rule, and buffer size rule, as shown in Table 1. Then, the sensitive API context is matched with the rule details in each rule. If a match is found, an exception is thrown, indicating that a vulnerability is detected in the binary program. Specifically, it includes:

[0052] The pattern string rule means that if the sensitive API context contains a string with the given rule details, an exception is thrown; the special character rule means that if the sensitive API context contains a special character in the given rule details, an exception is thrown; the buffer size rule means that if the length of the source address string in the sensitive API context is greater than the destination buffer size, an exception is thrown.

[0053] S103: Select corresponding samples as seeds to be mutated according to the sensitive API pool and the subroutine pool;

[0054] Specifically, when selecting seeds to be mutated, the seed selection strategy mainly includes two principles. One is to retain samples that hit new subroutines or sensitive APIs as seeds, and the other is that the more sensitive APIs are hit, the higher its test weight. That is, this step mainly includes:

[0055] First, retain the samples corresponding to the sensitive APIs in the sensitive API pool as seeds, and retain the samples corresponding to the subroutines in the subroutine pool as seeds to construct a seed pool; then assign a test weight to the samples according to the number of sensitive APIs hit by the samples; among them, the more sensitive APIs are hit, the greater the test weight; finally, select a seed from the seed pool as the seed to be mutated.

[0056] S104: Select a seed mutation strategy according to whether sensitive fields are detected, use the selected seed mutation strategy to mutate the seed to be mutated to generate new test samples, and use the new test samples to perform a new round of fuzz testing on the program under test, that is, execute the above steps S101 to S104 again.

[0057] Specifically, in this embodiment, the seed mutation strategy mainly includes two types, namely the driven mutation strategy and the active mutation strategy. If sensitive fields are detected, the driven mutation strategy is adopted, that is, only the sensitive fields are replaced; the replacement rule can use the pre-given replacement string items to replace the sensitive fields, as shown in the "replacement string" item in Table 1. If no sensitive fields are detected, the active mutation strategy is adopted, including typical mutation means such as byte flipping and bit flipping.

[0058] Table 1 Sensitive API Information

[0059]

[0060] Aiming at the problem of insufficient ability to trigger multiple types of vulnerabilities, the present invention innovatively proposes a seed mutation strategy that combines driver mutation and active mutation, which can implement precise mutation after discovering sensitive APIs being hit, improving the ability and efficiency to trigger multiple types of vulnerabilities.

[0061] Aiming at the problem of insufficient coverage of core business logic code, the present invention innovatively proposes a seed selection strategy guided by sub - processes and sensitive APIs, which can screen out seeds that hit sub - processes and sensitive APIs and allocate additional test resources to improve the coverage rate of business logic code.

[0062] Aiming at the problem of a single type of exploitable vulnerability, the present invention innovatively proposes a heuristic vulnerability determination mechanism, which can identify multiple non - Crash - type vulnerabilities and expand the supported types of vulnerability mining.

[0063] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fuzz testing method for embedded device programs, characterized in that Including: Step 1: Preprocess the target binary program, and the preprocessing includes: obtaining sensitive API information and sub - process information, and inserting monitoring code at the positions of sensitive APIs and sub - processes; wherein, the target binary program after inserting the monitoring code is called the program under test; the sub - process refers to the code that executes a single business process. Step 2: Run the program under test to obtain monitoring information, specifically including: Step 2.1: Conduct an association analysis on the sensitive API context and the input sample to determine whether there are sensitive fields. Step 2.2: Monitor the call sites of sensitive APIs. If a sensitive API is hit during this run, check whether it is a newly hit sensitive API in the sensitive API pool. If so, add it to the sensitive API pool. Step 2.3: Monitor the call sites of sub - processes. If a sub - process is hit during this run, check whether it is a newly hit sub - process in the sub - process pool. If so, add it to the sub - process pool. Step 2.4: Monitor the sensitive API context. If the sensitive API context matches any one of the preset exception rules, an exception is thrown. Step 3: Select corresponding samples as the seeds to be mutated according to the sensitive API pool and the sub - process pool. Step 4: Select a seed mutation strategy according to whether sensitive fields are detected, use the selected seed mutation strategy to mutate the seeds to be mutated to generate new test samples, and use the new test samples to conduct a new round of fuzz testing on the program under test.

2. The fuzz testing method for embedded device programs according to claim 1, wherein In Step 1, static analysis methods are used to obtain sensitive API information and sub - process information; among them, the sub - processes are identified through two identification methods, including: identifying sub - processes in the form of a function pointer table and identifying sub - processes in the form of registered callback functions.

3. The fuzz testing method for embedded device programs according to claim 1, wherein In Step 1, static instrumentation is used to insert monitoring code at the positions of sensitive APIs and sub - processes.

4. The fuzz testing method for embedded device programs according to claim 1, wherein Step 2.1 specifically includes: using the longest common substring algorithm to compare the sensitive API context and the input sample to determine the longest common substring between the two; determining whether the length of the longest common substring is greater than a set threshold. If so, the position where the longest common substring is located is the sensitive field, otherwise, it is considered that there is no sensitive field.

5. The fuzz testing method for embedded device programs according to claim 1, wherein Step 2.4 specifically includes: Configure exception rules, including: pattern string rule, special character rule, and buffer size rule. The pattern string rule means that if the sensitive API context contains a string with given rule details, an exception is thrown. The special character rule means that if the sensitive API context contains special characters in the given rule details, an exception is thrown. The buffer size rule means that if the length of the source address string in the sensitive API context is greater than the destination buffer size, an exception is thrown.

6. The fuzz testing method for embedded device programs according to claim 1, wherein Step 3 specifically includes: Retain the samples corresponding to the sensitive APIs in the sensitive API pool as seeds, retain the samples corresponding to the sub - processes in the sub - process pool as seeds, and construct a seed pool. Assign a test weight to the samples according to the number of times the samples hit sensitive APIs; among them, the more times a sample hits a sensitive API, the greater the test weight. Select a seed from the seed pool as the seed to be mutated.

7. The fuzz testing method for embedded device programs according to claim 1, wherein Step 4 specifically includes: If a sensitive field is detected, the drive mutation strategy is adopted, that is, only the sensitive field is replaced; If no sensitive field is detected, the active mutation strategy is adopted, including byte flipping and bit flipping.

Images