Static detection method and device for service condition competition vulnerability during operation of UEFI (Unified Extensible Firmware Interface) firmware

Abstract

The invention provides a UEFI (Unified Extensible Firmware Interface) firmware runtime service condition competition vulnerability static detection method and device, and the method comprises the steps: recognizing rule data based on condition competition vulnerability features, and recognizing and generating a taint source set, a taint convergent point set and an input check point set from runtime service drive data of UEFI firmware; performing static taint analysis on the runtime service driving data according to the interprocess control flow diagram of the runtime service driving data to generate a target path between a taint source and a taint convergent point; and judging whether the condition competition vulnerability exists in the runtime service of the UEFI firmware according to the target path in a mode of a pattern matching result. According to the method and the device, the condition competition vulnerability detection for the runtime service of the UEFI firmware can be realized, and the effectiveness and the reliability of vulnerability static detection can be effectively improved, so that the security and the stability of executing the runtime service by the UEFI firmware can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of firmware vulnerability detection, and in particular to a method and device for statically detecting runtime service condition race vulnerabilities in UEFI firmware. Background Art

[0002] Billions of personal computers and cloud servers worldwide currently use firmware implemented using the Unified Extensible Firmware Interface (UEFI) standard. These devices are ubiquitous across the entire computer network ecosystem. However, amidst the increasingly intense international cybersecurity landscape, protection mechanisms at the upper-layer operating system and software levels have become a hot topic for security researchers, while protection measures at the lower-layer UEFI firmware level are often overlooked. Specifically, UEFI firmware provides two types of services: boot services and runtime services. After the system is powered on, the boot services are the first to execute. These services are responsible for initializing the underlying hardware, loading runtime service drivers, and verifying the firmware integrity during the power-on phase. During system operation, the runtime services executed by the UEFI firmware isolate the upper-layer operating system from the underlying hardware and provide the upper-layer operating system with access to the underlying hardware.

[0003] However, there are race conditions in the runtime services provided by UEFI firmware. Attackers can exploit these race conditions in the runtime services to access and control the underlying hardware and break through the security protection mechanisms of the upper-layer operating system. Currently, there is no effective static analysis method for race conditions in the runtime services of UEFI firmware. Therefore, it is urgent to carry out high-quality automated race condition vulnerability detection for the runtime services of UEFI firmware. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a method and device for statically detecting runtime service condition race vulnerabilities in UEFI firmware to eliminate or improve one or more defects in the prior art.

[0005] One aspect of the present application provides a static detection method for a runtime service race vulnerability in UEFI firmware, including:

[0006] Based on preset conditional race vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, a corresponding taint source set, a taint sink point set, and an input checkpoint set are identified and generated from the runtime service driver data of the UEFI firmware;

[0007] Based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired inter-procedural control flow graph of the runtime service driver data, static taint analysis is performed on the runtime service driver data to generate a target path between the taint source and the taint sink point; and based on the target path in the form of pattern matching results, it is determined whether a conditional race vulnerability currently exists in the runtime service of the UEFI firmware.

[0008] In some embodiments of the present application, the conditional race vulnerability feature identification rule data corresponding to the preset UEFI firmware runtime service is used to identify and generate a corresponding taint source set, a taint sink point set, and an input checkpoint set from the UEFI firmware runtime service driver data, including:

[0009] Receive race condition vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, wherein the race condition vulnerability feature identification rule data includes: external input interface identification rules, race condition vulnerability security sensitive instruction identification rules, and external input security checkpoint identification rules;

[0010] Identify, according to the external input interface identification rule, an external input interface corresponding to the runtime service of the UEFI firmware, and use the identified external input interface as a taint source to form a corresponding taint source set;

[0011] Based on the conditional race vulnerability security-sensitive instruction identification rule, identifying the conditional race vulnerability security-sensitive instruction corresponding to the runtime service of the UEFI firmware, and using the identified conditional race vulnerability security-sensitive instruction as a taint convergence point to form a corresponding taint convergence point set;

[0012] Furthermore, according to the external input security checkpoint identification rule, the external input security checkpoint corresponding to the runtime service of the UEFI firmware is identified, and the instructions and functions for security verification of the identified external input are used as input checkpoints to form a corresponding input checkpoint set.

[0013] In some embodiments of the present application, the step of performing static taint analysis on the runtime service driver data to generate a target path between the taint source and the taint sink point based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired inter-procedural control flow graph of the runtime service driver data; and determining whether the runtime service of the UEFI firmware currently has a conditional race vulnerability based on the target path in a pattern matching manner includes:

[0014] For each taint source in the taint source set, searching for instructions that introduce the taint source in the inter-procedural control flow graph;

[0015] Taking each instruction that introduces the taint source as a starting point, traverse all paths in the interprocedural control flow graph, and perform a preset path recording step for each instruction in each node in each path; wherein the path recording step includes: if the current instruction is any taint sink point in the taint sink point set and the operand of the instruction is tainted, taking the taint source in the path where the instruction is located as a starting point, recording the target path from the taint source to the taint sink point;

[0016] Starting from the taint convergence point in the target path, traversing all instructions in the target path backward to identify an external structure member used to assign a value to the operand;

[0017] According to each input checkpoint in the input checkpoint set, determining whether there is an input checkpoint for the external structure member between the taint source and the statement for assigning a value to the operand, and if so, determining whether there is a read operation for the external structure member between the taint source and the input checkpoint for the external structure member;

