Policy-based vulnerability dynamic shielding method and device, and electronic equipment

Abstract

The application provides a kind of policy-based vulnerability dynamic shielding method, device and electronic equipment, wherein the method comprises: based on dynamic vulnerability detection mechanism, obtain binary level security policy;Wherein, binary level security policy includes perception point related information, decision point related information, constraint information and execution unit information;Based on binary level security policy, detect potential attack existing in current running program, and execute target operation, and shield vulnerability in time, ensure the normal operation of current running program.The method generates binary level security policy and executes based on dynamic vulnerability detection mechanism, can provide effective protection measures for active program and kernel with vulnerability before vulnerability is repaired, and this process does not require developers to have professional security knowledge or spend a lot of time for manual analysis.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a policy-based dynamic vulnerability shielding method, apparatus, and electronic device. Background Technology

[0002] Ensuring the security of computer systems and software remains a significant challenge, with white-hat hackers discovering a large number of security vulnerabilities in released computer systems and software every year. Although most vulnerabilities are patched before disclosure, many remain unpatched after disclosure.

[0003] Unfortunately, patching vulnerabilities often takes a long time. Developers must conduct a comprehensive analysis of the affected programs, identify the root cause of the vulnerability, and develop patches to address the issues. The time between vulnerability discovery and actual patch deployment provides opportunities for malicious attackers to exploit it. Therefore, an effective and timely vulnerability mitigation mechanism can temporarily prevent vulnerability exploitation, significantly reducing the risk of a successful attack.

[0004] In order to effectively prevent vulnerability exploitation before the official patch is actually deployed, researchers have proposed a variety of vulnerability masking or temporary vulnerability patching solutions.

[0005] Some of these methods use code injection to dynamically update vulnerable code, but this approach carries security risks, potentially leading to unexpected program behavior or introducing new vulnerabilities. In contrast, the Extended Berkeley Packet Filter (eBPF) is a kernel technology that allows sandboxed programs to run within the Linux kernel, enabling developers to run specific functionalities without modifying the kernel code. Some methods utilize eBPF for vulnerability detection; while these eBPF-based methods cannot easily modify program execution, they still possess the ability to write to memory, posing a danger and potentially causing unexpected behavior.

[0006] Other solutions employ alternative methods, such as returning error codes or using a combination of rules and hardware breakpoints to detect exploits. However, these solutions require instrumentation of the target program or reloading additional libraries, therefore they cannot provide protection for already running processes or the kernel. Furthermore, these methods are only applicable to certain attack scenarios and may affect program functionality, exhibiting significant limitations.

[0007] For example, Talos leverages the program's inherent error handling mechanism to insert a return instruction with an appropriate error code at the entry point of a vulnerable function. However, this method relies on the program's error code handling mechanism and does not perform input checking. Therefore, even without exploitation, the target function will return an error code instead of running normally. If the vulnerable function is a critical core function of the program, using Talos may affect the program's functionality. InstaGuard requires loading additional libraries and relies on hardware breakpoints. Furthermore, due to design limitations, the types of vulnerabilities it can support are relatively limited; for example, it cannot effectively detect and block exploits such as double-free and complex use-after-free memory corruption vulnerabilities.

[0008] Therefore, how to solve the problem that existing vulnerability shielding solutions cannot provide effective security for running programs and kernels is an important issue that urgently needs to be addressed in the computer field. Summary of the Invention

[0009] This invention provides a policy-based dynamic vulnerability shielding method, device, and electronic device to overcome the shortcomings of existing vulnerability shielding schemes that cannot provide effective security protection for running programs and kernels, and to provide security protection for running programs and kernels and cope with various attack scenarios.

[0010] On one hand, the present invention provides a policy-based dynamic vulnerability shielding method, comprising: obtaining a binary-level security policy based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; and based on the binary-level security policy, detecting potential attacks in the currently running program and performing target operations to shield vulnerabilities in a timely manner and ensure the normal operation of the currently running program.

[0011] Furthermore, the step of obtaining a binary-level security policy based on a dynamic vulnerability detection mechanism includes: when a vulnerability is detected in the currently running program that has not yet been disclosed, obtaining vulnerability report information according to the dynamic vulnerability detection mechanism; analyzing the vulnerability report information to obtain vulnerability information; generating a source code-level security policy based on the vulnerability information and a general policy for the current vulnerability; and converting the source code-level security policy into the binary-level security policy based on the debugging information and binary files of the currently running program.

