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

Abstract

The invention provides a dynamic vulnerability shielding method and device based on a strategy and electronic equipment, and the method comprises the steps: obtaining a binary-level security strategy based on a dynamic vulnerability detection mechanism; wherein the binary level security policy comprises sensing point related information, decision point related information, constraint information and execution unit information; and detecting potential attacks existing in the current running program based on the binary level security policy, and executing the target operation to shield vulnerabilities in time and ensure normal running of the current running program. According to the method, a binary-level security policy is automatically generated and executed based on a dynamic vulnerability detection mechanism, effective protection measures can be provided for active programs and kernels with vulnerabilities before the vulnerabilities are repaired, and developers do not need to have professional security knowledge or spend a large amount of time for manual analysis in the process.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a policy-based dynamic vulnerability shielding method, device and electronic equipment. Background Art

[0002] Securing computer systems and software has always been a major challenge. Every year, white hat hackers can discover a large number of security vulnerabilities in released computer systems or software. Although most vulnerabilities are fixed before disclosure, there are still many vulnerabilities that are not patched after being disclosed.

[0003] Unfortunately, patching vulnerabilities usually takes a long time. Developers must conduct a comprehensive analysis of the programs affected by the vulnerabilities, find out the root causes of the vulnerabilities, and develop patches to address these problems. The time between discovering the vulnerability and actually deploying the patch leaves malicious attackers with opportunities to exploit the vulnerability. Therefore, an effective and timely vulnerability shielding mechanism that can temporarily prevent the exploitation of the vulnerability will greatly reduce 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 shielding or temporary vulnerability repair solutions.

[0005] Some of these solutions use code injection to dynamically update the vulnerable code, but this method has security risks and may cause unexpected program behavior or introduce new vulnerabilities. In contrast, the extended Berkeley Packet Filter (eBPF) is a kernel technology that allows sandboxed programs to run in the Linux kernel, allowing developers to run specific functions without modifying the kernel code. Some solutions use eBPF for vulnerability detection. Although these eBPF-based solutions cannot easily modify program execution, they still have the ability to write to memory, which is dangerous and may cause unexpected behavior.

[0006] Some other solutions use other methods, such as returning error codes or using a combination of rules and hardware breakpoints to detect vulnerability exploits. However, these solutions require instrumenting the target program or reloading additional libraries, so they cannot provide protection for already running processes or kernels. In addition, these methods are only applicable to some attack scenarios and may affect the functionality of the program, which has great limitations.

[0007] For example, Talos exploits the inherent error handling mechanism of the program to insert a return instruction with an appropriate error code at the entry of the vulnerable function, but this method relies on the error code handling mechanism of the program and does not perform input checking. Therefore, even if there is no exploit, 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 functionality of the program. InstaGuard requires loading additional libraries and relies on hardware breakpoints. In addition, due to the design limitations of the solution, the types of vulnerabilities that the solution can support are relatively limited. For example, it cannot effectively detect and block the exploitation of memory corruption vulnerabilities such as double release and complex use after release.

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

[0009] The present invention provides a policy-based dynamic vulnerability shielding method, device and electronic device, which are used to overcome the defect that the existing vulnerability shielding scheme cannot provide effective security protection for the running program and kernel, provide security protection for the running program and kernel and cope with various attack scenarios.

[0010] On the one hand, the present invention provides a policy-based dynamic vulnerability shielding method, including: based on a dynamic vulnerability detection mechanism, obtaining a 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; based on the binary-level security policy, detecting potential attacks in a currently running program, and executing target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0011] Furthermore, the binary-level security policy is obtained based on the dynamic vulnerability detection mechanism, including: when it is detected that the currently running program has a vulnerability that has not 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 according to 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 according to the debugging information and binary file of the currently running program.

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

[0013] Furthermore, detecting potential attacks existing in the currently running program based on the perception point operation information and the decision point operation information includes: obtaining a general policy corresponding to the vulnerability existing in the currently running program; generating a target constraint condition based on the general policy; determining that there is no potential attack in the currently running program when the perception point operation information and the decision point operation information satisfy the target constraint condition; and determining that there is a potential attack in the currently running program when the perception point operation information and the decision point operation information do not satisfy the target constraint condition.

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

[0015] Furthermore, the step of executing the target operation specifically includes: 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] Further, the obtaining of the binary level security policy then includes: signing the binary level security policy, and verifying the signature of the binary level security policy before executing the policy.