[0018] If there is a read operation on the external structure member between the taint source and the input checkpoint for the external structure member, the target path is added to a conditional competition vulnerability set currently corresponding to the runtime service of the UEFI firmware.

[0019] In some embodiments of the present application, further comprising:

[0020] Traverse each instruction under each of the target paths, and obtain the symbolic expression of the quadruple corresponding to each operand in each instruction, so as to identify the input format and / or alias corresponding to each instruction under each of the target paths based on the symbolic expression of the quadruple.

[0021] In some embodiments of the present application, before performing static taint analysis on the runtime service driver data to generate a target path between a taint source and a taint sink point based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired interprocedural control flow graph of the runtime service driver data, the method further includes:

[0022] Generate an intra-process control flow graph corresponding to each runtime service driver data corresponding to the UEFI firmware;

[0023] Traversing all nodes in each of the intra-procedural control flow graphs, and performing a preset function call instruction analysis step on each function call instruction in each of the nodes, so as to update each of the intra-procedural control flow graphs, and thereby generate a corresponding inter-procedural control flow graph;

[0024] The function call instruction analysis step includes:

[0025] For a target function address in a function call instruction of direct call type, the corresponding called function is added as a new node into the control flow graph within the process;

[0026] For the target function address in the function call instruction of indirect call type, the calling code position corresponding to the function call instruction is obtained based on the backward slicing method, and the corresponding called function is taken as a new node based on the calling code position and added to the control flow graph within the process.

[0027] In some embodiments of the present application, the external input interface identification rule includes: the type of the external input interface and the identification method corresponding to each type of the external input interface;

[0028] The types of the external input interface include: a communication buffer pointer corresponding to the runtime service of the UEFI firmware, a memory space for storing a CPU status register corresponding to the runtime service of the UEFI firmware, a hard-coded address, and a UEFINVRAM variable.

[0029] In some embodiments of the present application, the conditional race vulnerability security sensitive instruction identification rule includes: the type of the conditional race vulnerability security sensitive instruction and the identification method corresponding to each type of the conditional race vulnerability security sensitive instruction;

[0030] Among them, the security-sensitive instructions of the conditional competition vulnerability include: indirect memory access instructions, indirect control transfer instructions, setting variable interfaces and memory-sensitive functions.

[0031] In some embodiments of the present application, the external input security checkpoint identification rule includes: the type of the external input security checkpoint and the identification method corresponding to each type of the external input security checkpoint;

[0032] The externally input security checkpoints include: instructions and functions for performing security checks input from outside the UEFI firmware.

[0033] Another aspect of the present application provides a static detection device for a runtime service condition race vulnerability of UEFI firmware, comprising:

[0034] A taint feature recognition module is used to identify and generate a corresponding taint source set, a taint sink point set, and an input checkpoint set from the UEFI firmware runtime service driver data based on preset conditional race vulnerability feature recognition rule data corresponding to the UEFI firmware runtime service;

[0035] A static taint analysis module is configured to perform static taint analysis on the runtime service driver data based on the taint source set, the taint sink point set, the input checkpoint set, and a pre-acquired inter-procedural control flow graph of the runtime service driver data to generate a target path between the taint source and the taint sink point; and determine whether a conditional race vulnerability currently exists in the runtime service of the UEFI firmware based on the target path in a manner of pattern matching results.

[0036] The third aspect of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the static detection method for runtime service condition competition vulnerability of UEFI firmware when executing the computer program.

[0037] A fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the static detection method for runtime service condition competition vulnerabilities of UEFI firmware.

[0038] A fifth aspect of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the static detection method for runtime service condition competition vulnerabilities of UEFI firmware.

[0039] The present application provides a static detection method for a conditional race vulnerability in a UEFI firmware runtime service. Based on preset conditional race vulnerability feature identification rule data corresponding to the UEFI firmware runtime service, the method identifies and generates a corresponding taint source set, a taint sink point set, and an input checkpoint set from the UEFI firmware runtime service driver data; based on the taint source set, the taint sink point set, the input checkpoint set, and a pre-acquired inter-procedural control flow graph of the runtime service driver data, the method performs static taint analysis on the runtime service driver data to generate a target path between the taint source and the taint sink point; and determines whether the UEFI firmware runtime service currently has a conditional race vulnerability based on the target path in the form of a pattern matching result. This method can implement conditional race vulnerability detection for the UEFI firmware runtime service, effectively improve the effectiveness and reliability of static vulnerability detection, and thereby improve the security and stability of the UEFI firmware executing runtime services.

[0040] Additional advantages, purposes, and features of the present application will be described in part in the following description and will become apparent to those skilled in the art upon study of the following or may be learned from practice of the present application. The purposes and other advantages of the present application may be achieved and obtained by the structures specifically pointed out in the specification and drawings.

[0041] Those skilled in the art will understand that the purposes and advantages that can be achieved by the present application are not limited to the above specific description, and the above and other purposes that can be achieved by the present application will be more clearly understood based on the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The drawings described herein are intended to provide a further understanding of the present application, constitute a part of the present application, and do not constitute a limitation of the present application. The components in the drawings are not drawn to scale, but are only for the purpose of illustrating the principles of the present application. In order to facilitate the illustration and description of some parts of the present application, the corresponding parts in the drawings may be enlarged, that is, they may become larger than other components in the exemplary device actually manufactured according to the present application. In the drawings:

[0043] Figure 1 This is a first flow chart of a static detection method for a runtime service race vulnerability in UEFI firmware in one embodiment of the present application.

[0044] Figure 2 This is a second flow chart of a static detection method for a runtime service race vulnerability in UEFI firmware in one embodiment of the present application.

[0045] Figure 3 2 is a flow chart of the path recording step in one embodiment of the present application.

[0046] Figure 4 2 is a flow chart of the function call instruction analysis steps in one embodiment of the present application.

[0047] Figure 5 This is a schematic diagram of the execution logic of a static detection method for a runtime service condition race vulnerability in UEFI firmware in a video in an application example of this application.

[0048] Figure 6 Schematic diagram of the structure of a static detection device for a runtime service condition race vulnerability in UEFI firmware in one embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail in conjunction with the embodiments and drawings. Here, the illustrative embodiments of this application and their descriptions are used to explain this application, but are not intended to limit this application.

[0050] It should also be noted here that in order to avoid obscuring the present application due to unnecessary details, the accompanying drawings only show structures and / or processing steps that are closely related to the scheme according to the present application, while other details that are not closely related to the present application are omitted.

[0051] It should be emphasized that the term "include / comprises" when used herein refers to the existence of features, elements, steps or components, but does not exclude the existence or addition of one or more other features, elements, steps or components.

[0052] It should also be noted that, unless otherwise specified, the term "connection" herein may refer not only to a direct connection but also to an indirect connection involving an intermediate.

[0053] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0054] In order to realize the conditional race vulnerability detection for the runtime service of UEFI firmware, the embodiments of the present application respectively provide a static detection method for conditional race vulnerability of runtime service of UEFI firmware, a static detection device for conditional race vulnerability of runtime service of UEFI firmware for executing the static detection method for conditional race vulnerability of runtime service of UEFI firmware, a computer device, a computer-readable storage medium and a computer program product, which can restore different input types and dependencies between structures of different UEFI firmware runtime services; and can effectively detect conditional race vulnerabilities existing in the runtime service of UEFI firmware.

[0055] The details are described in detail through the following examples.

[0056] Based on this, the embodiment of the present application provides a UEFI firmware runtime service condition competition vulnerability static detection method that can be implemented by the UEFI firmware runtime service condition competition vulnerability static detection device, see Figure 1 The static detection method for the runtime service condition race vulnerability of the UEFI firmware specifically includes the following contents:

[0057] Step 100: Based on preset conditional race vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, a corresponding taint source set, a taint sink point set, and an input checkpoint set are identified and generated from the runtime service driver data of the UEFI firmware.

[0058] It is understandable that the core idea of ​​vulnerability discovery technology based on static taint analysis is to track the propagation path of the program's external input interface (i.e., the taint source) during program execution, and to determine whether the program's external input propagates to security-sensitive instructions (i.e., the taint convergence point) that may cause security vulnerabilities without any input verification. However, although static taint analysis can be used to detect vulnerabilities hidden in firmware in specific fields, vulnerability detection through static taint analysis requires taint modeling of the target program under test, that is, it is necessary to identify the taint source, taint convergence point, and input verification point. However, there is currently a lack of systematic analysis of UEFI firmware runtime service conditional race vulnerabilities, and different UEFI firmware runtime services have different complex input types. At the same time, UEFI firmware runtime services have complex dependencies between structures. Therefore, static taint analysis cannot be directly used to detect vulnerabilities in UEFI firmware runtime services.

[0059] Based on this, step 100 of the present application first determines the taint source, taint convergence point and input check point by adopting the preset conditional competition vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, thereby effectively improving the effectiveness and reliability of static taint analysis in the conditional competition vulnerability detection scenario corresponding to the runtime service of the UEFI firmware.

[0060] It is understandable that the race vulnerability feature identification rule data may also be abbreviated as a race vulnerability feature. In one example, the race vulnerability feature identification rule data may be manually pre-defined. The core root cause of the UEFI firmware runtime service program race vulnerability is:

[0061] (1) The UEFI firmware runtime service running on the high-privilege CPU copies external input twice from the same memory space controlled by the low-privilege server;

[0062] (2) When the UEFI firmware runtime service copies external input from the low-privilege controllable memory space, the first copy will perform input verification, and the second copy will use the obtained external input;

[0063] (3) The external input of the second copy propagates to security-sensitive instructions that can affect the execution state of the UEFI firmware runtime service.

[0064] For UEFI firmware runtime service code that meets the above conditions, an attacker with lower permissions than the UEFI firmware runtime service can tamper with the external input data required by the UEFI firmware runtime service within the time window between the input verification for the first copy and the second copy. Since the attacker tampered with the input data after the input verification, the external input copied by the UEFI firmware runtime service for the second time is the malicious input constructed by the attacker. If these external inputs propagate to security-sensitive instructions that can affect the execution state of the UEFI firmware runtime service, a security vulnerability will be triggered. Therefore, it is necessary to implement the static detection method for the UEFI firmware runtime service conditional race vulnerability provided by the embodiment of the present application.

[0065] Step 200: Based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired inter-procedural control flow graph of the runtime service driver data, static taint analysis is performed on the runtime service driver data to generate a target path between the taint source and the taint sink point; and based on the pattern matching result, it is determined according to the target path whether there is a conditional race vulnerability in the runtime service of the UEFI firmware.