[0012] Furthermore, the step of detecting potential attacks in the currently running program based on the binary-level security policy includes: obtaining perception point operation information according to perception point-related information in the binary-level security policy; the perception point operation information includes the memory state, register values, and counter usage of the currently running program; obtaining decision point operation information according to decision point-related information in the binary-level security policy, the decision point operation information including the memory state and register values ​​of the currently running program; and detecting potential attacks in the currently running program based on the perception point operation information and the decision point operation information.

[0013] Furthermore, the step of detecting potential attacks in the currently running program based on the perception point operation information and the decision point operation information includes: obtaining a general strategy corresponding to the vulnerabilities existing in the currently running program; generating target constraints based on the general strategy; determining that there are no potential attacks in the currently running program if the perception point operation information and the decision point operation information satisfy the target constraints; and determining that there are potential attacks in the currently running program if the perception point operation information and the decision point operation information do not satisfy the target constraints.

[0014] Furthermore, the vulnerability information includes the vulnerability type, the name, path, and line number of the vulnerability source file, the name of the memory object, the size of the memory object, the memory object allocation point, and the memory object release point.

[0015] Furthermore, the steps of performing the target operation specifically include: suspending the currently running program; or interrupting the currently running program; or issuing a warning for the currently running program; or returning an error code for the currently running program.

[0016] Furthermore, the step of obtaining the binary-level security policy includes: signing the binary-level security policy, and verifying the signature of the binary-level security policy before executing the policy.

[0017] Secondly, the present invention also provides a policy-based dynamic vulnerability shielding device, comprising: a policy generation module, used to obtain a binary-level security policy based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; and a policy implementation module, used to detect potential attacks in the currently running program based on the binary-level security policy, and perform target operations to shield vulnerabilities in a timely manner and ensure the normal operation of the currently running program.

[0018] Thirdly, the present invention also 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, when executing the computer program, implements the policy-based dynamic vulnerability masking method as described above.

[0019] Fourthly, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the policy-based dynamic vulnerability masking method as described above.

[0020] This invention provides a policy-based dynamic vulnerability shielding method. By employing a dynamic vulnerability detection mechanism, it obtains binary-level security policies. These binary-level security policies include information related to awareness points, decision points, constraints, and execution units. Based on these policies, the method detects potential attacks in currently running programs and executes targeted operations to promptly shield vulnerabilities and ensure the normal operation of the program. This method automatically generates and executes binary-level security policies based on a dynamic vulnerability detection mechanism, providing effective protection for active programs and kernels with vulnerabilities before they are patched. Furthermore, this process does not require developers to possess specialized security knowledge or spend significant time on manual analysis. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the policy-based dynamic vulnerability masking method provided in an embodiment of the present invention.

[0023] Figure 2 This is a schematic diagram of the overall process of the policy-based dynamic vulnerability masking method provided in the embodiments of the present invention.

[0024] Figure 3 This is a schematic diagram of the structure of the policy-based dynamic vulnerability shielding device provided in an embodiment of the present invention.

[0025] Figure 4 This is a schematic diagram of the physical structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0027] It's important to note that patching vulnerabilities typically takes a considerable amount of time. Developers must conduct a comprehensive analysis of the affected programs, identify the root cause of the vulnerability, and develop patches to address these issues. However, the time between discovering a vulnerability and actually deploying a patch provides opportunities for malicious attackers to exploit it.

[0028] In response, existing technologies have proposed many solutions for vulnerability shielding or timely vulnerability patching, but these solutions cannot effectively detect various vulnerabilities, nor can they provide effective security guarantees for running programs and kernels.

[0029] In view of this, the present invention proposes a policy-based dynamic vulnerability masking method, specifically, Figure 1 The diagram illustrates a flowchart of a policy-based dynamic vulnerability masking method provided in an embodiment of the present invention.

[0030] like Figure 1 As shown, the method includes steps S110-S120, and steps S110-S120 and related steps will be described in detail below.