[0017] In the second aspect, the present invention also provides a policy-based dynamic vulnerability shielding device, including: 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; a policy implementation module, used to detect potential attacks in a currently running program based on the binary-level security policy, and execute target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0018] In a third aspect, the present invention further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the policy-based dynamic vulnerability shielding method as described above is implemented.

[0019] In a fourth aspect, the present invention further 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 shielding method as described in any one of the above.

[0020] The policy-based dynamic vulnerability shielding method provided by the present invention obtains 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 then detects potential attacks in the currently running program based on the binary-level security policy, and executes the target operation to timely shield the vulnerability and ensure the normal operation of the currently running program. The method automatically generates and executes a binary-level security policy based on a 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0022] Figure 1 It is a flow chart of a policy-based dynamic vulnerability shielding method provided by an embodiment of the present invention.

[0023] Figure 2 It is a schematic diagram of the overall process of the policy-based dynamic vulnerability shielding method provided by an embodiment of the present invention.

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

[0025] Figure 4 It is a schematic diagram of the physical structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0027] It should be noted that patching vulnerabilities usually takes a long time. Developers must conduct a comprehensive analysis of the programs affected by the vulnerabilities, find out the root causes of the vulnerabilities, and develop patches to resolve these problems. However, the time between discovering the vulnerability and actually deploying the patch leaves malicious attackers with the opportunity to exploit the vulnerability.

[0028] In this regard, the prior art has proposed many solutions for vulnerability shielding or timely repair of vulnerabilities, but these solutions cannot effectively detect various vulnerabilities, nor can they provide effective security protection for running programs and kernels.

[0029] In view of this, the present invention proposes a policy-based dynamic vulnerability shielding method, specifically, Figure 1 A schematic flow chart of a policy-based dynamic vulnerability shielding method provided in an embodiment of the present invention is shown.

[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, obtaining a 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] It is understandable that 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 dynamic vulnerability detection mechanism from the supplier. 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 (the 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 policies to deal with different attack scenarios, namely, binary-level security policies, can be generated.

[0035] Among them, the dynamic vulnerability detection mechanism is a method of checking for security vulnerabilities while the software is running, which usually involves real-time monitoring of the program's behavior to identify potential security issues. Unlike static analysis, dynamic analysis is performed during the execution of the software, which enables it to capture some problems that only appear at runtime.

[0036] Dynamic vulnerability detection mechanisms include but are not limited to fuzz testing, dynamic application security testing, memory error detection, interactive application security testing, runtime application self-protection, monitoring and logging, penetration testing, etc., which are crucial to improving software security, especially in complex production environments, so that vulnerabilities can be discovered and fixed in a timely manner, reducing the risk of attacks.

[0037] The binary level security policy includes, but is not limited to, information related to perception points, information related to decision points, constraint information, and execution unit information.

[0038] Regarding the information related to the sensing point, the information related to the sensing point is used to describe what necessary runtime information needs to be collected at what address. Among them, the sensing point refers to the location used to collect runtime status data during program execution. The information related to the sensing point includes counter usage, register status, memory access information, etc.

[0039] Regarding decision point related information, decision point related information is used to describe what security checks need to be performed at what locations using arithmetic constraints. Among them, decision points are the locations in the program where security decisions are made based on the information collected by the perception points. The decision point related information is the same as the perception point related information above, but there is no counter flag and corresponding value setting.

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

[0041] Regarding the execution unit information, the execution unit information is used to describe the execution unit to be executed, and the 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 implemented by a policy generator deployed on the supplier'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 the binary-level security policy is verified before executing the policy to ensure that the executed policy is the binary-level security policy signed as above.

[0044] S120, based on the binary level security policy, detecting potential attacks in the currently running program, and executing target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0045] It can be understood that, based on the acquisition of the binary level security policy based on the dynamic vulnerability detection mechanism in step S110, further, step S120 will execute the binary level security policy.

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

[0047] That is to say, the perception point operation information is obtained at the perception point, the decision point operation information is obtained at the decision point, and it is judged whether the perception point operation information and the decision point operation information meet the target constraint conditions. If the target constraint conditions are met, it means that there is no potential attack in the current running program; otherwise, it means that there is a potential attack in the current running program and the target operation needs to be taken.