[0066] In step 200, taint analysis is performed based on the taint source, taint sink, input checkpoints, and the generated inter-procedural control flow graph to generate a path between the taint source and the taint sink that triggers the vulnerability. Finally, pattern matching is used to determine whether the path between the taint source and the taint sink satisfies the characteristics of a UEFI firmware runtime service race vulnerability.

[0067] From the above description, it can be seen that the static detection method for conditional race vulnerabilities in the runtime services of UEFI firmware provided in the embodiment of the present application can realize conditional race vulnerability detection for the runtime services of UEFI firmware, and can effectively improve the effectiveness and reliability of static vulnerability detection, thereby improving the security and stability of UEFI firmware executing runtime services.

[0068] In order to further improve the reliability and comprehensiveness of the feature identification of the conditional competition vulnerability of the runtime service of the UEFI firmware, in a static detection method of the conditional competition vulnerability of the runtime service of the UEFI firmware provided in an embodiment of the present application, see Figure 2 Step 100 of the static detection method for the runtime service condition race vulnerability of the UEFI firmware specifically includes the following contents:

[0069] Step 110: Receive race condition vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, wherein the race condition vulnerability feature identification rule data includes: external input interface identification rules, race condition vulnerability security sensitive instruction identification rules and external input security checkpoint identification rules.

[0070] Step 120: Identify the external input interface corresponding to the runtime service of the UEFI firmware according to the external input interface identification rule, and use the identified external input interface as a taint source to form a corresponding taint source set.

[0071] Step 130: Based on the conditional race vulnerability security-sensitive instruction identification rule, identify the conditional race vulnerability security-sensitive instructions corresponding to the runtime service of the UEFI firmware, and use the identified conditional race vulnerability security-sensitive instructions as taint convergence points to form a corresponding taint convergence point set.

[0072] And, step 140: according to the external input security checkpoint identification rule, identify the external input security checkpoint corresponding to the runtime service of the UEFI firmware, and use the instructions and functions for security verification of the identified external input as input checkpoints to form a corresponding input checkpoint set.

[0073] In order to further improve the effectiveness and reliability of taint source identification, in a specific application example of step 120, the external input interface identification rule includes: the type of the external input interface and the identification method corresponding to each type of the external input interface;

[0074] The types of the external input interface include: a communication buffer pointer corresponding to the runtime service of the UEFI firmware, a memory space for storing a CPU status register corresponding to the runtime service of the UEFI firmware, a hard-coded address, and a UEFINVRAM variable.

[0075] Correspondingly, the identification methods corresponding to each type of external input interface are shown in Table 1.

[0076] Table 1 - Types and identification methods of external input interfaces

[0077]

[0078] In order to further improve the effectiveness and reliability of taint convergence point identification, in a specific application example of step 130, the conditional race vulnerability security sensitive instruction identification rule includes: the type of the conditional race vulnerability security sensitive instruction and the identification method corresponding to each type of the conditional race vulnerability security sensitive instruction;

[0079] Among them, the security-sensitive instructions of the conditional competition vulnerability include: indirect memory access instructions, indirect control transfer instructions, setting variable interfaces and memory-sensitive functions.

[0080] Correspondingly, the identification methods corresponding to each type of security-sensitive instructions with conditional competition vulnerabilities are shown in Table 2.

[0081] Table 2 - Types and identification methods of security-sensitive instructions of conditional competition vulnerabilities

[0082]

[0083] In order to further improve the effectiveness and reliability of taint convergence point identification, in a specific application example of step 140, the external input security checkpoint identification rule includes: the type of the external input security checkpoint and the identification method corresponding to each type of the external input security checkpoint;

[0084] The externally input security checkpoints include: instructions and functions for performing security checks input from outside the UEFI firmware.

[0085] Correspondingly, the identification methods corresponding to the external input security check points are shown in Table 3.

[0086] Table 3 - Types and identification methods of external input security checkpoints

[0087]

[0088]

[0089] In order to further improve the reliability and effectiveness of the static detection of the service condition competition vulnerability of the UEFI firmware at runtime, in the embodiment of the present application, a static detection method of the service condition competition vulnerability of the UEFI firmware at runtime is provided. Figure 2 Step 200 of the static detection method for the runtime service condition race vulnerability of the UEFI firmware specifically includes the following contents:

[0090] Step 210: For each taint source in the taint source set, search for the instruction that introduces the taint source in the inter-procedural control flow graph.

[0091] Step 220: starting from each instruction that introduces the taint source, traverse all paths in the inter-procedural control flow graph, and execute the preset path recording step for each instruction in each node in each path.

[0092] In step 220, see Figure 3 , the path recording step specifically includes the following contents:

[0093] Step 221: If the current instruction is any taint sink point in the taint sink point set, and the operand of the instruction is tainted, then take the taint source in the path where the instruction is located as the starting point and record the target path from the taint source to the taint sink point.

[0094] Step 222: Starting from the taint convergence point in the target path, traverse all instructions in the target path backward to identify the external structure member used to assign values ​​to the operands.

[0095] Step 223: Based on each input checkpoint in the input checkpoint set, determine whether there is an input checkpoint for the external structure member between the taint source and the statement that assigns a value to the operand; if so, determine whether there is a read operation for the external structure member between the taint source and the input checkpoint for the external structure member.