[0031] S110, Based on the dynamic vulnerability detection mechanism, obtain the binary-level security policy; wherein, the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information.

[0032] Understandably, when a vulnerability is detected but not disclosed, this step first requires obtaining a vulnerability report or source code-level vulnerability information generated by the vendor based on the dynamic vulnerability detection mechanism. The vulnerability report or source code-level vulnerability information includes the vulnerability type, the source code information corresponding to the vulnerability trigger point, and the memory object information involved.

[0033] Then, based on the vulnerability report or source code-level vulnerability information, combined with the debugging information of the target program (currently running program), binary-level vulnerability information of the target binary file is generated, such as specific binary addresses, register information, etc.

[0034] Furthermore, based on the generated binary-level vulnerability information, security strategies for dealing with different attack scenarios can be generated, namely binary-level security strategies.

[0035] Dynamic vulnerability detection mechanisms are a method of checking for security vulnerabilities during software runtime. They typically involve real-time monitoring of program behavior to identify potential security issues. Unlike static analysis, dynamic analysis is performed during software execution, allowing it to capture problems that only manifest at runtime.

[0036] Dynamic vulnerability detection mechanisms include, but are not limited to, fuzzing, dynamic application security testing, memory error detection, interactive application security testing, runtime application self-protection, monitoring and logging, and penetration testing. They are crucial for improving software security, especially in complex production environments, where they can promptly identify and fix vulnerabilities and reduce the risk of attacks.

[0037] Binary-level security policies include, but are not limited to, information related to perception points, information related to decision points, constraint information, and execution unit information.

[0038] Regarding perceptron-related information, this information describes at what addresses and what necessary runtime information needs to be collected. A perceptron refers to a location during program execution where runtime state data is collected. Perceptron-related information includes, for example, counter usage, register status, and memory access information.

[0039] Regarding decision point information, this information is used to describe, using arithmetic constraints, what security checks need to be performed at what locations. A decision point is the location in the program where a security decision is made based on information collected from sensing points. The decision point information is the same as the sensing point information described above, but it lacks a counter flag and corresponding numerical settings.

[0040] Regarding constraint information, constraint information is used to describe how a program should behave or what it should not do under specific conditions.

[0041] Regarding execution unit information, this information describes the execution unit to be executed. An execution unit is a component or module responsible for executing a specific security policy.

[0042] It should be noted that, in order to quickly generate the security policy in this embodiment, this step can be achieved through a policy generator deployed on the vendor's server.

[0043] It should also be noted that after obtaining the binary-level security policy, a signature verification mechanism can be introduced to prevent attackers from forging or tampering with the policy. Specifically, the obtained binary-level security policy is signed, and then verified before execution to ensure that the executed policy is the aforementioned signed binary-level security policy.

[0044] S120, based on the binary-level security policy, detect potential attacks in the currently running program, and perform target operations to promptly block vulnerabilities and ensure the normal operation of the currently running program.

[0045] It is understandable that, based on obtaining the binary-level security policy through the dynamic vulnerability detection mechanism in step S110, step S120 will further execute the binary-level security policy.

[0046] Specifically, based on the binary-level security policy, we can know: the location of the perception point and the decision point, what information needs to be obtained at the perception point and the decision point, what constraints the obtained information needs to meet, and what actions should be taken when a vulnerability is discovered.

[0047] In other words, the system acquires operational information at the sensing point and at the decision point, and then determines whether the operational information at both points satisfies the target constraints. If the target constraints are met, it indicates that there are no potential attacks in the current program; otherwise, it indicates that there are potential attacks in the current program, and the target action needs to be taken.

[0048] The target operation can be determined based on the execution unit information in the binary-level security policy, such as interrupting, pausing, warning, or avoiding the execution of vulnerable code.

[0049] It should be noted that even if the information from the sensing point and the information from the decision point meet the target constraints, the target operation still needs to be executed. However, the target operation at this time is to continue running the currently running program.

[0050] Similarly, in order to use the binary-level security policy obtained in step S110 quickly and effectively, step S120 can be implemented by a policy enforcer running in the kernel of the target device, which can be any smart device.

