Operating system device post-cleanup vulnerability detection system based on static analysis

Abstract

The application discloses a system for detecting post-cleaning use vulnerabilities of operating system devices based on static analysis, which comprises three modules of preprocessing, suspicious pair positioning and vulnerability detection. The preprocessing module models the device removal process and system call processing process in the operating system through standard interface abstraction and heuristic experience method, and hierarchically divides the codes in the system by means of the established model to obtain boundary functions of the codes in each layer. The suspicious pair positioning module positions suspicious pairs in the target layer code through mainstream static analysis and solves the code paths reaching the suspicious pairs. The vulnerability detection module detects post-cleaning use vulnerabilities of the devices from the given suspicious pairs through a routine switching point algorithm and outputs intermediate results during the algorithm operation. The application can efficiently and accurately detect post-cleaning use vulnerabilities of the devices in the operating system and enhance the robustness of the target system to the vulnerabilities.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of information security, and particularly relates to a use-after-cleanup (UAC) detection system based on static analysis. BACKGROUND

[0002] Recently, the operating system level vulnerability mining technology gradually matures, and specific vulnerability types, such as memory vulnerability (overflow, null pointer dereference, memory leak, etc.) can be efficiently and accurately detected. However, a specific type of concurrent vulnerability in the operating system, use-after-cleanup (UAC) lacks effective detection means.

[0003] Through investigation, the main reasons for the lack of related detection systems are as follows:

[0004] 1. The inherent complexity of the vulnerability: Device use-after-free (CUAF) vulnerabilities are essentially a special case of concurrent use-after-free (CUAF) vulnerabilities in the operating system's device cleanup process. The release operation originates from the normal resource reclamation of the cleanup routine; however, due to concurrency, while the device is being removed, the system call routine, due to improper synchronization implementation, fails to recognize the concurrent cleanup action and thus abnormally accesses already released resources. Research indicates that current operating system vulnerability discovery techniques have limited exploration of concurrency issues, primarily focusing on detecting data race problems. The few cutting-edge technologies capable of detecting CUAF vulnerabilities all have their limitations: UFO (Huang, Jeff. "UFO: predictive concurrency use-after-free detection." Proceedings of the 40th International Conference on Software Engineering. 2018.) predicts potential vulnerability trajectories based on existing execution paths. Because this method is too costly to apply to large targets at the operating system level, DCUAF (Bai, Jia-Ju, et al. "Effective Static Analysis of Concurrency Use-After-Free Bugs in Linux Device Drivers." USENIX Annual Technical Conference. 2019.) detects concurrent use-after-free vulnerabilities in operating system drivers by extending the detection of data races. Although it is more efficient, it has been shown to produce unnecessary false positives and false negatives (kernel commit 3f60f468569 "cw1200: Revert unnecessary patches that fix unreal use-after-free bugs"). Furthermore, this tool only focuses on device driver code, neglecting other parts of the system, making it insufficient to effectively detect device cleanup-after-free vulnerabilities.

[0005] 2. Misconceptions about the vulnerability threat: Research and discussions with kernel developers reveal that the community does not give sufficient attention to this type of vulnerability. First, compared to direct memory corruption, the triggering and exploitation of device sanitization-use vulnerabilities, as concurrent vulnerabilities, are uncertain. Second, resource release during the triggering process of this type of vulnerability is handled by the device sanitization routine; therefore, the community generally believes that only expensive programmable hardware devices can trigger this type of vulnerability. However, contrary to this, evidence shows that attackers can not only overcome the requirement of a real device for device removal by implementing virtual devices through pseudo-terminals, but also completely circumvent the uncertainty of triggering concurrent vulnerabilities using existing userfaultfd technology, triggering and exploiting device sanitization-use vulnerabilities with a high probability or even with complete certainty. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a vulnerability detection system for operating system devices after cleanup based on static analysis.

[0007] The objective of this invention is achieved through the following technical solution:

[0008] A vulnerability detection system for operating system devices after cleanup based on static analysis, the system includes a preprocessing module, a suspicious pair location module, and a vulnerability detection module;