[0096] Step 224: If there is a read operation on the external structure member between the taint source and the input checkpoint for the external structure member, the target path is added to the conditional race vulnerability set currently corresponding to the runtime service of the UEFI firmware.

[0097] For example, for the taint source taint_sourcei in the taint source set taint_sources, the path recording step is used to perform the following:

[0098] a) Traverse the interprocedural control flow graph and identify the instructions that introduce taint_sourcei;

[0099] b) Starting from the instruction that introduces taint_sourcei, traverse all paths in the interprocedural control flow graph and perform the following operations on each instruction in each node in the path:

[0100] b-1) If the current instruction is a security-sensitive instruction vul_inst and the operand op of the instruction is tainted, then the path potential_vul_path from the taint source taint_sourcei to the current instruction is recorded;

[0101] After b-2), starting from vul_inst, traverse all instructions in potential_vul_path backwards to identify the external structure member (struct_base, member_offset) assigned to op. Based on the input checkpoints recorded in the taint_sanitizers set, determine whether there is an input check for (struct_base, member_offset) between taint_sourcei and the statement assigning the value to op. If so, determine whether there is a read operation on (struct_base, member_offset) between taint_sourcei and the input checkpoint for (struct_base, member_offset). If so, add potential_vul_path to the conditional race vulnerability set vul_set.

[0102] In order to further improve the reliability and effectiveness of the static detection of the service condition competition vulnerability of the UEFI firmware at runtime, in the embodiment of the present application, a static detection method of the service condition competition vulnerability of the UEFI firmware at runtime is provided. Figure 2 The method for statically detecting a runtime service race vulnerability in UEFI firmware further includes the following steps after step 200:

[0103] Step 300: traverse each instruction under each of the target paths, and obtain the symbolic expression of the quadruple corresponding to each operand in each instruction, so as to identify the input format and / or alias corresponding to each instruction under each of the target paths based on the symbolic expression of the quadruple.

[0104] In step 300, in order to further improve the accuracy of static detection, the embodiment of the present application also designs an algorithm for inferring the input format of a UEFI firmware runtime service program. The UEFI firmware runtime service program input format inference traverses each instruction under the current path and calculates the symbolic expression of each operand in the instruction. For indirect memory access operands of the form "[base+index*scale+displacement]", the algorithm uses a four-tuple form of (base, index, scale, displacement) to represent a variable pointing to a specific field of the structure, where base represents a base pointer pointing to the base address of the structure, and the offset is a relative offset within the structure, and the offset is expressed in the form of base+index*scale+displacement. And during the analysis process, in order to identify nested data structures, the algorithm recursively retrieves the symbolic expression of the base pointer (base), and uses a nested (base, index, scale, displacement) method to recursively represent the base pointer (base), thereby identifying complex input types with multi-layer nested pointer structures. In addition, the algorithm also recursively retrieves the source symbol information of the current variable, and the recursive process can solve the alias problem.

[0105] In order to further improve the reliability and effectiveness of the static detection of the service condition competition vulnerability of the UEFI firmware at runtime, in the embodiment of the present application, a static detection method of the service condition competition vulnerability of the UEFI firmware at runtime is provided. Figure 2 The method for statically detecting a runtime service race vulnerability in UEFI firmware further includes the following contents before step 100:

[0106] Step 010: Generate an intra-process control flow graph corresponding to each runtime service driver data corresponding to the UEFI firmware;

[0107] Step 020: traverse all nodes in the control flow graph within each process, and execute the preset function call instruction analysis step for each function call instruction in each node to update the control flow graph within each process, and then generate the corresponding inter-process control flow graph.

[0108] In step 020, see Figure 4 The function call instruction analysis step specifically includes the following contents:

[0109] Step 021: For the target function address in the function call instruction of direct call type, the corresponding called function is added as a new node into the control flow graph within the process.

[0110] Step 022: For the target function address in the function call instruction of indirect call type, the calling code position corresponding to the function call instruction is obtained based on the backward slicing method, and the corresponding called function is used as a new node based on the calling code position and added to the control flow graph within the process.

[0111] For example, the function call instruction analysis step is used to perform the following:

[0112] a) Perform intra-procedural analysis on each function fi and generate an intra-procedural control flow graph cfgi;

[0113] b) For each process control flow graph cfgi, traverse all nodes of cfgi and analyze each function call instruction in each node as follows:

[0114] b-1) For direct calls, according to the target function address in the function call instruction, the called function is added as a new node node into the control flow graph cfgi within the process;

[0115] b-2) For indirect calls, use backward slicing technology to find the code location of the function call, and add the called function as a new node node to the control flow graph cfgi within the process.

[0116] To further illustrate the above embodiment, the present application also provides a specific application example of a static detection method for a UEFI firmware runtime service condition race vulnerability. The static detection method for a UEFI firmware runtime service condition race vulnerability is divided into two stages: inter-process control flow graph construction and vulnerability static detection. The inter-process control flow graph construction stage mainly constructs an inter-process control flow graph driven by the UEFI firmware runtime service. The vulnerability static detection stage is divided into three steps: taint analysis, data structure recovery, and alias analysis. Figure 5 The specific application examples of the static detection method for the runtime service condition race vulnerability of UEFI firmware include the following:

[0117] Step 1: Interprocedural Control Flow Graph Construction