[0051] In this embodiment, a binary-level security policy is obtained based on a dynamic vulnerability detection mechanism. This binary-level security policy includes information related to awareness points, decision points, constraints, and execution units. Based on this policy, potential attacks in the currently running program are detected, and targeted operations are executed to promptly block vulnerabilities and ensure the normal operation of the program. This method automatically generates and executes a binary-level security policy based on a dynamic vulnerability detection mechanism, providing effective protection for active programs and the kernel with vulnerabilities before they are patched. Furthermore, this process does not require developers to possess specialized security knowledge or spend significant time on manual analysis.

[0052] Based on the above embodiments, the process of obtaining binary-level security policies will be described in detail below.

[0053] If a vulnerability is detected in the currently running program that has not yet been disclosed, vulnerability report information is obtained according to the dynamic vulnerability detection mechanism; the vulnerability report information is analyzed to obtain vulnerability information; based on the vulnerability information and the general policy for the current vulnerability, a source code level security policy is generated; based on the debugging information and binary files of the currently running program, the source code level security policy is converted into a binary level security policy.

[0054] Understandably, when a vulnerability is detected in a currently running program that has not yet been disclosed, security developers and maintainers can obtain vulnerability report information through a dynamic vulnerability detection mechanism. Vulnerability report information includes, but is not limited to, the vulnerability type and the call stack information of the detection point.

[0055] The vulnerability types include, but are not limited to, injection attacks, cross-site scripting, cross-site request forgery, buffer overflows, information leakage, and configuration errors.

[0056] The call stack information at a checkpoint refers to the function call history at a specific moment during program execution, showing how the current execution position was reached through a series of function calls. The call stack information at a checkpoint includes, but is not limited to, function names, file names, line numbers, parameters, and local variables.

[0057] It should be noted that for different vulnerability types, the vulnerability report information will also provide additional vulnerability information. For example, when ASA detects a use-after-free vulnerability, it will also provide the call stack information of the target memory object at the allocation point and the call stack information at the free point.

[0058] Furthermore, analyzing vulnerability report information allows us to understand the nature of the vulnerability and the information available when it was detected, i.e., vulnerability information. Vulnerability information includes the vulnerability type (e.g., buffer overflow, null pointer dereference, etc.) and the source code line number and function call information where the detection point is located, derived from call stack information.

[0059] In a specific embodiment, taking a vulnerability type of use-after-release vulnerability as an example, the vulnerability information shown in Table 1 below can be obtained by analyzing the vulnerability report information.

[0060] Table 1

[0061]

[0062] As shown in Table 1 above, the vulnerability information analyzed includes the vulnerability type, the name, path, and line number of the vulnerability source file, the name of the memory object, the size of the memory object, the allocation point of the memory object, and the release point of the memory object.

[0063] Next, based on the vulnerability information extracted from the analysis and the general policies for the current vulnerability type, a source code-level security policy can be generated.

[0064] The general strategies for current vulnerability types refer to a series of general prevention and remediation measures taken against specific types of vulnerabilities. For example, general strategies for SQL injection include parameterized queries (using prepared statements or parameterized queries to prevent SQL injection), input validation (strictly validating and cleaning all user input), and the principle of least privilege (using the database account with the fewest privileges to connect).

[0065] Finally, using the debugging information and binary files of the currently running program, the source code-level security policy is converted into a binary-level security policy, as shown in Table 2 below.

[0066] Table 2

[0067]

[0068] As shown in Table 2 above, the binary-level security policy includes information related to the perception point, information related to the decision point, constraint information, and execution unit information.

[0069] Regarding awareness point information, awareness point information can be represented using registers and constants (a combination of registers and constants is sufficient to represent the value in memory or the value of a register). For some vulnerabilities, such as sequential memory corruption vulnerabilities, specific runtime state information is required, such as the allocation and release of heap objects. Therefore, the awareness point also includes a 2-bit flag to indicate the usage status of the counter. The counter usage status includes not using the counter (00), counter decrement (01), and counter increment (10), with the corresponding values ​​representing the specific increment or decrement of the counter.

[0070] Regarding decision point information, this includes the specific executable address and the information that needs to be collected. Similar to perception point information, runtime information, such as values ​​in registers and memory addresses, needs to be collected to make a decision. However, decision points do not have counter flags or corresponding numerical settings.

