Detailed Description
When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of systems and methods that are consistent with aspects of the application as detailed in the accompanying claims.
In the description of the present application, it should be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. The specific meaning of the above terms in the present application will be understood in specific cases by those of ordinary skill in the art. Furthermore, in the description of the present application, unless otherwise indicated, "a plurality" means two or more. "and/or" describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate that there are three cases of a alone, a and B together, and B alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.
Fig. 1 illustrates a schematic diagram of the internal levels of a terminal. The internal hierarchical structures of the terminal are respectively a hardware layer, a kernel layer, a command analysis layer and a user layer from bottom to top.
Specifically, the hardware layer may include a central processing unit (Central Processing Unit, CPU), a memory, a network card, a disk, and other hardware devices. The kernel layer refers to a piece of system software that provides the functions of hardware abstraction layer, disk and file system control, multitasking, etc., which is a piece of software that provides many applications with secure access to computer hardware, where access is limited, and determines how long a program will operate on a piece of hardware. The method is very complex in directly operating hardware in a hardware layer, so that a set of simple and unified interface is provided between application software and hardware by a kernel layer, and programming is simpler. The command analysis layer is used for analyzing the command input to the terminal by the user and calling a corresponding program in the kernel layer to execute the command input by the user at the terminal. For example, the Shell command interpreter may parse the command into a command that can be recognized by the kernel layer, then the kernel layer executes the command, and finally the terminal displays the result of the command execution to the user. The user layer is used for displaying software operable by a user such as an application program and receiving an operation instruction of the user.
The kernel vulnerability detection method in the related technology firstly carries out kernel vulnerability detection through static features of a kernel layer, but the method is easily bypassed, so that detection is inaccurate and unknown threats cannot be defended, and secondly carries out kernel vulnerability detection through the action of acquiring the control right of an operating system by acquiring the highest right (such as the right of an administrator) of the system through a right raising mode when a hacker is detected to invade the system, and if the hacker does not raise the right when the hacker is invaded to the system, the kernel vulnerability is difficult to detect.
The kernel vulnerability detection method provided by the embodiment of the application is described next with reference to an application scenario diagram of the kernel vulnerability detection system described in fig. 1.
In one embodiment, as shown in fig. 2, a flow diagram of a kernel vulnerability detection method is provided. As shown in fig. 2, the kernel vulnerability detection method may include the following steps:
s201, obtaining information to be detected of a target kernel layer.
The information to be tested can comprise basic information of a target kernel layer, configuration information of the target kernel layer and codes of the target kernel layer.
Specifically, the basic information in the embodiment of the application can comprise kernel version information, release date, manufacturer and the like. The configuration information may include encryption algorithms, rights settings, network configuration, operating environment information, etc. The operating environment may include a hardware environment, other software environments, and the like.
S202, inputting information to be detected of the target kernel layer into a vulnerability risk model to obtain compiling vulnerabilities and operation vulnerabilities of the target kernel layer.
The vulnerability risk model is obtained based on information training of a plurality of kernel layers of known vulnerability risk information, the kernel layer information of the known vulnerability risk information comprises basic information of the kernel layer, configuration information of the kernel layer and codes of the kernel layer, compiling vulnerabilities of a target kernel layer are determined based on the codes of the target kernel layer and the basic information of the target kernel layer, and operation vulnerabilities of the target kernel layer are determined based on the codes of the target kernel layer and the configuration information of the target kernel layer.
The embodiment of the application can acquire the information of the kernel layers with a plurality of known vulnerability risk values, and train a pre-established vulnerability risk initial model based on the information of the kernel layers with the plurality of known vulnerability risk values to obtain a vulnerability risk model. The information of the kernel layer may include basic information and configuration information.
It will be appreciated that different versions of the kernel may correspond to different security features and known version vulnerabilities. The relevant setting of certain configuration information of the kernel layer may lead to the kernel layer being more vulnerable, e.g. unlocking unsafe features or services, an applied patch may fix some vulnerabilities, but new vulnerabilities may also be introduced.
Possibly, the known vulnerability information of the kernel layer of the embodiment of the application can comprise a known vulnerability list and the like.
Possibly, the embodiment of the application can also include other index information, such as code quality index, historical security record, community activity level and the like.
It can be appreciated that in the embodiment of the present application, the above-mentioned basic information of the kernel layer, the configuration information of the kernel layer, and the code of the kernel layer may be encoded and combined in a plurality of ways to obtain predicted vulnerability information, and then the predicted vulnerability information and the known vulnerability information may be compared to train the vulnerability risk model.
It will be appreciated that the compiling loopholes in the embodiments of the present application represent loopholes that may occur during encoding of code of the target kernel layer.
Possibly, the embodiment of the application can determine the compiling loopholes through a static method, for example, by analyzing the source code of the kernel to acquire the static information of the kernel, identify the code mode or unsafe programming practice in which the loopholes possibly exist, and detect the loopholes according to whether the static features related to the loophole patch files exist or not. The static analysis method has the advantages of simple analysis and realization and capability of comprehensively detecting the kernel code.
Possibly, the embodiment of the application can also adopt other decision models such as decision trees, neural networks and the like to establish the vulnerability risk model.
It will be appreciated that the execution vulnerability in the embodiments of the present application represents a vulnerability that may occur during execution of the target kernel layer code. Since the kernel layer typically involves complex interactions of multiple threads or processes at runtime, it may be difficult to accurately identify the risks that occur during its execution by the method of analyzing the code alone.
In particular, embodiments of the present application may detect vulnerabilities by dynamically determining the vulnerability of the execution, for example, by monitoring and analyzing kernel behavior at kernel layer runtime. The dynamic method has the advantages that the loopholes and abnormal behaviors can be detected in real time when the kernel runs, the corresponding safety problems can be quickly found and corresponding, and because the dynamic method is based on the analysis of the actual running behaviors of the kernel, more accurate loophole detection results can be provided, and the possibility of false alarm and false alarm is reduced.
S203, determining the vulnerability risk level of the target kernel layer based on the compiling vulnerability of the target kernel layer and the operation vulnerability of the target kernel layer.
Specifically, the compiling loopholes in the embodiment of the application can comprise any one or more of null pointer reference, kernel mode authority upgrade, unsafe system call, misuse of an application programming interface, unsafe driving call, hard coding sensitive and hard coding credential loopholes and use of a abandoned kernel application programming interface. The operation loopholes can comprise any one or more of unsafe system calls, buffer overflows, integer overflows, kernel memory leaks, information leaks, hardware-level loopholes, double releases, race conditions, deadlocks and resource exhaustion.
In particular, privilege upgrades represent permission to lower-privilege users or processes to obtain higher-level privileges, memory leaks that may lead to sensitive information leaks or system resource exhaustion, buffer overflows that may lead to system crashes or remote code execution, race conditions that may allow unauthorized operations such as file access or data modification, information leaks that may leak sensitive system or user data, hardware-level vulnerabilities that are present in computer hardware such as CPUs, graphics processors (graphics processing unit, GPUs), chipsets, etc. These vulnerabilities may allow for attack to bypass software security mechanisms, e.g., the "Meltdown" and "spectrum" vulnerabilities are hardware-level security flaws that utilize the specification execution functions of modern processors to access sensitive data of the system. Information leakage refers to kernel-level vulnerabilities that may result in unauthorized access or leakage of sensitive data (e.g., user information, system configuration, passwords, etc.). Because the second release may affect memory areas that have been reassigned to other uses, double releases may cause memory corruption, and sometimes an attacker may use double release holes to destroy the memory management data structure of the program, thereby executing any code or upgrade authority. Deadlocks are often caused by competing resources between multiple processes that prevent the normal running of the program such that these processes can never complete.
It will be appreciated that attacks are typically more complex to exploit than software-level vulnerabilities, but they tend to provide deeper system access rights, yet some interactivity exists between kernel vulnerabilities and hardware-level vulnerabilities. For example, some hardware-level vulnerabilities (e.g., spectrum) may require actual leakage of data through kernel-level vulnerabilities. Hardware-level vulnerabilities may exacerbate the severity of kernel-level information leakage. If the hardware is unable to reliably isolate the memory space of different processes, the risk of information leakage may increase even if the kernel is properly designed, and an attacker may take advantage of such vulnerabilities to obtain critical information, further upgrade the attack, such as obtaining higher system rights or executing remote code.
Further, the embodiment of the application can adopt the following treatment measures for different vulnerability risk levels of the target kernel layer:
1. lower risk level:
Monitoring and logging for low risk vulnerabilities, it is recommended to implement system monitoring and event logging to detect and respond in time when exploit attempts.
2. Medium risk rating:
And (3) repairing the medium risk loopholes by adopting a loophole repairing plan, and ensuring that the medium risk loopholes are repaired within a reasonable time range.
Updating the kernel-the kernel version may need to be updated or upgraded to include the relevant security fixes.
3. Higher risk level:
priority repair-high risk vulnerabilities should be repaired in priority to reduce the threat of potential attacks.
Emergency update-emergency release of kernel updates may be required to contain critical security fixes.
Emergency response-for high risk vulnerabilities, additional emergency response measures should be taken, such as disabling affected services or taking emergency security measures, to minimize potential risk.
4. Extremely high risk level:
immediate disablement of services-for extremely high risk vulnerabilities, immediate disablement of the affected services may be required to prevent the attack.
Investigation and tracking detailed investigation and tracking is required for the case that has been attacked to understand the impact of the attack and the way in which the vulnerability is exploited.
And (3) comprehensive repair, namely immediately repairing extremely high risk loopholes to ensure the safety of the system.
When implementing vulnerability management and emergency response policies, the vulnerability management and emergency response policies should be formulated according to the severity of the vulnerability, the influence of the vulnerability, the business requirements and the organization policies. Meanwhile, the organization should establish vulnerability management and emergency response plans to ensure that vulnerabilities are handled in due course, thereby maintaining the security of the system.
Therefore, the method adopts a mode of inputting the information to be detected of the target kernel layer into the vulnerability risk model to firstly determine the compiling vulnerability and the operation vulnerability of the target kernel layer, and then determines the vulnerability risk level of the target kernel layer through the compiling vulnerability and the operation vulnerability of the target kernel layer, so that the vulnerability generated during compiling and the vulnerability generated during operation are fully considered, the two methods can mutually compensate the limitation of self detection, and the false alarm rate is reduced.
In some implementations, fig. 3 illustrates a flowchart of a vulnerability risk level determination method provided by an embodiment of the present application. As shown in fig. 3, the vulnerability risk level determination method may at least include the following steps:
s301, extracting features of basic information of the kernel layer to obtain basic feature information of the kernel layer, and extracting features of configuration information of the kernel layer to obtain configuration feature information of the kernel layer.
Possibly, the embodiment of the application can normalize the values of the kernel version number, the release date and the like in the basic information, and can determine the classification characteristics by single-hot coding of the information such as the manufacturer, the encryption algorithm and the like.
In particular, one-hot encoding is mainly used to convert discrete features into continuous features so that machine learning algorithms can handle better. The one-hot code maps the value of each discrete feature to a binary vector, where only one element is a1 and the remaining elements are 0, the position of this element representing the position of the value in all values. For example, the vulnerability risk model stores a plurality of manufacturers, namely, manufacturer A, manufacturer B, manufacturer C, etc., and if the manufacturer of the kernel layer is manufacturer A, then the element corresponding to manufacturer A is 1, and the elements corresponding to other manufacturers are 0.
S302, obtaining a static loss value of the kernel layer based on the code of the kernel layer and basic characteristic information of the kernel layer, and obtaining a dynamic loss value of the kernel layer based on the code of the kernel layer and configuration characteristic information of the kernel layer.
The method and the device for determining the dynamic loss value of the kernel layer can determine the test compiling loopholes of the kernel layer based on the code of the kernel layer and the basic characteristic information of the kernel layer, determine the static loss value of the kernel layer based on the test compiling loopholes of the kernel layer and the known compiling loopholes of the kernel layer, determine the test running loopholes of the kernel layer based on the code of the kernel layer and the configuration characteristic information of the kernel layer, and determine the dynamic loss value of the kernel layer based on the test running loopholes of the kernel layer and the known running loopholes of the kernel layer.
And inputting the codes of the kernel layer and the basic characteristic information of the kernel layer into a first detection module to obtain the test compiling loopholes of the kernel layer. And inputting the codes of the kernel layer and the configuration characteristic information of the kernel layer into a second detection module to obtain the test operation loopholes of the kernel layer.
The first detection module comprises any one or more of the following detection of module dependency analysis, symbol table analysis, static data flow analysis and detection based on pattern matching. The second detection module is used for detecting codes of the kernel layer based on at least one test case, and the test case is used for simulating the attack behaviors of the user layer and/or the server.
Specifically, the embodiment of the application can analyze the dependency relationship among the modules of the kernel layer through the module dependency analysis, and can detect the hidden modules in the kernel layer or the malicious behaviors loaded with illegal modules. The symbol table analysis may identify illegal code in the kernel based on known legal kernel functions and their associated code features. The technique is capable of detecting malicious functions in the kernel that use fraudulent naming patterns. Static data flow analysis, the technology tracks the sources and the destinations of sensitive variables (such as system call parameters, process Identification (ID) and the like) when carrying out static analysis on codes of a kernel layer, and is convenient for finding and preventing attacks on the sensitive variables. The detection of pattern matching can design corresponding detection rules according to known attack behavior patterns, and then scan kernel mode codes and user mode codes in the running process of the system, so that similar attack can be found and prevented, and the matching attack behavior can be detected.
Possibly, the second detection module in the embodiment of the present application may determine the running vulnerability of the kernel layer by adopting a Proof of Concept (PoC) method, and simulate the attack process by writing a special test case. The method comprises the steps of triggering loopholes in the kernel and recording related information by constructing specific input data or input sequences to verify whether the kernel has the loopholes. Specifically, the type of the vulnerability to be detected needs to be determined, kernel versions, patch levels, configuration options and the like need to be defined, and then a proper test case is selected according to the type of the vulnerability and an attack scene. And writing PoC codes required by symbol test again for testing, and generating vulnerability construction parameters and corresponding attack codes. If experimental verification is performed in a controlled environment, poC needs to be continually modified and perfected to ensure that it can successfully trigger a vulnerability. If the PoC successfully triggers the vulnerability, the attacker can thereby further exploit the vulnerability, boost the rights, execute code, etc. And meanwhile, the record utilization and reproduction process is also needed, so that the subsequent safety analysis and report writing are facilitated.
It can be understood that, because the PoC method is based on the actual vulnerability, more malicious behaviors can be detected, thereby improving the detection accuracy and comprehensiveness.
In addition, the embodiment of the application can also determine the operation loopholes of the kernel layer by adopting a mode of combining a PoC method and a system call method. The system call method may detect whether there is an exception in the parameters and return values of the system call based on monitoring the behavior of the system call. In kernel layer vulnerability detection, whether kernel layer vulnerabilities exist or not is judged by monitoring the use condition of system calls and according to defined rules or trust models. The system call may also detect some low-level malicious attacks, such as attacks based on buffer overflows, etc. And simulating the operation process of the kernel layer by using a PoC method, and detecting by using a system call method in the operation process. The system call monitoring program records all syscall calls and parameters thereof, checks whether the parameters are abnormal, and analyzes whether a returned result is normal. If the exception exists, the kernel is indicated to have the vulnerability.
Possibly, the PoC method and the system call method may be run again by gradually changing the parameters of the attack code or adding more attack scenarios, and gradually verifying whether other kernel layer vulnerabilities can be exposed.
S303, training the initial model of the vulnerability risk based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer to obtain the model of the vulnerability risk.
Possibly, the embodiment of the application can process a word bag model or a common weighting technology (Term Frequency-Inverse Document Frequency, TF-IDF) of information retrieval and text mining on possibly occurring text data (for example, known vulnerability information), and train and verify a vulnerability risk model through a random forest algorithm.
It can be appreciated that vulnerability risk level assessment is a complex process that requires training of an initial model of vulnerability risk based on a number of factors:
1. the types of loopholes, such as authority upgrading, hardware level loopholes and the like, are more likely to cause serious security consequences. However, this does not mean that every such vulnerability would be classified as a high risk vulnerability.
2. The context of the vulnerability includes the importance of the software component in which the vulnerability is located, the extent to which the vulnerability is readily exploited, the potential scope of influence, etc.
3. Availability of vulnerabilities-even though seemingly serious vulnerabilities-actual risk may be low if it is difficult to exploit (e.g., requires specific conditions or uses advanced skills).
4. Potential impacts of vulnerabilities include different impact dimensions, such as data leakage, service interruption, system control rights being acquired, etc. Some seemingly slight vulnerabilities may have a significant impact in certain situations.
Thus, in training the initial model of vulnerability risk, the model should be trained based on the factors described above. Furthermore, different types of vulnerabilities may have different levels of risk in different application environments. For example, for a high security system, any vulnerability that may lead to information leakage may be considered a high risk. While for a system that is less demanding in terms of security, the same vulnerability may be considered only medium or low risk.
Further, the embodiment of the application can determine the loss value of the initial model of the vulnerability risk based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer, and execute the step S302 again after adjusting the model parameters of the initial model of the vulnerability risk under the condition that the loss value of the initial model of the vulnerability risk is larger than the loss threshold value until the loss value of the initial model of the vulnerability risk is smaller than or equal to the loss threshold value, so as to obtain the model of the vulnerability risk.
It will be appreciated that the loss value of the vulnerability risk initial model, i.e., the total loss value, is a combination of the static loss value and the dynamic loss value by some method (e.g., weighted average or maximum value, etc.) to obtain a comprehensive loss value.
Possibly, the embodiment of the application can calculate the loss value of the vulnerability risk initial model by the following ways:
Calculating a static loss value, wherein the static loss value=f (test compiling loopholes, known compiling loopholes);
calculating a dynamic loss value, namely, dynamic loss value = f (test operation loopholes, known test loopholes);
Loss value=g (static loss value, dynamic loss value) of vulnerability risk initial model.
Where f and g are functions for calculating the loss value, which may include weighting, normalization, nonlinear transformation, etc. algorithms.
Possibly, the embodiment of the application further comprises index information which can be used for helping training the initial model of the vulnerability risk so as to obtain a model of the vulnerability risk with more accurate prediction.
Specifically, the index information in the embodiment of the application can comprise code quality indexes which can influence the security of software, such as code complexity, compliant coding standards, proportion of repeated codes, code coverage rate and the like. The historical security records comprise the number of the loopholes discovered by the historical version, the repair speed, the severity of the loopholes and the like. Community liveness, such as the liveness of the developer, feedback and engagement of the community, frequency of periodic updates and maintenance, and the like.
It will be appreciated that an active community generally means that software is updated in time and vulnerabilities can be discovered and repaired quickly. Effective communication and collaboration among community members also helps to improve the overall security of the software. Conversely, items lacking an active community may result in vulnerabilities that are not discovered or repaired for a long period of time, increasing security risks.
S304, obtaining information to be detected of the target kernel layer.
Specifically, S304 corresponds to S201, and will not be described here.
S305, inputting information to be detected of the target kernel layer into the vulnerability risk model to obtain compiling vulnerabilities and operation vulnerabilities of the target kernel layer.
Specifically, S305 corresponds to S202, and will not be described here.
S306, determining the vulnerability risk level of the target kernel layer based on compiling vulnerabilities of the target kernel layer and running vulnerabilities of the target kernel layer.
Specifically, S306 corresponds to S203, and will not be described here.
It should be noted that, when the kernel vulnerability detection system provided in the above embodiment executes the kernel vulnerability detection method, only the division of the above functional modules is used for illustration, in practical application, the above functional allocation may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the kernel vulnerability detection system provided in the above embodiment and the kernel vulnerability detection method embodiment belong to the same concept, which embody the detailed implementation process in the method embodiment, and are not described herein again.
The foregoing embodiment numbers of the present application are merely for the purpose of description, and do not represent the advantages or disadvantages of the embodiments.
Fig. 4 is a schematic structural diagram of a vulnerability risk level determining apparatus according to an exemplary embodiment of the present application. The vulnerability risk level determining device may be disposed in a server or other device, and execute the information pushing method according to any of the above embodiments of the present application. As shown in fig. 4, the information pushing apparatus may include:
The acquisition module 41 is configured to acquire information to be tested of a target kernel layer, where the information to be tested includes basic information of the target kernel layer, configuration information of the target kernel layer, and codes of the target kernel layer;
The obtaining module 42 is configured to input information to be tested of the target kernel layer into a vulnerability risk model to obtain a compiling vulnerability and an operating vulnerability of the target kernel layer, where the vulnerability risk model is obtained based on information training of kernel layers of a plurality of known vulnerability risk information, and the information of the kernel layer of the known vulnerability risk information includes basic information of the kernel layer, configuration information of the kernel layer, and codes of the kernel layer;
the determining module 43 is configured to determine a vulnerability risk level of the target kernel layer based on the compiling vulnerability of the target kernel layer and the operation vulnerability of the target kernel layer.
Therefore, the method adopts a mode of inputting the information to be detected of the target kernel layer into the vulnerability risk model to firstly determine the compiling vulnerability and the operation vulnerability of the target kernel layer, and then determines the vulnerability risk level of the target kernel layer through the compiling vulnerability and the operation vulnerability of the target kernel layer, so that the vulnerability generated during compiling and the vulnerability generated during operation are fully considered, the two methods can mutually compensate the limitation of self detection, and the false alarm rate is reduced.
In some embodiments, prior to the deriving module 42, the apparatus includes:
The kernel layer information acquisition module is used for acquiring information of a plurality of kernel layers with known vulnerability risk values;
The vulnerability risk model obtaining module is used for training a pre-established vulnerability risk initial model based on the information of the kernel layers of the known vulnerability risk values to obtain the vulnerability risk model.
In some embodiments, the basic information of the kernel layer comprises any one or more of kernel version information, release date and manufacturer, and the configuration information of the kernel layer comprises any one or more of encryption algorithm, authority setting, network configuration, patch information and running environment information;
the vulnerability risk model obtaining module is specifically configured to:
Extracting the characteristics of the basic information of the kernel layer to obtain the basic characteristic information of the kernel layer;
extracting the characteristics of the configuration information of the kernel layer to obtain the configuration characteristic information of the kernel layer;
based on the codes of the kernel layer and the basic characteristic information of the kernel layer, obtaining a static loss value of the kernel layer;
Obtaining a dynamic loss value of the kernel layer based on the code of the kernel layer and the configuration characteristic information of the kernel layer;
And training the initial model of the vulnerability risk based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer to obtain the model of the vulnerability risk.
In some embodiments, the known vulnerability information of the kernel layer includes a known compiling vulnerability of the kernel layer and a known running vulnerability of the kernel layer;
the vulnerability risk model obtaining module is specifically configured to:
Determining a test compiling vulnerability of the kernel layer based on the code of the kernel layer and basic characteristic information of the kernel layer;
Determining a static loss value of the kernel layer based on the test compiling loopholes of the kernel layer and the known compiling loopholes of the kernel layer;
the vulnerability risk model obtaining module is specifically configured to:
determining the test operation loopholes of the kernel layer by the codes of the kernel layer and the configuration characteristic information of the kernel layer;
And determining a dynamic loss value of the kernel layer based on the test operation loopholes of the kernel layer and the known operation loopholes of the kernel layer.
In some embodiments, the vulnerability risk model obtaining module is specifically configured to:
determining a loss value of the vulnerability risk initial model based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer;
And under the condition that the loss value of the initial model of the vulnerability risk is larger than a loss threshold value, after the model parameters of the initial model of the vulnerability risk are adjusted, executing the code based on the kernel layer and the basic characteristic information of the kernel layer again to obtain the static loss value of the kernel layer, and obtaining the dynamic loss value of the kernel layer based on the code of the kernel layer and the configuration characteristic information of the kernel layer until the loss value of the initial model of the vulnerability risk is smaller than or equal to the loss threshold value to obtain the model of the vulnerability risk.
In some embodiments, the initial model of vulnerability risk comprises a first detection module and a second detection module;
the vulnerability risk model obtaining module is specifically configured to:
Inputting the codes of the kernel layer and the basic characteristic information of the kernel layer into the first detection module to obtain the test compiling loopholes of the kernel layer, wherein the first detection module comprises any one or more of the following detection including module dependency analysis, symbol table analysis, static data flow analysis and detection based on pattern matching;
the vulnerability risk model obtaining module is specifically configured to:
and inputting the codes of the kernel layer and the configuration characteristic information of the kernel layer into the second detection module to obtain the test operation loopholes of the kernel layer, wherein the second detection module is used for detecting the codes of the kernel layer based on at least one test case, and the test case is used for simulating the attack behaviors of a user layer and/or a server.
In some embodiments, the compilation loopholes include any one or more of null pointer references, kernel mode permission errors, unsafe system calls, application programming interface misuse, unsafe drive calls, hard coded sensitive information, hard coded credentials, use of obsolete kernel application programming interfaces;
The operation loopholes comprise any one or more of unsafe system call, buffer overflow, integer overflow, kernel memory leakage, double release, race condition, deadlock and resource exhaustion.
Referring to fig. 5, a schematic structural diagram of a terminal is provided in an embodiment of the present application. As shown in fig. 5, the terminal 50 may include at least one processor 51, at least one network interface 54, a user interface 53, a memory 55, and at least one communication bus 52.
Wherein the communication bus 52 is used to enable connected communication between these components.
The user interface 53 may include a Display screen (Display) and a Camera (Camera), and the optional user interface 53 may further include a standard wired interface and a standard wireless interface.
The network interface 54 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others.
Wherein the processor 51 may comprise one or more processing cores. The processor 51 connects various parts within the overall terminal 50 using various interfaces and lines, performs various functions of the terminal 50 and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 55, and invoking data stored in the memory 55. Alternatively, the processor 51 may be implemented in at least one hardware form of digital signal Processing (DIGITAL SIGNAL Processing, DSP), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA), programmable logic array (Programmable Logic Array, PLA). The processor 51 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), an image processor (Graphics Processing Unit, GPU), and a modem, etc. The CPU mainly processes an operating system, a user interface, an application program and the like, the GPU is used for rendering and drawing contents required to be displayed by the display screen, and the modem is used for processing wireless communication. It will be appreciated that the modem may not be integrated into the processor 51 and may be implemented by a single chip.
The Memory 55 may include a random access Memory (Random Access Memory, RAM) or a Read-Only Memory (Read-Only Memory). Optionally, the memory 55 includes a non-transitory computer readable medium (non-transitory computer-readable storage medium). Memory 55 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 55 may include a stored program area that may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-described respective method embodiments, etc., and a stored data area that may store data, etc., referred to in the above-described respective method embodiments. The memory 55 may alternatively be at least one memory system located remotely from the aforementioned processor 51. As shown in fig. 5, an operating system, a network communication module, a user interface module, and a kernel vulnerability detection application may be included in the memory 55 as one type of computer storage medium.
In the terminal 50 shown in fig. 5, the user interface 53 is mainly used for providing an input interface for a user to obtain data input by the user, and the processor 51 may be used for calling a kernel vulnerability detection application program stored in the memory 55 and specifically performing the following operations:
Obtaining information to be detected of a target kernel layer, wherein the information to be detected comprises basic information of the target kernel layer, configuration information of the target kernel layer and codes of the target kernel layer;
inputting information to be detected of the target kernel layer into a vulnerability risk model to obtain compiling vulnerability and operation vulnerability of the target kernel layer, wherein the vulnerability risk model is obtained based on information training of kernel layers of a plurality of known vulnerability risk information, and the information of the kernel layer of the known vulnerability risk information comprises basic information of the kernel layer, configuration information of the kernel layer and codes of the kernel layer;
And determining the vulnerability risk level of the target kernel layer based on the compiling vulnerability of the target kernel layer and the running vulnerability of the target kernel layer.
In some embodiments, before executing the inputting the information to be tested of the target kernel layer into the vulnerability risk model, the processor 51 further executes:
acquiring information of a plurality of kernel layers with known vulnerability risk values;
training a pre-established initial model of the vulnerability risk based on the information of the kernel layers of the known vulnerability risk values to obtain the vulnerability risk model.
In some embodiments, the basic information of the kernel layer comprises any one or more of kernel version information, release date and manufacturer, and the configuration information of the kernel layer comprises any one or more of encryption algorithm, authority setting, network configuration, patch information and running environment information;
The processor 51 performs feature extraction on basic information of the kernel layer to obtain basic feature information of the kernel layer when performing information of the kernel layer based on a plurality of known vulnerability risk values and training a pre-established vulnerability risk initial model to obtain the vulnerability risk model;
extracting the characteristics of the configuration information of the kernel layer to obtain the configuration characteristic information of the kernel layer;
based on the codes of the kernel layer and the basic characteristic information of the kernel layer, obtaining a static loss value of the kernel layer;
Obtaining a dynamic loss value of the kernel layer based on the code of the kernel layer and the configuration characteristic information of the kernel layer;
And training the initial model of the vulnerability risk based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer to obtain the model of the vulnerability risk.
In some embodiments, the known vulnerability information of the kernel layer includes a known compiling vulnerability of the kernel layer and a known running vulnerability of the kernel layer;
the processor 51 specifically executes when executing the code based on the kernel layer and the basic feature information of the kernel layer to obtain a static loss value of the kernel layer:
Determining the test compiling loopholes of the kernel layer by codes of the kernel layer and basic characteristic information of the kernel layer;
Determining a static loss value of the kernel layer based on the test compiling loopholes of the kernel layer and the known compiling loopholes of the kernel layer;
the processor 51 specifically executes when executing the code based on the kernel layer and the configuration feature information of the kernel layer to obtain a dynamic loss value of the kernel layer:
determining the test operation loopholes of the kernel layer by the codes of the kernel layer and the configuration characteristic information of the kernel layer;
And determining a dynamic loss value of the kernel layer based on the test operation loopholes of the kernel layer and the known operation loopholes of the kernel layer.
In some embodiments, when the processor 51 trains the initial model of vulnerability risk based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer to obtain the model of vulnerability risk, the method specifically includes:
determining a loss value of the vulnerability risk initial model based on the static loss value of the kernel layer and the dynamic loss value of the kernel layer;
And under the condition that the loss value of the initial model of the vulnerability risk is larger than a loss threshold value, after the model parameters of the initial model of the vulnerability risk are adjusted, executing the code based on the kernel layer and the basic characteristic information of the kernel layer again to obtain the static loss value of the kernel layer, and obtaining the dynamic loss value of the kernel layer based on the code of the kernel layer and the configuration characteristic information of the kernel layer until the loss value of the initial model of the vulnerability risk is smaller than or equal to the loss threshold value to obtain the model of the vulnerability risk.
In some embodiments, the initial model of vulnerability risk comprises a first detection module and a second detection module;
the processor 51 specifically performs, when executing the determination of the test compiling vulnerability of the kernel layer based on the code of the kernel layer and the basic feature information of the kernel layer:
Inputting the codes of the kernel layer and the basic characteristic information of the kernel layer into the first detection module to obtain the test compiling loopholes of the kernel layer, wherein the first detection module comprises any one or more of the following detection including module dependency analysis, symbol table analysis, static data flow analysis and detection based on pattern matching;
The processor 51 specifically performs, when executing the code of the kernel layer and the configuration feature information of the kernel layer to determine a test operation vulnerability of the kernel layer:
and inputting the codes of the kernel layer and the configuration characteristic information of the kernel layer into the second detection module to obtain the test operation loopholes of the kernel layer, wherein the second detection module is used for detecting the codes of the kernel layer based on at least one test case, and the test case is used for simulating the attack behaviors of a user layer and/or a server.
In some embodiments, the compilation loopholes include any one or more of null pointer references, kernel mode permission errors, unsafe system calls, application programming interface misuse, unsafe drive calls, hard coded sensitive information, hard coded credentials, use of obsolete kernel application programming interfaces;
The operation loopholes comprise any one or more of unsafe system call, buffer overflow, integer overflow, kernel memory leakage, double release, race condition, deadlock and resource exhaustion.
Embodiments of the present application also provide a computer-readable storage medium having instructions stored therein, which when executed on a computer or processor, cause the computer or processor to perform one or more of the steps of the embodiment shown in fig. 2 described above. The above-described constituent modules of the kernel vulnerability detection system may be stored in the computer-readable storage medium if implemented in the form of software functional units and sold or used as independent products.
In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable system. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digital Subscriber Line, DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disk (DIGITAL VERSATILE DISC, DVD)), or a semiconductor medium (e.g., a Solid state disk (Solid STATE DISK, SSD)), or the like.
Those skilled in the art will appreciate that implementing all or part of the above-described embodiment methods may be accomplished by way of a computer program, which may be stored in a computer-readable storage medium, instructing relevant hardware, and which, when executed, may comprise the embodiment methods as described above. The storage medium includes various media capable of storing program codes such as a Read Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk. The technical features in the present examples and embodiments may be arbitrarily combined without conflict.
The above-described embodiments are merely illustrative of the preferred embodiments of the present application and are not intended to limit the scope of the present application, and various modifications and improvements made by those skilled in the art to the technical solution of the present application should fall within the scope of protection defined by the claims of the present application without departing from the design spirit of the present application.