[0118] This application example utilizes techniques such as taint analysis and alias analysis to detect potential race conditions within UEFI firmware runtime services. Therefore, for each UEFI firmware runtime service driver, this application example requires the creation of an interprocedural control flow graph (CFG) to assist with alias analysis and the propagation of external inputs within the UEFI firmware runtime service. Generating a global CFG involves two main steps: first, establishing an intraprocedural CFG; second, constructing an interprocedural CFG based on the constructed intraprocedural CFG and function call instructions. The interprocedural CFG generation algorithm is shown in Table 4.

[0119] Table 4

[0120]

[0121] Step 2: Static vulnerability detection

[0122] In this phase, this application example first identifies taint sources, taint sinks, and input checkpoints that meet the characteristics of the UEFI firmware runtime service race vulnerability based on the characteristics of the UEFI firmware runtime service race vulnerability. Then, based on the taint sources, taint sinks, input checkpoints, and the generated inter-procedural control flow graph, taint analysis is used to generate the path between the taint source and the taint sink that can trigger the vulnerability. Finally, using pattern matching methods, the existence of the vulnerability is determined by checking whether the path between the taint source and the taint sink meets the characteristics of the UEFI firmware runtime service race vulnerability.

[0123] The characteristics of the UEFI firmware runtime service condition race vulnerability are described as follows:

[0124] Through the analysis of historical UEFI firmware runtime service race vulnerabilities, this application example found that the core root cause of the UEFI firmware runtime service program race vulnerability is:

[0125] (1) The UEFI firmware runtime service running on the high-privilege CPU copies external input twice from the same memory space controlled by the low-privilege server;

[0126] (2) When the UEFI firmware runtime service copies external input from the low-privilege controllable memory space, the first copy will perform input verification, and the second copy will use the obtained external input;

[0127] (3) The second copied external input propagates to security-sensitive instructions that can affect the execution state of UEFI firmware runtime services;

[0128] For UEFI firmware runtime service code that meets the above conditions, an attacker with lower permissions than the UEFI firmware runtime service can tamper with the external input data required by the UEFI firmware runtime service within the time window between the input verification for the first copy and the second copy. Since the attacker tampered with the input data after the input verification, the external input copied by the UEFI firmware runtime service for the second time is the malicious input constructed by the attacker. If these external inputs propagate to security-sensitive instructions that can affect the execution state of the UEFI firmware runtime service, a security vulnerability will be triggered.

[0129] Based on this, the specific steps of step 2 are as follows:

[0130] 2-1. Taint Analysis

[0131] We obtain the vulnerability signature set and inter-procedural control flow graph generated above and combine them with static taint analysis and pattern matching techniques to identify race conditions in UEFI firmware runtime services. The specific algorithm is shown in Table 5.

[0132] Table 5

[0133]

[0134]

[0135] Step 3: Input format inference

[0136] To further improve analysis accuracy, this application example designs an algorithm for inferring the input format of UEFI firmware runtime services. This algorithm traverses each instruction in the current path and calculates the symbolic expression for each operand in the instruction. For indirect memory access operands of the form [base+index*scale+displacement], the algorithm uses a four-tuple (base, index, scale, displacement) to represent a variable pointing to a specific field of a structure, where base represents the base pointer pointing to the structure's base address, and offset is a relative offset within the structure, expressed as base+index*scale+displacement. Furthermore, during analysis, to identify nested data structures, the algorithm recursively retrieves the symbolic expression of the base pointer (base), using a nested (base, index, scale, displacement) representation to recursively represent the base pointer, thereby identifying complex input types with multiple nested pointer structures. Furthermore, the algorithm recursively retrieves the source symbol information for the current variable, recursively resolving aliasing issues.

[0137] As can be seen, the application example of this application designs the characteristics of the UEFI firmware runtime service race vulnerability, including the taint source, taint sink, and input checkpoint characteristics related to the race vulnerability; and provides the input type of the UEFI firmware runtime service and the dependency recovery method between structures, as well as the UEFI firmware runtime service race vulnerability detection method. Compared with other taint analysis technologies, this application example has the following advantages:

[0138] (1) The characteristics of UEFI firmware runtime service race vulnerabilities are summarized, including taint sources, taint sinks, and input checkpoint features related to race vulnerabilities;

[0139] (2) It can recover different input types and inter-structural dependencies of different UEFI firmware runtime services;

[0140] (3) It can effectively detect the conditional race vulnerabilities in the UEFI firmware runtime service.

[0141] In other words, this application example involves the detection technology of conditional race vulnerabilities in the field of static analysis of UEFI firmware runtime services. It is mainly aimed at the current situation where there is no effective static analysis method for conditional race vulnerabilities in UEFI firmware runtime services. The input interface characteristics of the UEFI firmware runtime service defined in the underlying UEFI standard are used to identify the input interface of the binary UEFI firmware runtime service. Afterwards, the identified input interface is used as the taint source, and the propagation process of the tainted data related to the input is tracked using the taint analysis method. During the taint analysis process, based on the UEFI firmware runtime service conditional race vulnerability model, the pattern matching method is used to achieve automated static detection and identification of UEFI firmware runtime service conditional race vulnerabilities.

[0142] From the software level, the present application also provides a UEFI firmware runtime service condition competition vulnerability static detection device for executing all or part of the UEFI firmware runtime service condition competition vulnerability static detection method, see Figure 6 The static detection device for the runtime service condition competition vulnerability of the UEFI firmware specifically includes the following contents:

[0143] The taint feature identification module 10 is used to identify and generate corresponding taint source sets, taint sink point sets and input check point sets from the runtime service driver data of the UEFI firmware based on the conditional competition vulnerability feature identification rule data corresponding to the runtime service of the preset UEFI firmware.

[0144] The static taint analysis module 20 is configured to perform static taint analysis on the runtime service driver data based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired inter-procedural control flow graph of the runtime service driver data to generate a target path between the taint source and the taint sink point; and determine whether a conditional race vulnerability currently exists in the runtime service of the UEFI firmware based on the target path in the form of a pattern matching result.

[0145] The embodiment of the static detection device for runtime service condition competition vulnerability of UEFI firmware provided in this application can be specifically used to execute the processing flow of the embodiment of the static detection method for runtime service condition competition vulnerability of UEFI firmware in the above-mentioned embodiment. Its functions are not described in detail here, and reference can be made to the detailed description of the embodiment of the static detection method for runtime service condition competition vulnerability of UEFI firmware mentioned above.

[0146] The portion of the UEFI firmware runtime service condition competition vulnerability static detection device that performs the UEFI firmware runtime service condition competition vulnerability static detection can be executed in the server or completed in the client device. The specific selection can be made based on the processing capability of the client device and the limitations of the user's usage scenario. This application does not limit this. If all operations are completed in the client device, the client device may also include a processor for the specific processing of the UEFI firmware runtime service condition competition vulnerability static detection.

[0147] The client device may include a communication module (i.e., a communication unit) that can establish a communication connection with a remote server to implement data transmission with the server. The server may include a server on the task scheduling center side, and in other implementation scenarios, may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a server structure of a distributed device.

[0148] The server and the client device may communicate using any suitable network protocol, including network protocols that have not yet been developed as of the filing date of this application. Examples of such network protocols include TCP / IP, UDP / IP, HTTP, and HTTPS. Furthermore, examples of such network protocols include RPC (Remote Procedure Call Protocol) and REST (Representational State Transfer) protocols, which are used on top of the aforementioned protocols.

[0149] From the above description, it can be seen that the static detection device for conditional competition vulnerabilities in the runtime services of UEFI firmware provided in the embodiment of the present application can realize conditional competition vulnerability detection for the runtime services of UEFI firmware, and can effectively improve the effectiveness and reliability of static vulnerability detection, thereby improving the security and stability of UEFI firmware executing runtime services.

[0150] The present application also provides an electronic device (i.e., a computer device) that may include a processor, a memory, a receiver, and a transmitter. The processor is configured to execute the static detection method for the runtime service condition race vulnerability of the UEFI firmware mentioned in the above embodiment. The processor and the memory may be connected via a bus or other means, with bus connection being used as an example. The receiver may be connected to the processor and the memory via a wired or wireless manner.

[0151] The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0152] The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as the program instructions / modules corresponding to the static detection method for a run-time service race vulnerability in UEFI firmware in the embodiments of the present application. The processor executes the non-transitory software programs, instructions, and modules stored in the memory to perform various functional applications and data processing of the processor, thereby implementing the static detection method for a run-time service race vulnerability in UEFI firmware in the above method embodiments.

[0153] The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory may optionally include a memory remotely located relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0154] The one or more modules are stored in the memory, and when executed by the processor, perform the static detection method for runtime service condition competition vulnerability of UEFI firmware in the embodiment.

[0155] In some embodiments of the present application, the user equipment may include a processor, a memory and a transceiver unit, and the transceiver unit may include a receiver and a transmitter. The processor, memory, receiver and transmitter may be connected through a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0156] As an implementation method, the functions of the receiver and transmitter in this application can be considered to be implemented through a transceiver circuit or a dedicated transceiver chip, and the processor can be considered to be implemented through a dedicated processing chip, a processing circuit or a general-purpose chip.

[0157] As another implementation method, it is possible to use a general-purpose computer to implement the server provided in the embodiments of the present application. That is, the program code for implementing the functions of the processor, receiver, and transmitter is stored in a memory, and the general-purpose processor implements the functions of the processor, receiver, and transmitter by executing the code in the memory.

[0158] The present application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned static detection method for a runtime service condition race vulnerability in UEFI firmware. The computer-readable storage medium may be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the art.

[0159] It should be understood by those skilled in the art that the various exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is specifically performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. When implemented in hardware, it can be, for example, an electronic circuit, an application-specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of this application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0160] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0161] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or replace features of other embodiments.

[0162] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Those skilled in the art will appreciate that various modifications and variations of the present embodiment are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A static detection method for a runtime service condition race vulnerability in UEFI firmware, characterized in that: include: Based on preset conditional race vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, a corresponding taint source set, a taint sink point set, and an input checkpoint set are identified and generated from the runtime service driver data of the UEFI firmware; Performing static taint analysis on the runtime service driver data to generate a target path between a taint source and a taint sink point based on the taint source set, the taint sink point set, the input checkpoint set, and a pre-acquired inter-procedural control flow graph of the runtime service driver data; And in a manner of pattern matching results, it is determined according to the target path whether the runtime service of the UEFI firmware currently has a conditional competition vulnerability.