[0071] Regarding constraint information, constraint information refers to security constraints used for security checks. These constraints can be expressed using variables, constants, logical operators, arithmetic operators, and a small number of whitelisted functions (such as strlen).

[0072] Regarding the execution unit, the execution unit includes operations such as suspending the program, interrupting the program, issuing warnings, or returning error codes. These operations are selected when a potential vulnerability is discovered and needs to be masked.

[0073] The above allows us to obtain binary-level security policies based on the dynamic vulnerability detection mechanism.

[0074] In this embodiment, when a vulnerability is detected in a currently running program that has not yet been disclosed, a vulnerability report is obtained and analyzed using a dynamic vulnerability detection mechanism to obtain vulnerability information. Based on this vulnerability information and general strategies for the current vulnerability, a source code-level security policy is generated. Then, based on the debugging information and binary files of the currently running program, the source code-level security policy is converted into a binary-level security policy. This allows for the detection of potential attacks in the currently running program based on the binary-level security policy, and the execution of targeted operations to promptly block vulnerabilities and ensure the normal operation of the currently running program. This method automatically generates and executes binary-level security policies based on a dynamic vulnerability detection mechanism, providing effective protection for active programs and the kernel with vulnerabilities before they are patched. Furthermore, this process does not require developers to possess specialized security knowledge or spend a significant amount of time on manual analysis.

[0075] Based on the above embodiments, the following will further describe in detail the process of vulnerability shielding based on binary-level security policies.

[0076] Based on binary-level security policies, potential attacks in the currently running program are detected, including: obtaining perception point operation information based on perception point-related information in the binary-level security policy; perception point operation information includes the memory state, register values, and counter usage of the currently running program; obtaining decision point operation information based on decision point-related information in the binary-level security policy; decision point operation information includes the memory state and register values ​​of the currently running program; and detecting potential attacks in the currently running program based on the perception point operation information and the decision point operation information.

[0077] Understandably, some vulnerabilities can be identified by runtime information at the decision point, such as null pointer dereferences and division by zero. However, some vulnerabilities are more complex and require a combination of multiple runtime information points for effective identification, such as heap overflows, use after free, and race conditions. For these types of vulnerabilities, runtime information of the process needs to be collected before the decision point in this embodiment; that is, necessary runtime information needs to be collected at the awareness point, which is the awareness point runtime information.

[0078] Based on the awareness point information in the binary-level security policy, obtain awareness point operation information. Specifically, at the awareness point, obtain necessary information, such as the values ​​in registers, by collecting the memory state of the current process.

[0079] Furthermore, to address certain vulnerabilities, such as double-free and race conditions, this embodiment requires collecting state information to determine whether the accessed memory has been freed and whether it will be used after being freed. Therefore, this embodiment proposes a counter scheme: initially, a counter is allocated for each memory object that needs to be tracked; when a memory object is allocated, the counter is incremented; when a memory object is freed, the counter is decremented; when a memory object is accessed, the value of the counter is checked to ensure that the memory object is in a valid state.

[0080] Taking Table 2 above as an example, the counter is incremented by one at the first sensing point (at this time the counter flag is 10, the memory object is allocated, and the counter is incremented by one), and decremented by one at the second sensing point (at this time the counter flag is 01, the memory object is released, and the counter is decremented by one).

[0081] Next, based on the decision point information in the binary-level security policy, the decision point operation information is obtained. Specifically, in this embodiment, a decision point is inserted before the vulnerability trigger point, and the values ​​that need to be collected, such as the value of the target register, are collected at the decision point.

[0082] Then, based on the operational information of the perception points and the operational information of the decision points, potential attacks in the currently running program are detected. Specifically, this includes: obtaining the general strategies corresponding to the vulnerabilities in the currently running program; generating target constraints based on the general strategies; determining that there are no potential attacks in the currently running program if the operational information of the perception points and the operational information of the decision points meet the target constraints; and determining that there are potential attacks in the currently running program if the operational information of the perception points and the operational information of the decision points do not meet the target constraints.

[0083] The target constraints are generated based on the general strategy for the current vulnerability type. The target constraints are used to check the relationship between the value of the target register and the target memory object in order to determine whether the currently running program has abnormal behavior.