[0009] The preprocessing module, through standard interface abstraction and heuristic empirical methods, models the device removal process and system call processing in the operating system, and uses the established model to layer the code in the system, thereby obtaining the boundary functions of each layer of code, specifically:

[0010] (1) By abstracting and analyzing the standard interface for device removal, the set of cleanup entry functions for the driver layer code is obtained; at the same time, the set of cleanup entry functions for the upper layer code is obtained through heuristic empirical analysis.

[0011] (2) Perform cross-reference analysis using the obtained cleanup entry function to build the dependency relationships between each layer;

[0012] (3) The system call entry functions of each layer are obtained by bottom-up heuristic empirical analysis;

[0013] The cleanup entry function and the system call carrying entry function together form the boundary function of a layer;

[0014] The suspected match localization module performs static analysis based on the dependencies and boundary functions between layers provided by the preprocessing module, specifically as follows:

[0015] By path exploration on the boundary function of the target layer, a function call graph and a control flow graph are constructed; by the function call graph and the control flow graph constructed, a context-sensitive and path-sensitive inter-process analysis is performed from a clean-up entry function, and then a resource release position in the analyzed hierarchical code is accurately located; then, the module finds a resource usage position related to the located resource release position through a points-to analysis, and forms a suspicious pair data structure with the located resource release position related resource usage position; by the function call graph and the control flow graph constructed, a code path reaching the suspicious pair from the boundary function is solved out;

[0016] The vulnerability detection module takes the suspicious pair and the related code path as input, executes a routine switch point algorithm to perform vulnerability detection; the module outputs a detected device clean-up-after-use vulnerability, and also outputs an intermediate result of the vulnerability detection algorithm running time, which is used to guide a user to find a threatening and exploitable device clean-up-after-use vulnerability.

[0017] Further, by standard interface abstraction analysis of device removal, a set of clean-up entry functions of the driver layer code is obtained, specifically:

[0018] The preprocessing module performs semi-automatic analysis based on the interface, and obtains the clean-up entry function of the layer by marking a structure pointer described by the interface.

[0019] Further, the vulnerability detection module executes a routine switch point algorithm to perform vulnerability detection, specifically:

[0020] The routine switch point algorithm is based on the suspicious pair and the related code path, and solves out a lock set corresponding to the suspicious pair; based on the lock set, the routine switch point algorithm further collects constraint changes and checks experienced from the boundary function to the suspicious pair position; and based on the solved lock state and the collected constraint changes and checks, a possible routine switch point is solved out, so as to detect whether the suspicious pair causes a device clean-up-after-use vulnerability.

[0021] Further, the intermediate result of the vulnerability detection algorithm running time is a routine switch time window, a routine time slice and a controllable delay function.

[0022] The beneficial effects of the present application are as follows:

[0023] The operating system device clean-up-after-use vulnerability detection system based on static analysis proposed in the present application realizes a larger range and more specific detection by combining standard interface abstraction and heuristic experience methods, specifically:

[0024] The existing work UFO that discovers and finds concurrent post-release usage vulnerabilities in user-mode programs cannot be used to find device cleanup post-release usage vulnerabilities in operating systems due to too many false positives when analyzing such large targets. The present application overcomes this difficulty by focusing on device cleanup post-release usage vulnerabilities instead of concurrent post-release usage vulnerabilities, and successfully implements detection.

[0025] The existing work DCUAF that can also be used to find device cleanup post-release usage vulnerabilities in operating systems ignores vulnerabilities in upper layers because it only focuses on the device driver layer that has a uniform standard interface abstraction. The present application makes the upper layer also an input for vulnerability detection by combining heuristic experience methods, so it can cover more target code. On this basis, the routine switching point algorithm proposed by the present application is also superior to the lock set conflict algorithm used by the existing work. Specifically, the algorithm not only considers the lock set relationship between suspicious pairs, but also completes more accurate vulnerability detection by collecting and solving the constraint state of the code path. The intermediate results generated by the algorithm are also output to help users find more exploitable and more threatening vulnerabilities from vulnerabilities.

[0026] The present application completes efficient detection of this specific vulnerability type in the entire operating system through three sub-modules, effectively protects the target operating system from being affected by this type of vulnerability, and enhances the robustness of the target system to this type of vulnerability. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 is a system prototype of the present application.

