Policy-based dynamic vulnerability blocking method and apparatus, and electronic device

Abstract

Provided in the present application are a policy-based dynamic vulnerability blocking method and apparatus, and an electronic device. The method comprises: on the basis of a dynamic vulnerability detection mechanism, acquiring a binary-level security policy, wherein the binary-level security policy comprises sensing-point-related information, decision-point-related information, constraint information and execution unit information; and on the basis of the binary-level security policy, detecting a potential attack present in a currently running program, and executing a target operation, so as to promptly block vulnerabilities and thus ensure the normal operation of the currently running program. In the method, by means of automatically generating, on the basis of a dynamic vulnerability detection mechanism, a binary-level security policy and executing same, effective protective measures can be provided for active programs and kernels having vulnerabilities before the vulnerabilities are patched, and such a process does not require developers to have professional security knowledge nor require spending a large amount of time on manual analysis.

Description

Policy-based dynamic vulnerability masking methods, devices, and electronic equipment

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese patent application No. 2024111940438, filed on August 28, 2024, entitled "Strategy-based Dynamic Vulnerability Shielding Method, Apparatus and Electronic Device", the entirety of which is incorporated herein by reference. Technical Field

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

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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

[0011] This application provides a policy-based dynamic vulnerability shielding method, apparatus, 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.

[0012] On the one hand, this application provides a policy-based dynamic vulnerability shielding method, including: 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; 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, thereby ensuring the normal operation of the currently running program.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] Secondly, this application 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.

[0020] Thirdly, this application 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.

[0021] Fourthly, this application 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.

[0022] The policy-based dynamic vulnerability masking method provided in this application obtains binary-level security policies through a dynamic vulnerability detection mechanism. 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, executes target operations, and promptly masks vulnerabilities, ensuring 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

[0023] To more clearly illustrate the technical solutions in this application 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 application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 is a flowchart illustrating the policy-based dynamic vulnerability masking method provided in an embodiment of this application.

[0025] Figure 2 is a schematic diagram of the overall process of the policy-based dynamic vulnerability masking method provided in the embodiments of this application.

[0026] Figure 3 is a schematic diagram of the structure of the policy-based dynamic vulnerability shielding device provided in the embodiment of this application.

[0027] Figure 4 is a schematic diagram of the physical structure of the electronic device provided in the embodiment of this application. Detailed Implementation

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

[0029] 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.

[0030] 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.

[0031] In view of this, this application proposes a policy-based dynamic vulnerability masking method. Specifically, Figure 1 shows a flowchart of the policy-based dynamic vulnerability masking method provided in the embodiment of this application.

[0032] As shown in Figure 1, the method includes steps S110-S120, and the following will describe steps S110-S120 and related steps in detail.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

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

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] It should be noted that even if the operating information of the sensing point and the operating information of 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.

[0052] 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.

[0053] 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.

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

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] Table 1

[0063] 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.

[0064] 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.

[0065] 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).

[0066] 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.

[0067] Table 2

[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 increments by one at the first sensing point (when the counter flag is 10, the memory object is allocated, and the counter increments by one), and decrements by one at the second sensing point (when the counter flag is 01, the memory object is released, and the counter decrements 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 condition is satisfied, that is, "(ptr >= buf) && (ptr < buf + 21848) && (counter == 0)". In Table 2, the running information of the sensing point and the running information of the decision point do not satisfy the target constraint condition, 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 different situations of the current running program, different target operations are adopted. For a normal program, the target operation selected in this embodiment is to kill the process or suspend 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, an error code is only 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 according to the general policy, the target constraint condition is generated. When the running information of the sensing point and the running information of the decision point satisfy the target constraint condition, it is determined that there is no potential attack in the current running program. When the running information of the sensing point and the running information of the decision point do not satisfy the target constraint condition, 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. Moreover, this process does not require developers to have professional security knowledge or spend a lot of time for 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 shows a schematic diagram of the overall process of the policy-based dynamic vulnerability masking method provided in the embodiments of this application.

[0092] As shown in Figure 2, in order to quickly generate and effectively use the binary-level security policy of this embodiment, the overall framework of this application 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 in this application.

[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 application 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 application 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 application does not require code injection to achieve vulnerability mitigation. Each operation in this application 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 application 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 application 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 application 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 the current program execution is determined to be abnormal, 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 in this application can provide effective protection for active programs and kernels with vulnerabilities before the vulnerabilities are patched. In addition, this application 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, this application also provides a policy-based dynamic vulnerability masking device. Specifically, Figure 3 shows a schematic diagram of the structure of the policy-based dynamic vulnerability masking device provided in the embodiment of this application.

[0105] As shown in Figure 3, 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 illustrates a schematic diagram of the physical structure of an electronic device. As shown in Figure 4, the electronic device may include: a processor 410, a communication interface 420, a memory 430, and a communication bus 440. The processor 410, communication 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: 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; 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 this application, in essence, 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 this application. 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, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program is implemented to perform 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 this application, and are not intended to limit them. Although this application 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. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A policy-based dynamic vulnerability masking method, comprising: Based on a dynamic vulnerability detection mechanism, a binary-level security policy is obtained; wherein, the binary-level security policy includes information related to perception points, information related to decision points, constraint information, and execution unit information; Based on the aforementioned 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.

2. The policy-based dynamic vulnerability masking method according to claim 1, wherein, The binary-level security policy obtained based on the dynamic vulnerability detection mechanism includes: 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. Analyze the vulnerability report information to obtain vulnerability information; Based on the vulnerability information and the general strategies 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 the binary-level security policy.

3. The policy-based dynamic vulnerability masking method according to claim 1, wherein, 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.

4. The policy-based dynamic vulnerability masking method according to claim 1, wherein, 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.

5. The policy-based dynamic vulnerability masking method according to claim 2, wherein, 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.

6. The policy-based dynamic vulnerability masking method according to any one of claims 1-5, wherein, 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.

7. The policy-based dynamic vulnerability masking method according to any one of claims 1-5, wherein, 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.

8. A policy-based dynamic vulnerability shielding device, comprising: The policy generation module is used to obtain binary-level security policies based on a dynamic vulnerability detection mechanism; wherein, the binary-level security policies include 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 promptly block vulnerabilities and ensure the normal operation of the currently running program.

9. An electronic device comprising 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 in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the policy-based dynamic vulnerability masking method as described in any one of claims 1 to 7.

Images