[0084] Still taking the content in Table 2 above as an example, based on the value of the target register ptr collected at the decision point, combined with the value of the register buf collected at the sensing point, and the value of the recorded counter counter, it is determined whether the target constraint conditions are met, that is, "(ptr >= buf) && (ptr < buf + 21848) && (counter == 0)". In Table 2, the running information at the sensing point and the running information at the decision point do not meet the target constraint conditions, which indicates that there is an abnormal behavior in the current running program, that is, there is a potential attack behavior. In this case, the target operation is executed, that is, the process is killed.

[0085] After detecting the potential attack existing in the current running program, the target operation is executed, which specifically includes: suspending the current running program; or, interrupting the current running program; or, issuing a warning for the current running program; or, returning an error code for the current running program to avoid the triggering of vulnerabilities.

[0086] Specifically, according to the different situations of the current running program, the target operations adopted are different. For a normal program, the target operations selected in this embodiment are killing the process or suspending the process; for a service program or kernel with a complete error code handling mechanism, they often need to ensure the normal operation of the program. Therefore, for this situation, in this embodiment, the decision point is set to the function entry or return point, and its error code handling mechanism is used to ensure the normal operation of the current running program.

[0087] It should be noted that different from the prior art Talos, in this embodiment, only an error code is returned when a potential attack is detected, which will not affect the function of the target function. In addition, for these two situations, this embodiment also provides an option to issue a warning, and it can be selected whether to enable it.

[0088] In this embodiment, by obtaining the general policy corresponding to the vulnerability existing in the current running program, and generating target constraint conditions according to the general policy, when the running information at the sensing point and the running information at the decision point meet the target constraint conditions, it is determined that there is no potential attack in the current running program. When the running information at the sensing point and the running information at the decision point do not meet the target constraint conditions, it is determined that there is a potential attack in the current running program, and then the target operation is executed to timely shield the vulnerability and ensure the normal operation of the current running program. This method can automatically generate binary-level security policies and execute them based on the dynamic vulnerability detection mechanism, and can provide effective protection measures for active programs and kernels with vulnerabilities before the vulnerabilities are repaired, and this process does not require developers to have professional security knowledge or spend a lot of time on manual analysis.

[0089] Based on the above embodiments, the method further includes: signing the binary-level security policy after obtaining it, and verifying the signature of the binary-level security policy before executing the policy.

[0090] Understandably, to prevent attackers from forging or tampering with security policies, this embodiment introduces a signature verification mechanism. Once a binary-level security policy is generated, the developer signs the generated binary-level security policy. Then, the policy forwarder distributes the binary-level security policy to the policy implementer in the kernel of each target device. Before executing the policy, the policy implementer verifies the binary-level security policy to ensure that the policy to be executed is the one signed by the developer. After successful verification, the specific information is extracted and the policy is executed.

[0091] In some other embodiments, Figure 2 The diagram illustrates the overall process of the policy-based dynamic vulnerability masking method provided in this embodiment of the invention.

[0092] like Figure 2 As shown, in order to quickly generate and effectively use the binary-level security policy of this embodiment, the overall framework of this invention consists of three parts: a policy generator, a policy forwarder, and a policy implementer. The policy implementer includes four major modules: signature verification, perception, decision-making, and execution.