[0048] Among them, the target operation can be determined based on the execution unit information in the binary level security policy, such as interruption, suspension, warning or avoiding running vulnerable code.

[0049] It should be noted that when the perception point operation information and the decision point operation information meet the target constraint conditions, the target operation also needs to be executed, but the target operation at this time is to continue running the current 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, and the target device can be any smart device.

[0051] In this embodiment, a binary-level security policy is obtained based on a dynamic vulnerability detection mechanism; wherein the binary-level security policy includes information related to perception points, information related to decision points, constraint information, and execution unit information, and then based on the binary-level security policy, potential attacks in the currently running program are detected, and target operations are performed to timely shield 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, and can provide effective protection measures for active programs and kernels with vulnerabilities before the vulnerabilities are fixed, and this process does not require developers to have professional security knowledge or spend a lot of time on manual analysis.

[0052] On the basis of the above-mentioned embodiment, the process of obtaining the binary level security policy will be described in detail below.

[0053] When it is detected that a vulnerability exists in the currently running program and 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; a source code level security policy is generated according to the vulnerability information and the general policy for the current vulnerability; and the source code level security policy is converted into a binary level security policy according to the debugging information and binary files of the currently running program.

[0054] It is understandable that when it is detected that there is at least one vulnerability in the currently running program and it has not been disclosed, security developers and maintainers can obtain vulnerability report information through the dynamic vulnerability detection mechanism. The vulnerability report information includes but is not limited to the vulnerability type and the call stack information of the detection point.

[0055] Among them, vulnerability types include but are not limited to injection attacks, cross-site scripting, cross-site request forgery, buffer overflow, information leakage, configuration errors, etc.

[0056] The call stack information of the detection point refers to the function call history at a specific moment in the program execution process, which shows how the current execution position is reached through a series of function calls. The call stack information of the detection point includes but is not limited to the function name, file name, line number, 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 ASan 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 release point.

[0058] Furthermore, by analyzing the vulnerability report information, we can understand the nature of the vulnerability and the information when the vulnerability is detected, that is, the vulnerability information. The vulnerability information includes the vulnerability type (such as buffer overflow, null pointer dereference, etc.), as well as the source code line number and function call information of the detection point obtained by analyzing the call stack information.

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

[0060] Table 1

[0061] According to Table 1 above, the analyzed vulnerability information includes vulnerability type, name of vulnerability source file and its path and specific line number, memory object name, memory object size, memory object allocation point and memory object release point.

[0062] Next, based on the vulnerability information extracted from the analysis and the general strategy of the current vulnerability type, a source code level security policy can be generated.

[0063] Among them, the general strategy of the current vulnerability type refers to a series of general prevention and repair measures taken for specific types of vulnerabilities. For example, the general strategy for SQL injection includes parameterized queries (using precompiled statements or parameterized queries to prevent SQL injection), input validation (strictly validate and sanitize all user input), and the principle of least privilege (using the database account with the least privilege to connect).

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

[0065] Table 2

[0066] According to Table 2 above, the binary level security policy includes perception point related information, decision point related information, constraint information and execution unit information.