[0028] Figure 2 is a comparison chart of the detection vulnerability results of the present application and the most advanced existing tool. DETAILED DESCRIPTION

[0029] The present application will become more apparent from the following detailed description of preferred embodiments with reference to the attached drawings, and the purposes and effects of the present application will become more apparent. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application.

[0030] The static analysis-based operating system device cleanup post-release usage vulnerability detection system of the present application, as shown in Figure 1 , includes a preprocessing module, a suspicious pair positioning module, and a vulnerability detection module.

[0031] (I) Preprocessing module

[0032] The preprocessing module models the device removal process and system call processing process in the operating system, and layers the code in the system by means of the established model, so as to obtain the boundary functions of each layer code, wherein:

[0033] Modeling and layering divide the whole code of operating system into independent code layers; each layer provides clean-up entry function downward and system call carrying entry function upward;

[0034] The process of device removal and system call in operating system is completed by device driver layer and upper layer; the code of device driver layer conforms to the standard interface abstraction of device removal, and the upper layer has no uniform interface abstraction.

[0035] The specific steps of pre-processing module to realize modeling and layering are as follows:

[0036] Step one: through the analysis of standard interface abstraction of device removal, the set of clean-up entry functions of device driver layer is extracted by CodeQL engine; at the same time, through the analysis of heuristic experience method, the set of clean-up entry functions of upper layer code is extracted by CodeQL engine.

[0037] Step two: through the set of clean-up entry functions obtained, cross-reference analysis is carried out by CodeQL engine, and the dependency relationship between layers is constructed by calling relationship.

[0038] Step three: from bottom to top, the system call carrying entry functions of each layer are extracted by heuristic experience method and CodeQL engine; and the screening of system call carrying entry functions is completed by the dependency relationship obtained.

[0039] The pre-processing module analyzes the clean-up entry functions of device driver layer according to the hot plug standard interface abstraction of Linux operating system kernel since version 2.4; the interface abstraction stipulates that the device driver supporting hot plug will store handle functions for processing device removal by providing dedicated function pointers when inheriting the key structure device_driver. Therefore, by automatically searching the structure body inheriting device_driver and semi-automatically marking the corresponding function pointer field, the set of clean-up entry functions of driver layer code can be obtained.

[0040] The pre-processing module obtains the clean-up entry functions of upper layer code through heuristic experience method; the heuristic experience method is in accordance with the following characteristics:

[0041] Type characteristics: the upper layer clean-up entry function is often a void function;

[0042] Parameter characteristics: the parameter of upper layer clean-up entry function is often an independent pointer;

[0043] Naming characteristics: the naming of upper layer clean-up entry function often contains the keyword unregister;

[0044] The preprocessing module obtains the system call carrying entry functions of each layer by a heuristic empirical method according to the following characteristics:

[0045] Packaging feature: The system call carrying entry functions of each layer are often stored in static global structures or dynamic heap structures through function pointers;

[0046] Reference feature: The system call carrying entry functions of each layer must be referenced by the upper layer.

[0047] (ii) Suspicious pair positioning module

[0048] The suspicious pair positioning module performs static analysis based on the dependency relationship and boundary functions between layers provided by the preprocessing module.

[0049] Specifically:

[0050] Step one: Perform hierarchical library construction for the target layer through the CodeQL engine.

[0051] Step two: Perform path exploration from the boundary function of the target layer through the CodeQL engine to construct a function call graph and a control flow graph; through the constructed function call graph and control flow graph, perform context-sensitive, path-sensitive inter-process analysis from the cleanup entry function, and then accurately locate the resource release position in the analyzed hierarchical code;

[0052] Step three: Find the resource usage position related to the located resource release position through pointer analysis, and construct a suspicious pair data structure for the located resource release position related resource usage position.

[0053] Step four: Solve the code path from the boundary function to the suspicious pair through the constructed function call graph and control flow graph; and discard the unreachable suspicious pair to improve accuracy.