[0093] It's easy to understand that the vendor's (i.e., the developer's) server deploys a policy generator capable of generating specific security policies. Specifically, the policy generator can analyze vulnerability reports from dynamic vulnerability detection mechanisms (such as ASN) and automatically generate binary-level security policies. Furthermore, the policy generator can also automatically generate binary-level security policies using source-code-level security policies provided by the developers. The policy generator effectively reduces the time cost for developers to analyze vulnerabilities and the difficulty of using the policy-based dynamic vulnerability masking method provided by this invention.

[0094] After the binary-level security policy is generated, it is signed by the developer and distributed to the target device. Then, the policy forwarder forwards the binary-level security policy to the policy enforcer in the kernel of the target device.

[0095] Before executing the policy, the policy implementer verifies the signature of the binary-level security policy to prevent the policy from being forged by attackers. After successful verification, the specific information is extracted and the policy is executed.

[0096] The policy enforcer is a module running in the target device kernel. Its functions include verifying security policies, collecting and detecting runtime information of currently running programs, and executing specific security policies. The policy enforcer executes a policy only if and only if the binary-level security policy has been verified successfully. Before the vulnerability trigger point, the policy enforcer performs checks against the binary-level security policy.

[0097] If all checks pass, the policy enforcer will not interfere with the normal execution of the currently running program. When the security policy enforcer detects abnormal behavior in the target process (the currently running program) or the kernel, it will perform specific actions (target operations) according to the binary-level security policy provided by the developer, such as interrupting, pausing, issuing warnings, or preventing the execution of vulnerable code.

[0098] Compared to existing solutions, this invention eliminates the need for developers to perform detailed analysis of the target binary file. Developers simply provide the vulnerability report from the dynamic vulnerability detection mechanism as input to the policy generator, which then generates an automatically generated binary-level security policy. Thus, this invention provides effective security for applications without requiring developers to possess specialized security knowledge or spend significant time on manual analysis.

[0099] Furthermore, compared to existing hot-patching solutions, this invention does not require code injection to achieve vulnerability mitigation. Each operation of this invention is based on binary-level security policies, which serve as inputs to the various functionalities of the policy enforcer. The policy enforcer includes functions such as information gathering, arithmetic and logical computation, and execution of specific actions.

[0100] Information gathering refers to collecting runtime information of the process before the vulnerability detection point to help determine whether potential vulnerabilities exist. For vulnerabilities such as heap overflows, when the program executes to a specific binary address, this invention can obtain necessary information by collecting the memory state of the current process. For example, it can collect information such as the heap pointer value and heap size. Simultaneously, it can also collect register values ​​to determine the context information of the current execution point. This information can help this invention make effective decisions to prevent potential attacks.

[0101] Previous research has shown that security patch changes are typically small, involving only a few variables, and the detection logic can be represented by constraints. These constraints usually consist of variables, constants, operators, logical judgments, and a small number of whitelisted function calls. Most vulnerability-related detection logic can be represented by such constraints, such as buffer overflows, out-of-bounds access, division by zero, null pointer dereferences, integer overflows, and some logical vulnerabilities. Therefore, when performing anomalous behavior detection, arithmetic and logical calculations by the policy enforcer can be used.

[0102] For example, in detecting buffer overflows, this invention checks the relationship between the target register value and the target memory object before the vulnerability trigger point. If the boundary of the target memory object is crossed, the current program execution is considered abnormal. When an abnormality is determined in the current program execution, the policy enforcer executes the target operation selected by the user in the binary-level security policy, such as interrupting or suspending program execution, or issuing a warning.

[0103] It should also be noted that the policy-based dynamic vulnerability shielding method provided by this invention can provide effective protection for active programs and kernels with vulnerabilities before the vulnerabilities are patched. In addition, this invention has minimal impact on performance and good compatibility with various mainstream computer platforms and devices.

[0104] Corresponding to the policy-based dynamic vulnerability masking method described in the above embodiments, the present invention also provides a policy-based dynamic vulnerability masking device. Specifically, Figure 3 A schematic diagram of the structure of the policy-based dynamic vulnerability shielding device provided in an embodiment of the present invention is shown.

[0105] like Figure 3 As shown, the device includes: a policy generation module 310, used to obtain a binary-level security policy based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; and a policy implementation module 320, used to detect potential attacks in the currently running program based on the binary-level security policy, and perform target operations to promptly block vulnerabilities and ensure the normal operation of the currently running program.

[0106] In this embodiment, the policy generation module 310 obtains a binary-level security policy based on a dynamic vulnerability detection mechanism. This binary-level security policy includes information related to awareness points, decision points, constraints, and execution units. The policy implementation module 320 then uses this binary-level security policy to detect potential attacks in the currently running program and executes target operations to promptly block vulnerabilities and ensure the normal operation of the program. This device automatically generates and executes binary-level security policies based on a dynamic vulnerability detection mechanism, providing effective protection for active programs and kernels with vulnerabilities before they are patched. This process does not require developers to possess specialized security knowledge or spend significant time on manual analysis.

[0107] It should be noted that the policy-based dynamic vulnerability masking device provided in this embodiment can be referred to in correspondence with the policy-based dynamic vulnerability masking methods described in the above embodiments, and will not be repeated here.

[0108] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a policy-based dynamic vulnerability masking method. This method includes: acquiring a binary-level security policy based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; and based on the binary-level security policy, detecting potential attacks in the currently running program and performing target operations to mask vulnerabilities in a timely manner, ensuring the normal operation of the currently running program.

[0109] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0110] On the other hand, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the policy-based dynamic vulnerability masking method provided by the above methods. The method includes: obtaining a binary-level security policy based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; and detecting potential attacks in the currently running program based on the binary-level security policy, and performing target operations to mask vulnerabilities in a timely manner, thereby ensuring the normal operation of the currently running program.