[0067] Regarding the information related to the perception point, the information related to the perception point can be represented by registers and constants (the combination of registers and constants is sufficient to represent the value in the memory or the value of the 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 perception point also includes a 2-bit flag to indicate the usage of the counter. The usage of the counter includes not using the counter (00), decrementing the counter (01), and incrementing the counter (10). The corresponding values ​​represent the specific values ​​of the counter increase or decrease.

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

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

[0070] Regarding the execution unit, the execution unit includes operations such as suspending the program, interrupting the program, issuing a warning, or returning an error code. These operations are selected when potential vulnerabilities are found and need to be blocked.

[0071] With the above, binary-level security policies can be obtained based on the dynamic vulnerability detection mechanism.

[0072] In this embodiment, when it is detected that the current running program has a vulnerability and has not been disclosed, the vulnerability report information is obtained according to the dynamic vulnerability detection mechanism, and the vulnerability report information is analyzed to obtain the vulnerability information, and then the source code level security policy is generated according to the vulnerability information and the general policy for the current vulnerability, and the source code level security policy is converted into a binary level security policy according to the debugging information and binary file of the current running program, so that the potential attack in the current running program is detected based on the binary level security policy, and the target operation is performed to timely shield the vulnerability and ensure the normal operation of the current running program. The method can provide effective protection measures for active programs and kernels with vulnerabilities before the vulnerabilities are fixed by automatically generating and executing binary level security policies based on the dynamic vulnerability detection mechanism, and this process does not require developers to have professional security knowledge or spend a lot of time on manual analysis.

[0073] On the basis of the above-mentioned embodiment, the process of performing vulnerability shielding based on binary-level security policy will be described in detail below.

[0074] Based on the binary level security policy, potential attacks existing in the currently running program are detected, including: obtaining perception point operation information according to the perception point related information in the binary level security policy; the perception point operation information includes the memory status, register values ​​and counter usage of the currently running program; obtaining decision point operation information according to the decision point related information in the binary level security policy, the decision point operation information includes the memory status and register values ​​of the currently running program; based on the perception point operation information and the decision point operation information, potential attacks existing in the currently running program are detected.

[0075] It is understandable that some vulnerabilities can be judged by the runtime information of the decision point to determine whether there is a potential attack, such as null pointer dereference, division by zero, etc. However, some vulnerabilities are more complex and require a combination of multiple runtime information to make an effective judgment, such as heap overflow, use after free, and conditional competition. For this type of vulnerability, it is necessary to collect the runtime information of the process before the decision point of this embodiment, that is, to collect the necessary runtime information at the perception point, that is, the perception point running information.

[0076] According to the perception point related information in the binary level security policy, the perception point operation information is obtained. Specifically, at the perception point, the necessary information, such as the value in the register, is obtained by collecting the memory status of the current process.

[0077] In addition, for certain vulnerabilities such as double free and race condition, this embodiment needs to collect status 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 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.

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

[0079] Next, according to the decision point related information in the binary-level security policy, the decision point running information is obtained. Specifically, this embodiment will insert a decision point before the vulnerability trigger point and collect the values to be collected at the decision point, such as the value of the target register.

[0080] Then, based on the sensing point running information and the decision point running information, potential attacks existing in the currently running program are detected, specifically including: obtaining the general policy corresponding to the vulnerability existing in the currently running program; generating target constraint conditions according to the general policy; determining that there is no potential attack in the currently running program when the sensing point running information and the decision point running information meet the target constraint conditions; and determining that there is a potential attack in the currently running program when the sensing point running information and the decision point running information do not meet the target constraint conditions.

[0081] Among them, the target constraint conditions are generated according to the general policy of the current vulnerability type, and the target constraint conditions are used to check the relationship between the value of the target register and the target memory object to determine whether there is abnormal behavior in the currently running program.

[0082] Still taking the content in Table 2 above as an example, according to 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 judged whether the target constraint conditions are met, that is, "(ptr >= buf) && (ptr < buf + 21848) && (counter == 0)". In Table 2, the sensing point running information and the decision point running information do not meet the target constraint conditions, which indicates that there is abnormal behavior in the currently running program, that is, there is a potential attack behavior. In this case, the target operation is executed, that is, the process is killed.

[0083] After detecting a potential attack in the currently running program, a target operation is performed, including: 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 to the currently running program to avoid triggering a vulnerability.

[0084] Specifically, the target operation used is different according to the different situations of the currently running program. For normal programs, the target operation selected by this embodiment is to kill the process or suspend the process; for service programs or kernels with a complete error code processing mechanism, they often need to ensure the normal operation of the program. Therefore, for this situation, this embodiment sets the decision point to the function entry or return point, and uses its error code processing mechanism to ensure the normal operation of the currently running program.

[0085] It should be noted that, unlike the prior art Talos, this embodiment only returns an error code 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, which can be turned on or off.

[0086] In this embodiment, by obtaining the general policy corresponding to the vulnerability in the currently running program, and generating the target constraint condition according to the general policy, when the perception point operation information and the decision point operation information meet the target constraint condition, it is determined that there is no potential attack in the currently running program, and when the perception point operation information and the decision point operation information do not meet the target constraint condition, it is determined that there is a potential attack in the currently running program, and then the target operation is performed to timely shield the vulnerability 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, which can provide effective protection measures for active programs and kernels with vulnerabilities before the vulnerabilities are fixed, and this process does not require developers to have professional security knowledge or spend a lot of time on manual analysis.

[0087] Based on the above embodiment, further, it also includes: after obtaining the binary level security policy, signing the binary level security policy, and verifying the signature of the binary level security policy before executing the policy.

[0088] It is understandable that in order to prevent attackers from forging or tampering with security policies, this embodiment introduces a signature verification mechanism. Once the binary-level security policy is generated, the developer will sign the generated binary-level security policy, and then distribute the binary-level security policy to the policy implementer in the kernel of each target device through the policy forwarder. Before executing the policy, the policy implementer will verify the binary-level security policy to ensure that the policy to be executed is the one signed by the developer. After the verification is passed, the specific information will be extracted and the policy will be executed.

[0089] In some other embodiments, Figure 2 The figure shows the overall process diagram of the policy-based dynamic vulnerability shielding method provided by the embodiment of the present invention.

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

[0091] It is easy to understand that a policy generator is deployed on the server of the supplier (ie, the developer) to generate specific security policies. Specifically, the policy generator can analyze vulnerability reports of dynamic vulnerability detection mechanisms (such as ASan) and automatically generate binary-level security policies. In addition, the policy generator can also automatically generate binary-level security policies using source-level security policies provided by developers. The policy generator effectively reduces the time cost of developers to analyze vulnerabilities and the difficulty of using the policy-based dynamic vulnerability shielding method provided by the present invention.

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

[0093] Before executing the policy, the policy enforcer verifies the signature of the binary-level security policy to prevent the policy from being forged by an attacker. After the verification is passed, the specific information is extracted and the policy is executed.

[0094] The policy enforcer is a module running in the kernel of the target device. Its functions include verifying security policies, collecting and detecting runtime information of currently running programs, and executing specific security policies. The policy enforcer will execute the policy only if and when the binary-level security policy is verified. Before the vulnerability is triggered, the policy enforcer will check according to the binary-level security policy.

[0095] 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 of the target process (currently running program) or the kernel, it will perform specific actions (target operations) based on the binary-level security policy provided by the developer, such as interruption, suspension, warning, or avoiding the execution of vulnerable code.

[0096] Compared with the existing solutions, the present invention does not require developers to perform specific analysis on the target binary file. Developers only need to provide the vulnerability report of the dynamic vulnerability detection mechanism as input to the policy generator, and then obtain the automatically generated binary level security policy. In this way, the present invention can provide effective security protection for the application without requiring developers to have professional security knowledge or spend a lot of time on manual analysis.

[0097] In addition, compared with the existing hot patching solutions, the present invention does not need to implement vulnerability shielding through code injection. Each operation of the present invention is based on binary level security policies, which are used as inputs to various functional functions of the policy implementer. The policy implementer includes functions such as information collection, arithmetic and logical calculations, and specific action execution.

[0098] Among them, information collection refers to collecting the runtime information of the process before the vulnerability detection point to assist in determining whether there is a potential vulnerability. For vulnerabilities such as heap overflow, when the program executes to a specific binary address, the present invention can obtain necessary information by collecting the memory state of the current process. For example, the value of the heap pointer, the heap size and other information can be collected. At the same time, the value of the register can also be collected to determine the context information of the current execution point. This information can help the present invention make effective decisions to prevent potential attacks.

[0099] Previous research has shown that security patches usually have small changes, involving only a small number of variables, and the detection logic can be expressed using constraints. These constraints usually consist of variables, constants, operators, logical judgments, and a small number of whitelist function calls. The detection logic caused by most vulnerabilities can be expressed using such constraints, such as buffer overflows, out-of-bounds access, division by zero, null pointer dereference, integer overflow, and some logical vulnerabilities. Therefore, when performing abnormal behavior detection, the arithmetic and logical calculations of the policy enforcer can be used for detection.

[0100] For example, in the case of detecting a buffer overflow, the present invention will check the relationship between the value of the target register and the target memory object before the vulnerability trigger point. If the boundary of the target memory object is crossed, it is considered that the current program execution is abnormal. When it is determined that the current program execution is abnormal, the policy enforcer will execute the target operation selected by the user in the binary level security policy, such as the execution of the program will be interrupted or suspended, or a warning will be issued.

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

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

[0103] like Figure 3 As shown, the device includes: a policy generation module 310, which is 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; a policy implementation module 320, which is used to detect potential attacks in the currently running program based on the binary-level security policy, and execute target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0104] In this embodiment, the binary-level security policy is obtained by the policy generation module 310 based on the 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 then the policy implementation module 320 detects potential attacks in the currently running program based on the binary-level security policy, and executes the target operation to timely shield the vulnerability and ensure the normal operation of the currently running program. The device automatically generates and executes the binary-level security policy based on the dynamic vulnerability detection mechanism, which can provide effective protection measures for active programs and kernels with vulnerabilities before the vulnerabilities are fixed, and this process does not require developers to have professional security knowledge or spend a lot of time on manual analysis.