2. The method for statically detecting a service condition race vulnerability in UEFI firmware at runtime according to claim 1, wherein: The method of identifying and generating a corresponding taint source set, a taint sink point set, and an input checkpoint set from the UEFI firmware runtime service driver data based on the conditional race vulnerability feature identification rule data corresponding to the preset UEFI firmware runtime service includes: Receive race condition vulnerability feature identification rule data corresponding to the runtime service of the UEFI firmware, wherein the race condition vulnerability feature identification rule data includes: external input interface identification rules, race condition vulnerability security sensitive instruction identification rules, and external input security checkpoint identification rules; Identify, according to the external input interface identification rule, an external input interface corresponding to the runtime service of the UEFI firmware, and use the identified external input interface as a taint source to form a corresponding taint source set; Based on the conditional race vulnerability security-sensitive instruction identification rule, identifying the conditional race vulnerability security-sensitive instruction corresponding to the runtime service of the UEFI firmware, and using the identified conditional race vulnerability security-sensitive instruction as a taint convergence point to form a corresponding taint convergence point set; Furthermore, according to the external input security checkpoint identification rule, the external input security checkpoint corresponding to the runtime service of the UEFI firmware is identified, and the instructions and functions for security verification of the identified external input are used as input checkpoints to form a corresponding input checkpoint set.

3. The static detection method for the runtime service condition race vulnerability of UEFI firmware according to claim 1, characterized in that: performing static taint analysis on the runtime service driver data to generate a target path between a taint source and a taint sink point based on the taint source set, the taint sink point set, the input checkpoint set, and a pre-acquired inter-procedural control flow graph of the runtime service driver data; And determining whether the runtime service of the UEFI firmware currently has a conditional race vulnerability according to the target path in a pattern matching result, including: For each taint source in the taint source set, searching for instructions that introduce the taint source in the inter-procedural control flow graph; Taking each instruction that introduces the taint source as a starting point, traverse all paths in the interprocedural control flow graph, and perform a preset path recording step for each instruction in each node in each path; wherein the path recording step includes: if the current instruction is any taint sink point in the taint sink point set and the operand of the instruction is tainted, taking the taint source in the path where the instruction is located as a starting point, recording the target path from the taint source to the taint sink point; Starting from the taint convergence point in the target path, traversing all instructions in the target path backward to identify an external structure member used to assign a value to the operand; According to each input checkpoint in the input checkpoint set, determining whether there is an input checkpoint for the external structure member between the taint source and the statement for assigning a value to the operand, and if so, determining whether there is a read operation for the external structure member between the taint source and the input checkpoint for the external structure member; If there is a read operation on the external structure member between the taint source and the input checkpoint for the external structure member, the target path is added to a conditional competition vulnerability set currently corresponding to the runtime service of the UEFI firmware.

4. The method for statically detecting a service condition race vulnerability in UEFI firmware at runtime according to claim 1, wherein: Also includes: Traverse each instruction under each of the target paths, and obtain the symbolic expression of the quadruple corresponding to each operand in each instruction, so as to identify the input format and / or alias corresponding to each instruction under each of the target paths based on the symbolic expression of the quadruple.

5. The method for statically detecting a service condition race vulnerability in UEFI firmware at runtime according to claim 1, wherein: Before performing static taint analysis on the runtime service driver data to generate a target path between a taint source and a taint sink point based on the taint source set, the taint sink point set, the input checkpoint set, and the pre-acquired inter-procedural control flow graph of the runtime service driver data, the method further includes: Generate an intra-process control flow graph corresponding to each runtime service driver data corresponding to the UEFI firmware; Traversing all nodes in each of the intra-procedural control flow graphs, and performing a preset function call instruction analysis step on each function call instruction in each of the nodes, so as to update each of the intra-procedural control flow graphs, and thereby generate a corresponding inter-procedural control flow graph; The function call instruction analysis step includes: For a target function address in a function call instruction of direct call type, the corresponding called function is added as a new node into the control flow graph within the process; For the target function address in the function call instruction of indirect call type, the calling code position corresponding to the function call instruction is obtained based on the backward slicing method, and the corresponding called function is taken as a new node based on the calling code position and added to the control flow graph within the process.

6. The method for statically detecting a service condition race vulnerability in UEFI firmware runtime according to claim 2, wherein: The external input interface identification rules include: the type of the external input interface and the identification methods corresponding to each type of the external input interface; The types of the external input interface include: a communication buffer pointer corresponding to the runtime service of the UEFI firmware, a memory space for storing a CPU status register corresponding to the runtime service of the UEFI firmware, a hard-coded address, and a UEFINVRAM variable.

7. The method for statically detecting a service condition race vulnerability in UEFI firmware at runtime according to claim 2, wherein: The conditional race vulnerability security sensitive instruction identification rules include: the type of the conditional race vulnerability security sensitive instruction and the identification method corresponding to each type of the conditional race vulnerability security sensitive instruction; Among them, the security-sensitive instructions of the conditional competition vulnerability include: indirect memory access instructions, indirect control transfer instructions, setting variable interfaces and memory-sensitive functions.

8. The method for statically detecting a service condition race vulnerability in UEFI firmware at runtime according to claim 2, wherein: The external input security checkpoint identification rules include: the type of the external input security checkpoint and the identification methods corresponding to each type of the external input security checkpoint; The externally input security checkpoints include: instructions and functions for performing security checks input from outside the UEFI firmware.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for statically detecting a runtime service condition race vulnerability of UEFI firmware according to any one of claims 1 to 8 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method for statically detecting a runtime service condition race vulnerability of UEFI firmware according to any one of claims 1 to 8 is implemented.

Images