[0054] The vulnerability detection module takes the suspicious pair and the related code path as input, executes the routine switching point algorithm implemented by python for vulnerability detection; the module outputs the detected device cleanup after use vulnerabilities, and also outputs the intermediate results of the vulnerability detection algorithm running time, which is used to guide the user to find threatening and exploitable device cleanup after use vulnerabilities.

[0055] The suspicious pair positioning module parses the Kconfig and Makefile followed during kernel construction to organize and establish commands when constructing the hierarchical library, to ensure the correctness of the output hierarchical library. The single-layer database has the advantages of faster speed and higher analysis accuracy compared to the full-system granularity.

[0056] The suspicious pair positioning module provides the following filters when locating suspicious pairs and generating and screening effective access paths:

[0057] 1. Point-to-analysis threshold filter, the suspicious pair positioning module will discard the point-to-analysis result with too high threshold to ensure the correctness of the positioning resource usage location;

[0058] 2. Same function filter, it has been proved that the release and usage in the same function often cannot be concurrent, and the release behavior often plays the effect of error handling, so the suspicious pair positioning module will discard the suspicious pair in the same function to ensure the correctness of the generated path.

[0059] 3. Same predecessor filter, referring to the existing work, the suspicious pair positioning module will discard the release path and the usage path with overlapping access path predecessors to ensure the correctness of the generated path.

[0060] (Three) Vulnerability detection module

[0061] The vulnerability detection module takes the suspicious pair and the related code path as input, executes the routine switching point algorithm to perform vulnerability detection; the module outputs the detected device post-cleaning usage vulnerability, and also outputs the intermediate result of the vulnerability detection algorithm running time, which is used to guide the user to find the threat and exploitable device post-cleaning usage vulnerability.

[0062] The routine switching point algorithm refers to the implementation of DCUAF when solving the lock set, mainly considering three types of synchronization primitives commonly used in the operating system, namely mutex lock, spinlock lock and read-write lock.

[0063] The routine switching point algorithm is based on the real vulnerability audit experience of the present application, and collects bit and pointer constraints changes and checks on the basis of the synchronization primitives mainly concerned in the lock set analysis, to more accurately detect vulnerabilities. The algorithm logic is shown in the following code:

[0064]

[0065] The algorithm takes the release path and the usage path as input, and outputs the possible routine switch points. As shown in line 4-9 in the above code, the algorithm first collects the checks of constraints by performing in reverse on the usage path from the usage location, until the current lock set (CHoldLock) of the execution location and the historical lock set (HHoldLock) of the release location intersect with each other, and stop at this time, and mark the stopped running location as switch point A; then, the algorithm performs in forward on the release path, collects the changes of constraints in a loop, and stops until the current lock set of the execution location and the current lock set of the usage location intersect with each other, and mark the stopped running location as switch point B; finally, the algorithm determines whether the switch points A and B are valid by solving the constraints. If they are valid, an execution interleaving sequence that can trigger a usage-after-free vulnerability is: the system runs on the usage path to the switch point A, then switches to the release path and runs to the switch point B, switches back to the release path after completing the release operation, and then runs to the usage location to trigger the vulnerability.

[0066] The following shows the results output by the present application when verifying on a real operating system.

[0067] As shown in the following table, the present application verifies the vulnerability detection capability of the present application by checking the vulnerabilities in a real operating system: Linux 5.11 (released in February 2021, version number 7289e26f395b). Among them, the preprocessing module finds 88 device driver types by analyzing the standard interface abstraction, finds 1678 device driver layer cleanup entry functions by marking the function pointers of this type, and finds 178 upper layer cleanup entry functions by heuristic experience method. Then, the heuristic experience method is used to find 1856 layer codes that have system call carrying entry functions. The suspicious pair positioning module positions 136,628 suspicious pairs, and after filtering, outputs 51,270 valid pairs. The vulnerability detection module detects 436 usage-after-free vulnerabilities in the given suspicious pairs, of which 346 are determined to be real vulnerabilities by manual determination, with an accuracy of 79.4%.

[0068] Table 1: Data of vulnerability checking of the present application applied to the operating system Linux 5.11

[0069]

[0070] Among the 346 real device usage-after-free vulnerabilities, 277 have completed reporting, confirmation, and repair work. In particular, the present application has obtained 15 CVE numbers; the intermediate results output by the vulnerability detection module have successfully guided users to identify 13 exploitable threat vulnerabilities,