[0105] It should be noted that the policy-based dynamic vulnerability shielding device provided in this embodiment and the policy-based dynamic vulnerability shielding method described in the above embodiments can be referenced to each other, and will not be described in detail here.

[0106] Figure 4 An example of a physical structure diagram of an electronic device is shown in FIG. Figure 4As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430 and a communication bus 440, wherein the processor 410, the communications interface 420 and the memory 430 communicate with each other through the communication bus 440. The processor 410 may call the logic instructions in the memory 430 to execute a policy-based dynamic vulnerability shielding method, the 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; based on the binary-level security policy, detecting potential attacks in the currently running program, and executing target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0107] In addition, the logic instructions in the above-mentioned memory 430 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0108] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it is implemented to execute the policy-based dynamic vulnerability shielding method provided by the above-mentioned methods. The method includes: based on a dynamic vulnerability detection mechanism, obtaining a 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; based on the binary-level security policy, detecting potential attacks in the currently running program, and executing target operations to timely shield vulnerabilities and ensure the normal operation of the currently running program.

[0109] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0110] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0111] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A policy-based dynamic vulnerability shielding method, characterized in that: include: Based on the dynamic vulnerability detection mechanism, a binary level security policy is obtained; 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 performed to shield vulnerabilities in a timely manner to ensure the normal operation of the currently running program.