[0111] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A policy-based dynamic vulnerability masking method, characterized in that, include: Based on a dynamic vulnerability detection mechanism, a binary-level security policy is obtained, including: when a vulnerability is detected in the currently running program and has not yet been disclosed, obtaining vulnerability report information according to the dynamic vulnerability detection mechanism; analyzing the vulnerability report information to obtain vulnerability information; generating a source code-level security policy based on the vulnerability information and a general policy for the current vulnerability; and converting the source code-level security policy into the binary-level security policy based on the debugging information and binary files of the currently running program; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; Based on the binary-level security policy, potential attacks in the currently running program are detected, and target operations are executed to promptly block vulnerabilities and ensure the normal operation of the currently running program; the target operations are determined based on the execution unit information. The process of obtaining the binary-level security policy then includes: The binary-level security policy is signed, and the signature of the binary-level security policy is verified before the policy is executed.

2. The policy-based dynamic vulnerability masking method according to claim 1, characterized in that, The detection of potential attacks in the currently running program based on the binary-level security policy includes: Based on the perception point-related information in the binary-level security policy, the perception point operation information is obtained; the perception point operation information includes the memory state of the currently running program, the value of the registers, and the usage of the counter. Based on the decision point information in the binary-level security policy, obtain the decision point operation information, which includes the memory state and register values ​​of the currently running program; Based on the operational information of the sensing points and the operational information of the decision points, potential attacks in the currently running program are detected.

3. The policy-based dynamic vulnerability masking method according to claim 2, characterized in that, The step of detecting potential attacks in the currently running program based on the operational information of the sensing points and the operational information of the decision points includes: Obtain the general strategies corresponding to the vulnerabilities present in the currently running program; Based on the general strategy, generate the target constraints; If the operating information of the sensing point and the operating information of the decision point satisfy the target constraint conditions, it is determined that there is no potential attack in the current running program; If the operating information of the sensing point and the operating information of the decision point do not meet the target constraints, it is determined that there is a potential attack in the current running program.

4. The policy-based dynamic vulnerability masking method according to claim 1, characterized in that, The vulnerability information includes the vulnerability type, the name, path, and line number of the vulnerability source file, the name of the memory object, the size of the memory object, the memory object allocation point, and the memory object release point.

5. The policy-based dynamic vulnerability masking method according to any one of claims 1-4, characterized in that, The steps for performing the target operation specifically include: Suspend the currently running program; Alternatively, interrupt the currently running program; Alternatively, issue a warning for the currently running program; Alternatively, return an error code for the currently running program.

6. A policy-based dynamic vulnerability shielding device, characterized in that, include: The policy generation module is used to obtain binary-level security policies based on a dynamic vulnerability detection mechanism, including: when a vulnerability is detected in the currently running program and has not yet been disclosed, obtaining vulnerability report information according to the dynamic vulnerability detection mechanism; analyzing the vulnerability report information to obtain vulnerability information; generating a source code-level security policy based on the vulnerability information and a general policy for the current vulnerability; and converting the source code-level security policy into the binary-level security policy based on the debugging information and binary files of the currently running program; wherein the binary-level security policy includes perception point-related information, decision point-related information, constraint information, and execution unit information; The policy implementation module is used to detect potential attacks in the currently running program based on the binary-level security policy, and to perform target operations to block vulnerabilities in a timely manner and ensure the normal operation of the currently running program. The process of obtaining the binary-level security policy then includes: The binary-level security policy is signed, and the signature of the binary-level security policy is verified before the policy is executed.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the policy-based dynamic vulnerability masking method as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the policy-based dynamic vulnerability masking method as described in any one of claims 1 to 5.

Images