[0071] Furthermore, a comparison of the outputs of this invention with the state-of-the-art tool DCUAF at several stages is presented.

[0072] like Figure 2 As shown, since DCUAF only supports the device driver layer and not the upper layer, we shared the preprocessing module results of this invention with the two tools during the comparison, and specifically compared the output results of other modules, including the number of effectively located suspicious pairs, the number of detected vulnerabilities, and the number of real vulnerabilities in the detection results. It can be found that the number of suspicious pairs discovered by this invention (51,270) far exceeds the number discovered by existing tools (16,832). Based on this, this invention detected a total of 436 cleaned-up vulnerabilities, of which 346 were real vulnerabilities, achieving an accuracy rate of 79.4%. In contrast, DCUAF detected a total of 9,820 cleaned-up vulnerabilities, of which only 130 were real vulnerabilities, achieving an accuracy rate of only 0.01%. This demonstrates that this invention is superior to existing tools in terms of detection accuracy.

[0073] It will be understood by those skilled in the art that the above descriptions are merely preferred examples of the invention and are not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A static analysis based operating system post-cleaning exploit detection system, comprising: The system comprises a preprocessing module, a suspicious pair positioning module, and a vulnerability detection module; The preprocessing module models the device removal process and system call processing process in the operating system through standard interface abstraction and heuristic experience methods, and divides the code in the system into layers by means of the established model, so as to obtain the boundary functions of the codes in each layer, specifically: (1) the cleaning entry function set of the driver layer code is obtained through standard interface abstraction analysis of device removal, and the cleaning entry function set of the upper layer code is obtained through heuristic experience method analysis; (2) the dependency relationship between layers is constructed through cross-reference analysis of the obtained cleaning entry functions; (3) the system call carrying entry functions of each layer are obtained through heuristic experience method analysis from bottom to top; The cleaning entry functions and the system call carrying entry functions constitute the boundary functions of a layer; The suspicious pair positioning module performs static analysis based on the dependency relationship and the boundary functions between layers provided by the preprocessing module, specifically: The function call graph and the control flow graph are constructed by path exploration of the boundary functions of the target layer; the context-sensitive and path-sensitive inter-process analysis is performed from the cleaning entry function by means of the constructed function call graph and the control flow graph, so as to accurately locate the resource release position in the analyzed layer code; then, the resource usage position related to the located resource release position is found by means of the pointing analysis, and the resource usage position related to the located resource release position is constructed into a suspicious pair data structure; the code path reaching the suspicious pair from the boundary function is solved by means of the constructed function call graph and the control flow graph; The vulnerability detection module takes the suspicious pair and the related code path as input, and performs a routine switching point algorithm to detect vulnerabilities; the module outputs the detected device cleaning after use vulnerabilities, and also outputs the intermediate results during the running of the vulnerability detection algorithm, which are used to guide the user to find the threatening and exploitable device cleaning after use vulnerabilities.

2. The static analysis based operating system device post-use vulnerability detection system of claim 1, wherein, The cleaning entry function set of the driver layer code is obtained through standard interface abstraction analysis of device removal, specifically: The preprocessing module performs semi-automatic analysis based on the interface, and obtains the cleaning entry function of the layer by marking the structure pointer described by the interface.

3. The static analysis based operating system device post-use vulnerability detection system of claim 1, wherein, The vulnerability detection module performs a routine switching point algorithm to detect vulnerabilities, specifically: The routine switching point algorithm solves the lock set corresponding to the suspicious pair based on the suspicious pair and the related code path; the routine switching point algorithm further collects the constraint changes and checks experienced from the boundary function to the position of the suspicious pair based on the lock set; and based on the solved lock state and the collected constraint changes and checks, the possible routine switching points are solved, so as to detect whether the suspicious pair causes device cleaning after use vulnerabilities.

4. The static analysis based operating system device post-use vulnerability detection system of claim 1, wherein, The intermediate results during the running of the vulnerability detection algorithm are the routine switching time window, the routine time slice, and the controllable delay function.

Images