2. The policy-based dynamic vulnerability shielding method according to claim 1 is characterized in that: The binary level security policy is obtained based on the dynamic vulnerability detection mechanism, including: When it is detected that the currently running program has a vulnerability that has not yet been disclosed, obtaining vulnerability report information according to the dynamic vulnerability detection mechanism; Analyze the vulnerability report information to obtain vulnerability information; Generate a source code level security policy based on the vulnerability information and a common policy for the current vulnerability; The source code level security policy is converted into the binary level security policy according to the debugging information and the binary file of the currently running program.

3. The policy-based dynamic vulnerability shielding method according to claim 1 is characterized in that: The detecting potential attacks existing in the currently running program based on the binary level security policy includes: According to the sensing point related information in the binary level security policy, the sensing point operation information is obtained; the sensing point operation information includes the memory status of the currently running program, the value of the register and the usage of the counter; According to the decision point related information in the binary level security policy, obtaining the decision point operation information, wherein the decision point operation information includes the memory state and register value of the currently running program; According to the perception point operation information and the decision point operation information, potential attacks existing in the currently running program are detected.

4. The policy-based dynamic vulnerability shielding method according to claim 1 is characterized in that: The detecting potential attacks existing in the currently running program according to the perception point running information and the decision point running information includes: Obtaining a general strategy corresponding to a vulnerability existing in the currently running program; generating target constraints according to the general strategy; In the case where the sensing point operation information and the decision point operation information satisfy the target constraint condition, determining that there is no potential attack in the current running program; When the perception point operation information and the decision point operation information do not satisfy the target constraint condition, it is determined that there is a potential attack in the currently running program.

5. The policy-based dynamic vulnerability shielding method according to claim 2 is characterized in that: The vulnerability information includes the vulnerability type, the name and path of the vulnerability source file and the specific line number, the memory object name, the memory object size, the memory object allocation point and the memory object release point.

6. The policy-based dynamic vulnerability shielding method according to any one of claims 1 to 5, characterized in that: The step of performing the target operation specifically includes: Suspending the currently running program; Alternatively, interrupt the currently running program; Alternatively, a warning is issued for the currently running program; Alternatively, an error code is returned for the currently running program.

7. The policy-based dynamic vulnerability shielding method according to any one of claims 1 to 5, characterized in that: The obtaining of 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 executing the policy.

8. A policy-based dynamic vulnerability shielding device, characterized in that: include: 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; The policy implementation module is used to detect potential attacks in the currently running program based on the binary level security policy and perform target operations to timely shield 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: When the processor executes the computer program, the policy-based dynamic vulnerability shielding method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the policy-based dynamic vulnerability shielding method according to any one of claims 1 to 7 is implemented.

Images