Online repairing method for unknown vulnerability Cache patch of power terminal

Abstract

The invention provides a power terminal unknown vulnerability Cache patch online repair method, which comprises the following steps: firstly, formulating a Cache patch construction standard under a heterogeneous computing platform, defining a kernel-level multi-point hook, and carrying out correlation function replacement; secondly, a Cache code detection and vulnerability code segment accurate positioning method of the electric power intelligent terminal is provided, a function redirection-based Cache patch injection and replacement technology during operation is provided, and a'hot patch 'repair component of the electric power intelligent terminal is provided; by applying the technical scheme, the influence of service interruption caused by vulnerability repair processing in a multi-service fusion operation environment can be reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of Cache patches, and in particular to an online repair method for Cache patches of unknown vulnerabilities in power terminals. Background Art

[0002] With the continuous development of the power system, the network security situation is becoming more and more severe. Therefore, timely grasping the current system network security status can repair and protect the system's weaknesses as early as possible, effectively avoiding the occurrence of network security incidents. The cache "hot patch" vulnerability repair problem of the power intelligent terminal consumes manpower and material resources, and further optimization is needed to reduce the impact of business interruption caused by vulnerability repair and disposal in the multi-business converged operation environment. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide an online repair method for unknown vulnerability cache patches of power terminals, which reduces the impact of business interruptions caused by vulnerability repair disposal in a multi-business converged operating environment.

[0004] To achieve the above-mentioned purpose, the present invention adopts the following technical solutions: a method for online repair of cache patches for unknown vulnerabilities in power terminals. First, a cache patch construction standard under a heterogeneous computing platform is formulated, and kernel-level multi-point hooks and related function replacements are clarified; secondly, a method for accurately locating cache code detection and vulnerability code segments in power intelligent terminals is proposed, a runtime cache patch injection and replacement technology based on function redirection is proposed, and a "hot patch" repair component for power intelligent terminals is proposed.

[0005] In a preferred embodiment, the cache patch construction process method is specifically as follows: first, the hot patch source code is made into a loadable dynamic link library through a compiler, and then the hot patch is loaded into the address space of the target process through a loader. Finally, after a consistency model check is performed to confirm safety, the original code is replaced with a new code to complete the online repair process.

[0006] In a preferred embodiment, the hot patch itself and the hot patch loading program specifically include:

[0007] (1) Hot patch production

[0008] Write the hot patch source code and compile it into a hot patch patch.so in the format of a dynamic link library. Patch.so contains the information of func and func_v2.

[0009] When the hot patch patch.so is loaded into the address space of the target process T by the loader, the address of func is found through the dlsym call, and the entry instruction of func is changed to be writable, and at the same time, it is changed to jump to func_v2;

[0010] At this point, all calls to func will be redirected to func_v2, and func_v2 will return after execution, and the program will continue to run;

[0011] (2) Hot Patch Loader

[0012] The loader finds the entry address of the dlopen function of the target process T;

[0013] The loader attaches to the target process T through ptrace. The loader puts the name of the hot patch into the stack of the target process T and sets the IP register to the address of the dlopen function.

[0014] Loader enables the target process T to continue running; because the IP register has been set to the entry point of the dlopen function, the target process T will call dlopen to load the hot patch into the address space of T;

[0015] If you need to make a hot patch, you only need to write patch.so yourself. Loader is universal, and patch.so only needs a few lines of code to make corresponding replacements.

[0016] (3) Hot patch implementation

[0017] When the target process T executes dlopen, the function func_v1 replaces the function func during the loading process through the constructor function pre-written in the hot patch;

[0018] (4) Hot Patch Loader

[0019] 1) Loader obtains the dlopen entry address in the target process T address space;

[0020] The dlopen function is provided by libdl. Not all programs load libdl. Fortunately, libc provides a function with the same function, libc_dlopen_mode, and the parameters accepted are the same as dlopen. Unless there are special circumstances, all programs will load libc. Therefore, it is necessary to find the function entry address of libc_dlopen_mode in the address space of the target process T.

[0021] In different processes, libc will be loaded to different base addresses, but the offset of the address of the function in libc relative to the base address remains unchanged;

[0022] Through the / proc / pid / maps of the Loader and the target process T, we can get the base address of libc loaded in the Loader and the target process T; by running dlsym in the Loader, we can get the base address in the Loader;

[0023] The address of libc_dlopen_mode; this way, the address of libc_dlopen_mode in the target process T can be obtained;

[0024] 2) Loader uses ptraceattach on the target process T and saves the register information of T at this time;

[0025] 3) Set the %RIP of the target process T to point to dlopen, put the string of the hot patch name into the stack, write the address of the string into %rdi, and write the value of RTLD_NOW into %rsi as the flag of dlopen; at the same time, set the dlopen return address to the illegal address 0x0, so that the loader captures the SIGSEGV signal generated by the target process T and regains control of T;

[0026] 4) Loader enables the target process T to continue running; after T completes executing dlopen, the SIGSEGV signal generated by T is captured by Loader, and Loader regains control of the T process;

[0027] 5) Loader obtains the return value of dlopen by reading the %rax register of the target process T at this time, restores T's initial execution state, and finally releases control over T;

[0028] 5) Hot patch repair process

[0029] It is loaded into the target process by Loader, registers its own information to CoreRuntime, and uses the replacement code contained in itself to replace the problematic function after activation; when stopping all threads, it is necessary to first obtain all thread information, interact with libc in the process through the libthread_db library to obtain thread information, and obtain thread information directly from the kernel through the / proc / pid / tasks / directory; after stopping all threads, it is necessary to obtain all thread information again to check whether there are new threads, and if necessary, stop the new threads; repeat the above steps until no new threads appear;

[0030] (6) Automatically generate hot patches

[0031] Automatically generating hot patches is a technology that uses hot patch generation tools to process existing source code and patch files and automatically output hot patches. The basic principle of hot patches is to replace old functions with new ones, that is, to replace complete functions. The patch may contain modifications to one or more functions, and all of these modified functions will be replaced. The hot patch first puts the new function into the cache of the target process, and then modifies the entry of the old function to jump to the new function. The most important part of automatically generating hot patches is to automatically generate the binary code of the new function, also known as the replacement code. When generating the replacement code, it consists of automatically generating the replacement code and parsing the symbols used in the replacement code.

[0032] (7) Compare the previous and next codes to generate replacement code

[0033] A binary comparison method is used to extract all the information required to generate the replacement code by comparing the binary of the original program with the binary of the repaired program; the before and after comparison is performed at the level of the target file objectfile;

[0034] First, any source code changes will be reflected in the binary code of the object file;

[0035] Second, there is no need to deal with language-level features;

[0036] Finally, we only care about the binary representation of the code; at the target file level, the binary code and code composition information are the most complete, and it is most reasonable to compare the code before and after here;

[0037] (8) Symbol resolution in replacement code

[0038] The replacement code only contains the changed function codes, which may reference other unchanged symbols, so it is necessary to follow the symbol reference rules; the offset of the address of the code segment of the dynamic link library in the cache is calculated by the formula Addr = Base + Offset; in other cases, the address of the symbol is an absolute address and does not need to be calculated;

[0039] (9)POC: Generate replacement code and symbol resolution

[0040] Extract the .text.func section in T-patched.o;

[0041] According to the redirection information recorded previously, calculation (V=S+AP) is performed and func is written to the position offset by 0xa. After the redirection, the func function in the replacement code can correctly reference the print function in the original program. Finally, the behavior of the T program after the hot patch is inserted is observed through GDB, and the static and dynamic forms of the replacement code are verified through objdump and gdb.

[0042] In a preferred embodiment, the function file replacement specifically includes:

[0043] The first step is to load the ELF file header and check the file type and version. It is important to find the address of the programheader and the number of headers. If the connector script is the default, the ELF file header will be loaded at the address 0x804800.

[0044] The second step is to load the programheader, then scan the programheader and find a programheader of type PT_INTERP. This header contains the address of the interpreter. At this time, load the elf file header of the interpreter program.

[0045] The third step is to scan the programheader. If the type is PT_LOAD, load the segment in.

[0046] The fourth step is to determine whether an interpreter program is needed. If so, load the interpreter program and set the program entry to the address of the interpreter program; otherwise, it is the entry of the application program itself; disassemble it to the _start label;

[0047] Step 5: Set the parameters passed in by the command line and other information required by the application;

[0048] In the sixth step, the interpreter program starts running, loads the libraries required by the program, and fills in the address information in the redirection symbol table.

[0049] In a preferred embodiment, the hierarchical vulnerability repair VR-VTC model design of vulnerability type clustering includes three steps:

[0050] Step 1: Vulnerability cluster analysis;

[0051] PSO-K-means clustering algorithm: Use the PSO algorithm to find the cluster center, and use the K-means algorithm to cluster the vulnerability data after preprocessing;

[0052] Quantitative analysis of vulnerability type threat: Calculate the threat factor of each vulnerability type using the percentage of each vulnerability type's high, medium, and low risk levels;

[0053] Step 2: Vulnerability severity assessment;

[0054] Find the latest relevant security patches based on the host vulnerability reports obtained by the OVAL-based vulnerability scanner;

[0055] The proposed vulnerability severity assessment method based on rough sets performs quantitative and qualitative assessments on each vulnerability in the host;

[0056] Step 3: Vulnerability repair strategy selection;

[0057] Construct a hierarchical target host model for vulnerability types. The target host model is decomposed from top to bottom into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. The vulnerability repair strategy of "bottom-up, first local and then overall" is adopted;

[0058] A hierarchical vulnerability repair method based on vulnerability type is proposed, and finally a fine-grained vulnerability repair strategy is given;

[0059] Execute corresponding remediation strategies according to vulnerability priority.

[0060] In a preferred embodiment, a hierarchical target host model construction method for vulnerability types is proposed. The hierarchical relationship of the target host model is decomposed into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. The strategy of "bottom-up, first local and then overall" is adopted. The specific steps are as follows:

[0061] (1) Using the OVAL-based vulnerability scanner

[12] , we obtain a total of N vulnerabilities Vi for the host Host, where the value of i is in the range of 1≤i≤N;

[0062] (2) Use the vulnerability severity assessment method based on rough sets proposed in the literature

[11] to calculate the severity score QS of each vulnerability and obtain the corresponding vulnerability severity level;

[0063] (3) For M vulnerability types, vulnerabilities Vi of the same type are grouped into a vulnerability type VTk group, where the value range of k is 1≤k≤M;

[0064] (4) Put all vulnerabilities with a vulnerability type threat level of "weak hazard" into the Ggreen group; similarly, put the vulnerabilities with a "medium hazard" and "strong hazard" level into the corresponding Gyellow and Gred groups respectively.

[0065] In a preferred embodiment, the hierarchical vulnerability repair method based on vulnerability type comprises the following steps:

[0066] (1) In the Ggreen group, for each vulnerability, the corresponding repair strategy is implemented according to the Ggreen threat level rules; if the QS is high risk, the priority level is P1, and the patch installation time is no more than 1 week; if it is medium risk, the priority level is P2, and the patch installation time is no more than 5 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 9 weeks;

[0067] (2) In the Gyellow group, the corresponding repair strategy is implemented for each vulnerability according to the Gyellow threat level rules; if the QS is high risk, the priority level is P1, and the patch installation time is no more than 2 weeks; if it is medium risk, the priority level is P2, and the patch installation time is no more than 6 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 10 weeks;

[0068] (3) In the Gred group, the corresponding repair strategy is executed for each vulnerability Gred threat level rule; if the QS is high risk, the priority level is P1, and the patch installation time is up to 3 weeks; if it is medium risk, the priority level is P2, and the patch installation time is up to 7 weeks; if it is low risk, the priority level is P3, and the patch installation time is up to 11 weeks; CNNVD manually marks the vulnerability types of all vulnerabilities, and the result is 26 vulnerability types. The vulnerability type corresponding to each vulnerability is obtained through the crawler program, and its performance is compared with the clustering result obtained by the PSO-K-means algorithm; the various parameter values ​​of the PSO-K-means algorithm are: the population size of the particle swarm m = 65295, the number of clusters k = 26, the maximum number of iterations maxTime = 200, and the fitness variance threshold threδ of the particle swarm = 0.1; therefore, the size of KSset is a two-dimensional vector of 50×65295; the horizontal axis represents the vulnerability type.

[0069] Compared with the prior art, the present invention has the following beneficial effects: the present invention solves the problem of online vulnerability repair of power terminals such as power fusion terminals and distribution automation terminals, reduces the impact of business interruption caused by vulnerability repair in a multi-business fusion operation environment, and provides technical guarantee for the rapid repair of vulnerabilities in massive power intelligent terminals across the entire network BRIEF DESCRIPTION OF THE DRAWINGS

[0070] Figure 1 A diagram showing the relationship between patch status switching and command operations in a preferred embodiment of the present invention;

[0071] Figure 2 This is a schematic diagram of a patch not being loaded according to a preferred embodiment of the present invention;

[0072] Figure 3 A schematic diagram of loading a patch file according to a preferred embodiment of the present invention;

[0073] Figure 4 A schematic diagram of a patch being activated according to a preferred embodiment of the present invention;

[0074] Figure 5 A schematic diagram of a patch being confirmed to be running according to a preferred embodiment of the present invention;

[0075] Figure 6 A schematic diagram of a cache patch construction process according to a preferred embodiment of the present invention;

[0076] Figure 7 This is a schematic diagram of precise replacement comparison of functions in a preferred embodiment of the present invention;

[0077] Figure 8 A schematic diagram of a hot patch loading process according to a preferred embodiment of the present invention;

[0078] Fig. 9 A schematic diagram of a hot patch repair process according to a preferred embodiment of the present invention;

[0079] Fig.10 A schematic diagram of a hot patch repair safety mechanism according to a preferred embodiment of the present invention;

[0080] Fig.11 A schematic diagram of the differential comparison before and after the hot patch repair in a preferred embodiment of the present invention;

[0081] Fig.12 This is a schematic diagram of a kernel-level replacement hit three times in a preferred embodiment of the present invention;

[0082] Fig.13 This is a schematic diagram of a kernel-level replacement hit once in a preferred embodiment of the present invention;

[0083] Fig.14 A schematic diagram of a kernel-level replacement miss in a preferred embodiment of the present invention;

[0084] Fig.15 This is a schematic diagram of a kernel-level replacement hit twice in a preferred embodiment of the present invention;

[0085] Fig.16 A schematic diagram of a memory allocation write-back method according to a preferred embodiment of the present invention;

[0086] Fig.17 A schematic diagram of a memory non-write allocation method according to a preferred embodiment of the present invention;

[0087] Fig.18 A schematic diagram of using the memory allocation full write and write back method according to a preferred embodiment of the present invention;

[0088] Fig.19 This is a LRU flow chart of a preferred embodiment of the present invention;

[0089] Fig. 20 A schematic diagram of a method for implementing 1LRU and MRU in a preferred embodiment of the present invention;

[0090] Fig.21 LRU example 1 of the preferred embodiment of the present invention

[0091] Fig. 22 LRU Example 2 of the preferred embodiment of the present invention

[0092] Fig.23MRU Example 1 of the preferred embodiment of the present invention

[0093] Fig.24 A schematic diagram of a PseudoLRU according to a preferred embodiment of the present invention;

[0094] Fig.25 A schematic diagram of a precise replacement instruction according to a preferred embodiment of the present invention;

[0095] Fig.26 A schematic diagram of a remapping function replacement according to a preferred embodiment of the present invention;

[0096] Fig. 27 A schematic diagram of continuously collecting and marking kernel vulnerability repair patches in a preferred embodiment of the present invention;

[0097] Fig.28 A schematic diagram of a patch submission log information feature extraction process according to a preferred embodiment of the present invention;

[0098] Fig.29 A schematic diagram of the VR-VTC model architecture of a preferred embodiment of the present invention;

[0099] Fig.30 A schematic diagram of a hierarchical target host model oriented to vulnerability types according to a preferred embodiment of the present invention;

[0100] Fig.31 Schematic diagram of vulnerability repair strategy according to a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0101] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0102] It should be noted that the following detailed descriptions are illustrative and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

[0103] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application; as used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or their combinations.

[0104] A method for online repair of cache patches for unknown vulnerabilities in power terminals, reference Figure 1-31, a cache "hot patch" vulnerability repair technology for power smart terminals, formulated the cache patch construction standard under heterogeneous computing platforms, clarified the technical requirements such as kernel-level multi-point hooks and associated function replacement; proposed a method for accurately locating cache code detection and vulnerable code segments for power smart terminals, invented a runtime cache patch injection and replacement technology based on function redirection, and developed a "hot patch" repair component for power smart terminals, which solved the problem of online vulnerability repair for power terminals such as power fusion terminals and distribution automation terminals, reduced the impact of business interruptions caused by vulnerability repair and disposal in a multi-business fusion operating environment, and provided technical support for the rapid repair of vulnerabilities in massive power smart terminals across the entire network.

[0105] 1. Cache patch construction under heterogeneous computing platform

[0106] Ⅰ. Vulnerability Lifecycle Phases

[0107] By observing the life cycle of security vulnerabilities and summarizing the conventions of scientific researchers and enterprises in dividing security vulnerabilities into stages, the software vulnerability life cycle is mainly divided into four stages:

[0108] Phase 1: This phase has attracted widespread attention from scholars. For example, vulnerability detection, vulnerability mining, vulnerability analysis, and vulnerability exploitation (one of the important means of evaluating new vulnerabilities) have always been research hotspots in the security field and continue to receive close attention from scientific research, enterprises, and government agencies.

[0109] Phase 2: This phase responds quickly and is easy to get priority treatment. Once a new security vulnerability is discovered and confirmed, the software maintainer will respond actively to quickly develop, review, and process vulnerability repair patches. Statistics show that the maintenance personnel's response speed and degree of attention to security vulnerabilities and security repair patches are significantly higher than other issues.

[0110] Phase 4: Phase 2 Research shows that it is crucial for software users (security software engineers, operating system distributors, software integrators, operation and maintenance engineers, etc.) to identify security vulnerability repair patches and apply them to software systems as soon as possible through patch annotations, especially by clearly informing that the patches are to fix security vulnerabilities and clearly giving the corresponding CVEID. However, research has found that software maintainers often fix security vulnerabilities silently, that is, it is very common for the code part of the vulnerability repair patch to not provide security descriptions and CVEID information, so that users (even professional security engineers) face challenges in identifying security vulnerability repair patches, avoiding omissions and applying security patches as soon as possible. Based on these observations and analyses, the main research motivation of this invention is to develop an intelligent automatic identification tool for security repair patches, realize timely identification and notification of vulnerability repair patches, reduce the workload and omissions of manual identification, and promote the timely application of security patches.

[0111] 1.2 Introduction to patch classification and types

[0112] Patch and patch file: A patch is a program package used to fix a defect, usually released in the form of a patch file. A patch file may contain one or more patches, and different patches have different functions. When a patch file is loaded from a storage medium into the Cache patch area by a user, the patch in the patch file will be assigned a unit number that is unique in this Cache patch area, which is used to mark, manage, and operate each patch. The unit number of the patch starts from 1 and is numbered sequentially. For example, if there are 3 patch units in a patch file, the legal patch unit numbers are 1, 2, and 3.

[0113] Incremental patches: All patches in a patch file are incremental patches. Incremental patches mean that each patch unit is dependent on the patch unit before it. In other words, if there are three patch units in a patch file, patch No. 3 must be run after patches No. 1 and No. 2 take effect, and patch No. 3 cannot be run directly alone.

[0114] Common patches and temporary patches: Patches are divided into two types: Common patches are patches released through the version release process. Temporary patches are patches that are not released through the version release process and are used to temporarily solve urgent problems and requirements. Common patches always include the functions of the previous temporary patches, thus replacing the previous temporary patches. The type of patch only affects the patch loading process - the system will delete all temporary patches in the system before loading the common patch.

[0115] Hot patching: It is a fast and low-cost way to fix defects in product software versions. Compared with upgrading software versions, the main advantage of hot patching is that it will not interrupt the services currently running on the device, that is, the defects of the current software version of the device can be fixed without restarting the device.

[0116] 1.3 Patch Status

[0117] Each patch has its own status, which can only be switched under the intervention of the user's command line. The relationship between patch status switching and command operation is as follows: Figure 1As shown in the figure, IDLE, DEACTIVE, ACTIVE and RUNNING represent different states of the patch, and loading, temporary running, confirming running, stopping running, deleting, installing and uninstalling represent patch operations, which correspond to the commands patchload, patchactive, patchrun, patchdeactive, patchdelete and patchinstall, undopatchinstall respectively. The direction of the arrow indicates the direction of state change. For example, if the patchactive operation is performed on a patch in the DEACTIVE state, the patch state will change to ACTIVE. Figure 1 In the initial state (IDLE), the patch has not been loaded yet and patch operations such as installation and running cannot be performed. Figure 2 As shown in the figure (assuming that a maximum of 8 patches can be loaded into the system patch area). After the system restarts, all patches in the IDLE state remain in the IDLE state. Figure 2 In the DEACTIVE state, the patch has been loaded into the Cache patch area, but has not yet been run. Assuming that the patch file to be loaded by the user contains 7 patches, these 7 patches will be loaded into the Cache patch area after version verification and CRC verification. The successfully loaded patches are in the DEACTIVE state. At this time, the patch status in the system is as follows: Figure 3 After the system restarts, all patches in the DEACTIVE state remain in the DEACTIVE state. Figure 3 , Activation status (ACTIVE): indicates that the patch has been temporarily run, that is, the patch will no longer take effect after the device is restarted. Figure 3 If the user activates the first five patches, the status of the first five patches will change from DEACTIVE to ACTIVE. At this time, the status of the patches in the system is as follows: Figure 4 After the system restarts, all patches in the ACTIVE state will become DEACTIVE state. Figure 4 , confirm the running status (RUNNING): It means that the patch has been permanently run, that is, the patch will continue to take effect after the device is restarted. Figure 4 There are 5 patches in ACTIVE state. After the user confirms to run the first 3 patches, the status of the first 3 patches will change from ACTIVE state to RUNNING state. At this time, the patch status in the system is as follows: Figure 5 After the system restarts, all patches in the RUNNING state will remain in the RUNNING state.

[0118] 1.4 Differences between virtual patches and traditional patches

[0119] Compared with traditional patching technology, virtual patching also has the following advantages.

[0120] (1) Virtual patches provide immediate protection within hours of known vulnerabilities being announced.

[0121] (2) Software patches can be tested and deployed in a timely manner according to established processes to prevent known system vulnerabilities from being attacked.

[0122] (3) Check and purify network data according to host-oriented rules, which can effectively correct or block applications that may attack vulnerabilities. Deploying or uninstalling rules will not affect the core operating system at all. Therefore, if any problems occur in the system, just turn off the rules.

[0123] (4) Old applications or systems no longer have patches available, but virtual patches can provide effective patch protection for operating systems and applications that are no longer supported by the original system or program manufacturer, thereby extending the service life of the old system and saving upgrade and transformation costs.

[0124] (5) Fake patches can effectively solve the blue screen and business interruption caused by patch updates, thereby reducing operation and maintenance risks. Using virtual patches does not require scheduling downtime in advance and can also ensure that applications are protected from vulnerabilities.

[0125] 1.5Cache patch construction process method

[0126] The process of hot patching is to first use the compiler to make the hot patch source code into a loadable dynamic link library, then use the loader to load the hot patch into the address space of the target process, and finally replace the original code with the new code after the consistency model check is confirmed to be safe, completing the online repair process. The hot patch itself and the hot patch loader are introduced below. The hot patch itself varies from patch to patch, and the loader is universal. Assume that there is a hot patch loader Loader, a target process T, and a hot patch patch.so, and the func function of the target program is replaced with func_v2.

[0127] (1) Hot patch production

[0128] 1) Write the hot patch source code and compile it into a hot patch patch.so in the format of a dynamic link library. Patch.so contains the information of func and func_v2.

[0129] 2) When the hot patch patch.so is loaded into the address space of the target process T by the loader, the address of func is found through the dlsym call, and the entry instruction of func is changed to be writable, and at the same time, it is changed to jump to func_v2.

[0130] 3) At this point, all calls to func will be redirected to func_v2. After func_v2 is executed, it returns and the program continues to run.

[0131] (2) Hot Patch Loader

[0132] 1) The loader finds the entry address of the dlopen function of the target process T.

[0133] 2) Loader attaches to the target process T through ptrace. Loader puts the name of the hot patch into the stack of the target process T and sets the IP register to the address of the dlopen function.

[0134] 3) Loader enables the target process T to continue running. Because the IP register has been set to the entry point of the dlopen function, the target process T will call dlopen to load the hot patch into T's address space.

[0135] If you need to make a hot patch, you only need to write patch.so yourself. Loader is universal, and patch.so only requires a few lines of code to make corresponding replacements.

[0136] (3) Hot patch implementation

[0137] 1) During the execution of dlopen by the target process T, the function func_v1 replaces the function func during the loading process through the constructor function pre-written in the hot patch (dynamic link library).

[0138] (4) Hot Patch Loader

[0139] 1) Loader obtains the dlopen entry address in the target process T address space

[0140] The dlopen function is provided by libdl. Not all programs load libdl. Fortunately, libc provides a function with the same function, libc_dlopen_mode, and the parameters accepted are the same as dlopen. Unless there are special circumstances, all programs will load libc. So you need to find the function entry address of libc_dlopen_mode in the target process T address space.

[0141] Libc will be loaded to different base addresses in different processes, but the offset of the address of the function in libc relative to the base address remains unchanged.

[0142] Through the / proc / pid / maps of the Loader and the target process T, we can get the base address of libc loaded in the Loader and the target process T. By running dlsym through the Loader, we can get the address of libc_dlopen_mode in the Loader. In this way, we can get the address of libc_dlopen_mode in the target process T (Loader_dlopen-Loader_libc+T_libc).

[0143] 2) Loader uses ptraceattach on the target process T and saves the register information of T at this time.

[0144] 3) Set the %RIP of the target process T to point to dlopen, put the string of the hot patch name into the stack, write the address of the string into %rdi, and write the value of RTLD_NOW into %rsi as the flag of dlopen. At the same time, set the return address of dlopen to the illegal address 0x0 (push 0x0 into the stack), so that the loader can capture the SIGSEGV signal generated by the target process T and regain control of T.

[0145] 4) Loader enables the target process T to continue running. After T executes dlopen, the SIGSEGV signal generated by T is captured by Loader, and Loader regains control of the T process.

[0146] 5) Loader obtains the return value of dlopen by reading the %rax register of the target process T at this time, restores T's initial execution state, and finally releases control over T.

[0147] (5) Hot patch repair process

[0148] It is loaded into the target process by the Loader, registers its own information to the CoreRuntime, and uses the replacement code contained in it to replace the problematic function after activation. The collaboration between the components is shown in the figure below. The Creator tool generates a hot patch module based on the program source code and patch, and then the Loader loads the hot patch module into the address space of the target process Process. Finally, the hot patch and the universal runtime CoreRuntime complete the hot fix together. As a client program, the Loader tool operates the target process Process, including loading, activating, rolling back, unloading, and viewing hot patches. The Loader uses ptrace calls. Through ptrace, the Loader can read and write the cache and registers of the Process, change the running state of the Process, and capture the signals of the Process. In this way, the Loader can stop the running of the Process, and modify the cache and registers according to the AMD64ABI, so that the Process executes functions such as dlopen, loads the hot patch into the address space of the Process, or performs other hot patch operations. After the hot patch is loaded, it can be seen in the / proc / pid / maps file. How the Loader uses ptrace to load hot patches has been described in detail in the previous article, so I will not repeat it here. The Loader will then stop all threads of the Process and prepare to activate the hotfix. At this time, the Loader needs to perform a consistency check, that is, check the activation of the hotfix for all current threads.

[0149] When stopping all threads, you first need to get all thread information. You can get thread information by interacting with libc in the process through the libthread_db library, or you can get thread information directly from the kernel through the / proc / pid / tasks / directory. After stopping all threads, you need to get all thread information again to check if there are any new threads. If so, stop the new threads. Repeat the above steps until no new threads appear.

[0150] (6) Automatically generate hot patches

[0151] The basic principle of hot patching is to replace the old function with the new function, that is, to replace the complete function. The patch may contain modifications to one or more functions, and all of these modified functions will be replaced. The hot patch first puts the new function into the cache of the target process, and then modifies the entry of the old function to jump to the new function. The most important part of automatically generating hot patches is to automatically generate the binary code of the new function, also known as the replacement code. When generating the replacement code, it mainly consists of the following parts:

[0152] 1) Automatically generate replacement code. 2) Analyze the symbols used in the replacement code. (3) Compare the previous and next codes to generate replacement code.

[0153] In order to generate replacement code, we first need to know which functions have changed after the code repair, and then generate replacement code based on these changes. A binary comparison method is used to extract all the information required to generate replacement code by comparing the binary of the original program and the binary of the repaired program.

[0154] Choose to compare at the object file level. The benefits of doing so are obvious:

[0155] First, any changes in the source code will be reflected in the binary code of the target file. For example, if the parameter of a function in the header file .h file changes from int to longlong, the .c file that calls this function will not change due to the implicit type conversion. If the code comparison is done at the source code level, even after preprocessing, it will not be found that the .c file has changed.

[0156] Secondly, there is no need to deal with language-level features, such as the inline keyword, implicit type conversion, macros, etc. These language-related features may become more complex as the language develops, and we do not want hot patches to be limited to a certain language. C, C++, and assembly are all languages ​​that we hope to be able to handle.

[0157] Finally, we only care about the binary representation of the code. At the target file level, the binary code and code composition information are the most complete, and it is most reasonable to compare the before and after codes here.

[0158] Therefore, the idea of ​​generating replacement code is to extract the difference parts by comparing the target files compiled before and after, and form the replacement code. Comparing target files also faces many challenges, mainly in how to extract the changed functions. Since all function codes in the target file are placed in the .text segment by default, and the relative address jumps in the .text segment are all relative to the .text segment. If a function is changed, even if it is only a line of code, the subsequent relative address jumps are likely to change (because the symbol position has changed).

[0159] Compile the target application code and the repaired code separately, and compare the several target files generated by the two compilations one by one; Fig.11 As shown:

[0160] First, compile the original source code and keep all the target files generated in the intermediate process. Then, apply the repair patch to the original source code and compile it again. The build system (make) generally only compiles the changed source files and keeps the newly generated target files. If there is no build system or the build system does not work as expected, all target files can be kept. Finally, compare the newly generated target file with the corresponding target file compiled from the original code, extract the difference, form the replacement code, and generate a hot patch.

[0161] During the comparison process, we hope to be able to compare at the function level, so that only the changed functions can be extracted, and the generated replacement code is address-independent, because the replacement code may be loaded to any cache address. The GCC compiler provides the compilation options of -ffunciton-sections and -fdata-section, which are used to put functions and variables into independent segments in the target file (each function code is represented by an independent segment). In this way, the compiled function codes are address-independent and more universal binary, which can be extracted from the replacement code and loaded into any location in the cache for execution. When comparing the previous and next target files, the comparison is made at the ELF segment level (that is, the function level, because the functions are in their own independent segments). Because the target file is an ELF file and complies with the general standards, the ELFHeader of the target file can be parsed to find the beginning of the segment (SectionHeader), thereby finding all the segments. It is recommended to use some ELF parsing libraries, such as libelf, libbfd, etc.

[0162] Compare the code segments in the target files one by one. The content of the segment is the function code. Find the function that has changed:

[0163] First, the segment sizes are compared. If the sizes are different, the function has changed.

[0164] Next, the contents of the segments are compared. If a byte is different and the byte is not part of a redirection, the function has changed. If it is a redirection, check if the contents of the instruction after the redirection calculation are the same. If they are different, the function has changed (a different function or variable is referenced).

[0165] Finally, if neither the size of the segment nor the contents of the segment have changed, then the function has not changed.

[0166] It should be noted that if the patch modifies macros or inline functions, it is not possible to extract only the differences of macros or inline functions, because macros and inline functions will be placed in their calling functions during the compilation process, and all calling functions will be changed, so all called functions are extracted. At this time, the replacement code cannot be run directly, because the replacement code may also contain references to other symbols, which need to be resolved before running the replacement code.

[0167] (8) Symbol resolution in replacement code

[0168] The replacement code only contains the changed function codes, which may reference other unchanged symbols (functions or variables), so the referenced symbols need to be manually redirected according to the symbol reference rules (generally relative addresses relative to PC addresses). There are two main challenges in resolving symbol addresses:

[0169] Find the addresses where the symbols of a running program are located.

[0170] If there are two or more symbols with the same name, find the correct one.

[0171] The address of the symbol is determined at the time of the final link. If the executable file is a pie (position independent executable) or a dynamic link library, the address of the symbol is a relative address, which is the offset of the address of the code segment of the executable file or dynamic link library in the cache. The calculation formula is Addr = Base + Offset. In other cases, the address of the symbol is an absolute address and does not need to be calculated.

[0172] Symbols with the same name may appear multiple times in an executable file (for example, static variables with the same name are defined in two files), and the correct symbol needs to be found. After linking, the symbol table in the executable file will follow some fixed rules. Symbols in the same source file will be recorded together continuously, and at the beginning of the record there will be a symbol of type STT_FILE, with the name of the source file.

[0173] (9)POC: Generate replacement code and symbol resolution

[0174] Perform POC verification on the key steps in generating replacement code. Compile the source code and the repaired source code respectively to generate To and T-patched.o. It can be found that the func function has changed before and after, and the instruction at address 0x4 is different. (Other functions remain unchanged and are omitted). Therefore, the .text.func segment in T-patched.o is extracted. This completes the extraction of the replacement code. Because the func function in T-patched.o references the print function at position 0xa, the print symbol needs to be parsed. When the replacement code (hot patch) is loaded into the target process cache, the four bytes of 0xa-0xd are redirected and this redirection is recorded, type R_X86_64_PLT32, Addend-4, symbol print.

[0175] When the replacement code is loaded into the target process, the address where the replacement code is loaded can be determined. Then, according to the previously recorded redirection information, calculation (V=S+AP) is performed, and the position (4 bytes) of func offset 0xa is written. After redirection, the func function in the replacement code can correctly reference the print function in the original program. Finally, the behavior of the T program after the hot patch is applied is observed through GDB, and the static and dynamic forms of the replacement code are verified through objdump and gdb.

[0176] 2. Kernel-level multi-point hook and associated function replacement

[0177] Ⅰ. Kernel (hook) level replacement algorithm

[0178] 1. Random algorithm (RAND): Randomly determine the cache block to be replaced. Its implementation is relatively simple, but it is not based on the principle of locality of program access, so the hit rate may be low. 2. First-in-first-out algorithm (FIFO): Select the earliest line to be replaced. It is relatively easy to implement, but it is not based on the principle of locality of program access, and some program blocks that need to be used frequently (such as loop programs) may also be replaced as the earliest blocks to enter the cache. 3. Least Recently Used Algorithm (LRU): Based on the principle of locality of program access, storage lines that have not been accessed for a long time in the recent period are selected as replacement lines. The average hit rate is higher than FIFO, and it is a stack-type algorithm. The LRU algorithm sets a counter for each line. Every time the cache is hit, the hit line counter is cleared to 0, and the counters of other lines are increased by 1. When replacement is required, the count values ​​of each specific line are compared, and the line with the largest count value is swapped out. 4. Least Frequently Used Algorithm (LFU): Swap out the storage line that has been accessed the least times in a period of time. A counter is also set for each row. After a new row is created, the count starts from 0. Each time it is accessed, the counter of the accessed row is increased by 1. When replacement is needed, the count values ​​of each specific row are compared and the row with the smallest count value is replaced.

[0179] According to the replacement algorithm, calculate the number of cache hits. The meaning of a hit is simply to take the repeated content directly from the cache. That is, the content to be accessed is already in the cache. How to identify whether the tag hits or not? Associative memory: compare tags in parallel. If there is a tag that is the same as the tag of the address to be accessed and the valid bit is 1, it is a hit. Associative memory: compare tags according to the cache block number mapped to it. If the tags are the same and the valid bit is 1, it is a hit. If the tags are different, replace them directly.

[0180] Ⅱ.Cache strategy replacement

[0181] The content in the cache is a copy of the main memory block. When the content in the cache is updated, it is necessary to select a write operation strategy to keep the cache content consistent with the main memory content. At this time, there are two situations. Cache write hit processing method: (1) Full write method: When the CPU writes to the cache, the data must be written to the cache and main memory at the same time. When a block needs to be replaced, it is not necessary to write this block back to the main memory. It can be directly overwritten with the newly transferred block. (2) Write back method: When the CPU writes to the cache, it only needs to change the content of the cache, and does not write it to the main memory immediately. It is only written back to the main memory when this block is swapped out. When using this strategy, each cache line must set a flag bit (dirty bit) to reflect whether this block has been modified by the CPU.

[0182] For the implementation of LRU and MRU strategies, a table needs to be maintained in a set. The length of the table is equal to waynum, and the content of the record is wayid. Assume waynum = 4, pos_0 is LRU position, pos_3 is MRU position

[0183] If the LRU replacement strategy is adopted, after the new request is assigned a wayid, this id is filled in the position close to the MRU; when replacement is needed, the original way content corresponding to pos_0 is always removed, and after removal, pos_0id is moved to the MRU position, that is, it becomes pos_3, and the original pos_3 / pos_2 / pos_1 moves to the right to become pos_2 / 1 / 0 respectively. If a cache hit occurs, the hit wayid is moved to a position close to the MRU, and the id at the original position is moved right in sequence.

[0184] If the order of requestaddr is 0x100040, 0x200040, 0x300040, 0x400040, 0x100040, 0x500040, the first four allocated wayids are 0, 1, 2, 3. At the second time of 0x100040, the wayid of pos_0 is transferred to the MRU position, that is, pos_3, and the original pos_3 / pos_2 / pos_1 moves to the right. At 0x500040, Cache miss & no freeway, the original content of wayid (way1) corresponding to pos_0 is removed, and the new request enters way1. For the wayid table, pos_0 shift to MRU, and the others move to the right. Fig. 22 shown.

[0185] With the MRU replacement strategy, after a new request is assigned a wayid, this id is placed near the LRU position. When a replacement is needed, the original way content corresponding to pos_0 is always removed, but the pos_0id remains at the pos_0 position. The next time a replacement is made, this id is still removed. If a cache hit occurs, the hit wayid is moved to a position close to the LRU position, and the id at the original position is moved left in sequence.

[0186] If the requestaddr sequence is 0x100040, 0x200040, 0x300040, 0x400040, 0x100040, 0x500040, the first four allocated wayids are 0, 1, 2, 3. At the second time of 0x100040, the wayid of pos_3 is transferred to the LRU position, that is, pos_0, and the original pos_3 / pos_2 / pos_1 moves to the left. At 0x500040, Cache miss & nofreeway, the original content of wayid (way0) corresponding to pos_0 is removed, and the wayid table remains unchanged.

[0187] PseudoLRU is called pseudo LRU, which is also a commonly used replacement algorithm.

[0188] The kernel patching solution uses a kernel subsystem to redirect old functions to new functions. When a live kernel patch is applied to a system, the following happens: The kernel patch module is copied to this directory and registered to be reapplied to the kernel on the next boot. It is loaded into the running kernel and the patched function is registered with a mechanism with a pointer to the location of the new code in the cache. When the kernel accesses the patched function, it is redirected by a mechanism that bypasses the original function and redirects the kernel to the patched version of the function.

[0189] III. Function file replacement

[0190] To achieve function replacement, we need to implement a CHookApi class, which completes the main interception function. Moreover, the MainHookDll module is the module that will be injected into other processes of the system in the future. It is very difficult to call functions remotely, so when designing this module, it should be allowed to automatically perform interception initialization and other tasks after being loaded. In this way, we only need to let the remote process load HOOK, and then MainHookDll.dll can automatically perform other operations to HOOK the relevant API of the process. DT_NEEDED describes the required dynamic library name, DT_REL describes the relocation table address, DT_JMPREL describes the relocation table address (this table is used for lazy linking), and T_PLTGOT global offset table address. At this time, the interpreter program can load the required dynamic library into memory. The relevant information of each loaded library will be recorded in the link_map structure, which is a linked list that saves all dynamic information.

[0191] File replacement is simply composed of the following four parts: elf file header, programheader and sectionheader. The programheader is used at runtime, and the sectionheader will not be loaded into the program running space, but they can be specified with the load address of the segment during compilation. Of course, this link script .lds is generally the default by gcc.

[0192] The first step is to load the elf file header and check the file type and version. It is important to find the address of the programheader and the number of headers. If the connector script is the default, the elf file header will be loaded at the address 0x804800.

[0193] The second step is to load the programheader, then scan the programheader and find a programheader of type PT_INTERP. This header contains the address of the interpreter. At this time, the elf file header of the interpreter program is loaded. Generally, it is like this:

[0194] INTERP0x0001340x080481340x080481340x000130x00013R0x1[Requestingprograminterpreter: / lib / ld-linux.so.2]

[0195] The third step is to scan the programheader. If the type is PT_LOAD, load the segment.

[0196] The fourth step is to determine whether an interpreter program is needed. If so, load the interpreter program and set the program entry to the address of the interpreter program. Otherwise, it is the entry of the application program itself. Disassemble to the _start label.

[0197] The fifth step is to set the parameters passed in by the command line and other information required by the application.

[0198] In the sixth step, the interpreter program starts running, loads the libraries required by the program, and fills in the address information in the redirection symbol table.

[0199] Define vulnerability features for the code and description parts of the patch merged into the kernel source code, build a machine learning model, and train a classifier that can identify security vulnerability patches. The implementation of this method mainly includes three steps: 1) How to continuously collect and annotate security vulnerability patches and non-security patches; 2) Analyze the characteristics of security vulnerability patches compared with other bug fixes and function enhancement patches, and define and extract features from the original patch files; 3) Design and implement a machine learning model, and use the collected data set to train and generate a classifier that can identify vulnerability fix patches. The main contributions of the present invention include three aspects: 1) A machine learning modeling method that can automatically identify vulnerability repair patches is given, and how to define and extract code features and log features is given in detail, as well as how to model the joint code and log based on the semi-supervised method. Taking the representative Linux kernel as an application example, the experiment shows that the method improves the recognition accuracy to 91.3%, the accuracy to 92%, the recall rate to 87.53%, and the false alarm rate to 5.2%, so it has practical value, and the method has good scalability; 2) A tool system for continuously collecting and annotating security vulnerability repair patches and bug repair patches is implemented, and its design and implementation details are given. The system can be expanded to support other open source software managed by version control tools such as . 3) NVD and open source software community vulnerability notifications should not be blindly believed or overly relied on, because their comprehensiveness, effective prompts and timeliness are insufficient. Analysis shows that the quality of their notifications has problems such as omissions, errors, and non-updates. This requires the combination of manual and automated identification tools to actively identify vulnerability repair patches and repair them in a timely manner.

[0200] IV. Continuous collection and annotation of patches

[0201] Each source code patch (patch for short) consists of logmessage and code. The former is a natural language description of the patch's properties and behavior, and the latter specifies the modification (addition, deletion, replacement) of the source code file. Software evolves by merging patches, which can be divided into three types of patches: bug, function, and vulnerability repair. Because patch description information and patch code are highly arbitrary, it is difficult to directly and automatically classify (label) patches based on patch information. Model training and updating require sufficient labeled patches, which requires methods that can continuously collect and label patches, and design and develop automated tools.

[0202] V. Methods for collecting and annotating vulnerability fix patches

[0203] Because it is difficult and unreliable to identify security vulnerability patches directly from the repository based on patch submission information. However, the vulnerabilities assigned CVEID in the NVD database are confirmed and reliable. Therefore, we adopted the method of parsing information from the NVD database and then reversely tracing the kernel's git source repository. The method flow is as follows: Fig. 27 as shown.

[0204] This paper designs and constructs quantitatively calculable feature indicators based on the statistical laws and kernel security vulnerability experience discovered from relevant empirical studies, and gives a specific extraction method for each feature, which is summarized as follows.

[0205] F01: Number of function bodies crossed, measure of locality. F02: Number of files changed, measure of locality. F03: Number of modified hunks, locality and complexity. F04: Number of lines added, logical complexity. F05: Number of lines deleted, logical complexity. F06, F07: Number of IF branches added / deleted, logical complexity. F08, F09: Number of loops added / deleted (for, while, goto), logical complexity. F10, F11: Number of bracket expressions added / deleted, logical complexity. F12, F13: Number of files added / deleted, locality, counted by matching the patterns "--- / dev / null" and "+++ / dev / null" respectively. F14, F15: Number of sizefo, variable address, and pointer arithmetic operations added / deleted. F16 to F19: Number of function calls added / deleted, logical complexity. F20, F21: Number of function returns added / deleted, complexity. F22 to F25: Number of continue and break controls added / deleted. F26, F27: increase / delete the number of copy operation lines, complexity. F28, F29: increase / delete relational operations (>,!=,<,|,&&, etc.). F30, F31: increase / delete the number of macros, such as #ifdef, #define, #undef, #endif, #elif. F32: |F04-F05|, the addition minus the deletion, take the absolute value. F33: F04+F05, the addition plus the deletion. F34 to F54: Features F06 to F11, F14 to F31 are features calculated in a similar way to F32 and F33. The Logmessage part of the patch is an example) generally describes the summary, motivation, changes, contributors, reference links, etc. of the patch; it is a natural language text expressed in English. Therefore, natural language processing (NLP) can be used for feature extraction. The present invention uses a bag of words (BOW) model to extract features from the logmessage of the patch. The feature extraction process is as follows Fig.28 shown.

[0206] The detailed description of the feature extraction process is as follows:

[0207] 1) Logmessage text extraction. Extract the Logmessage part of each patch and store it in files named with the commitHash string. These files are organized and managed according to three directories: vulns, nonvulns, and unknows. 2) Data preprocessing. The original logmessage text contains noise interference information and needs to be cleaned before feature extraction. 3) Construct a corpus. Construct the BOW corpus with all log documents managed in the vulns, nonvulns, and unknows directories after preprocessing in the previous steps as document units. The corpus construction process includes: collecting all words; counting the word frequency in the global space of the corpus, denoted as TFg; the top 0 words with the highest word frequency constitute the vocabulary (Vocabulary); calculating the inverse document frequency (inersedocumentfrequency, denoted as IDF) of 50 words in the global space of the corpus. The selected 50 words constitute the feature component of each log document. The word frequency in the corpus is

[0208] Where: i——the number of times word i appears in all log documents; Ng——the sum of the number of times all words appear in the corpus. The calculation of IDF requires the calculation of DF (document frequency of vocabulary) first: DFi=|Di|, where Di={dj|ti is a word in the corpus, ti∈dj}. Where: D = {d1, d2, ..., di, di+1, ..., dn|di} - log document; n - total number of documents. 4) Generate log message features. With the vocabulary, TFg, and IDF information of the corpus obtained by statistical learning in step 3, the TF-IDF feature representation (denoted as TFIDF) can be calculated for each log message. The feature representation extracted from any document di is

[0209] TFIDF i =||[TFIDF i1 ,TFIDFi2,…,TFIDFij,…,TFIDF iv ||2

[0210] Where V = |vocabulary| = 50, the feature weight component TFIDFij is TFIDF ij =TF ij ×IDF j where TFij is the number of times vocabulary word j appears in document di.

[0211] Step 4 of the process completes the feature extraction of the logmessage document. 50 features are extracted and each log document is represented by a 50-dimensional vector. The weight component of the vector is the TF-IDF value of the corresponding feature.

[0212] VI. Vulnerability Patch Classifier Model

[0213] The collected training data sets include labeled data sets (vulns, nonvulns) and unlabeled data sets (unknowns). The number of unlabeled data is much larger than that of labeled data sets, so we try to adopt the semi-supervised Co-Training[24-25] method to model. Vulns are regarded as positive data points P, nonvulns (including functional and simple bug fix patches) are regarded as negative data points N, and unknowns are regarded as unlabeled data points U. P and N constitute the labeled data set L.

[0214] Algorithm 1 describes the process of training a classifier that can identify security vulnerability patches. During the execution of the algorithm, nP=2, nN=4, nU=80, and iter=30 are set; Algorithm 2 is the process of using the classifier learned by Algorithm 1 to make predictions. Because the classifier has two components, namely, patch-based Code feature training and patch-based log feature training, this algorithm describes how to integrate these two classifiers in the prediction and reasoning stage to build a unified security vulnerability patch identification classifier.

[0215] This model is based on disassembly technology and uses several concepts in compiler theory. Function call graph: a directed graph that describes the calling relationship between functions in a binary file, which can be expressed as a = {{f1,…,fn}, {fe1,…,fem}}, where f1,…,fn are nodes in the directed graph, representing n functions in the binary file; fe1,…,fem are m edges in the directed graph, representing the calling relationship between functions, and fei represents an edge from function fi to function fe, indicating that fe is a subfunction of fi. Control flow graph (CFG): All statement sequences of a function can be divided into several basic blocks. A basic block is a continuous statement sequence, and the control flow enters from its beginning and leaves from its end. There can be no interruption or branch (except at the end). A method of dividing program instruction sequences into basic blocks. The nodes of the control flow graph are composed of basic blocks, representing calculations; the edges between nodes represent the control flow direction. Each function control flow graph has only one entry (a point with an in-degree of 0), but can have multiple exits (points with an out-degree of 0). An example of a function control flow graph is given, which contains 5 basic blocks and 6 edges. During the patch analysis process, the binary file is processed by disassembly technology and can be abstracted into the two directed graphs mentioned above. A represents the version of the software before the patch, and its function call graph can be expressed as: a={{a1,…,an},{ae1,…,ael}}; B is used to describe the version of the software after the patch, and the function call graph is expressed as: β={{b1,…,bn},{be1,…,bek}}. Each function in A and B is described by a CFG. The purpose of patch analysis is to find the semantic differences between A and B.

[0216] Under the above model, follow the steps below to perform patch analysis:

[0217] ① Use disassembly technology to analyze the binary code and generate function call graphs and function control flow graphs for software versions A and B before and after the patch.

[0218] ② Using the two directed graph information, for each function αi in A, find the function bj that corresponds to it in B. Considering the particularity of the patch itself, most of the code in the software versions A and B is the same, so for most of the functions in A, you can find a function with the corresponding function in B to match it. For functions that cannot be matched, they should be regarded as differences between the two versions, representing new functions or modifications.

[0219] ③ For the paired functions (αi, bj), further compare them with the information provided by the function flow chart to determine whether there are any semantic changes between the two corresponding functions. If an error is found in the function pairing during the comparison process, return to the second step and adjust the intermediate pairing results. The dotted box is the main process of patch analysis, and other modules are auxiliary modules to improve the accuracy and effectiveness of the analysis.

[0220] Compiler optimization eliminates the differences between versions A and B caused by the compiler and avoids false positives. Throughout the analysis process, human experts can adjust the intermediate analysis results of each step to make the final result more accurate.

[0221] VII. Function Identification and Description

[0222] At the binary code level, there are no clear functions in the source code. In order to match the functions in versions A and B, the binary files must first be disassembled. Using disassembly tools such as IDA-Pro [4], the function set contained in the binary file can be analyzed. The function set of A is denoted as fA = {a1, ..., an}, and the function set of B is denoted as fB = {b1, ..., bm}. If the symbol tables of A and B are available, it will be very helpful for function pairing. When the symbol table is loaded during the disassembly of the binary code, the function name and parameters, variables, and library function names called can be obtained. Functions with the same name and functions that only contain static strings with the same name can be directly paired. For situations where the symbol table cannot be obtained or the symbol table is incomplete, a method for pairing functions using function structural features is introduced here. This method uses the concept of the function control flow graph mentioned above. The information that can represent the functional characteristics of the function is extracted from the function flow graph, which is called the function signature. Functions with the same signature in A and B can be considered to be functionally identical and can be paired. Obviously, the selection of signature factors is crucial and directly affects the accuracy of matching.

[0223] The information that can be used as function features include: function parameters, local variables, the number of basic blocks and edges in the function control flow graph, and the number of sub-functions called by the function. The number and type of function parameters, the number of local variables or the size of the space occupied, these function features can be used to distinguish functions at the source code level. However, there will be certain problems at the target code level. For example, there are many ways to pass parameters between functions. Usually, the compiler uses the stack (push) method to pass parameters. But some compilers use registers to pass parameters directly. At this time, the number of parameters cannot be accurately determined, and the byte alignment requirement cannot guarantee the uniformity of the number of local variables or the size of the space occupied. Therefore, it is inappropriate to use parameters and local variables as signature factors. The number of basic blocks and edges in the function control flow graph better reflects the scale and flow of the function. A considerable number of patches modify software vulnerabilities by judging certain conditions and adding some exception handling. At this time, the information of its basic blocks and edges must change. Using these two features as signature factors can effectively show the difference. In addition, the number of sub-functions is also an indispensable factor in reflecting function features.

[0224] Based on the above discussion, the structural characteristic information of a function is defined as a function signature. The specific description is as follows.

[0225] Definition 1: The signature of a function is a triple Sig(fi) = (αi, βi, ri), where αi represents the number of basic blocks in the control flow graph of function fi, βi represents the number of edges in the control flow graph of fi, and γ

[0226] i represents the number of sub-functions called by fi, that is, the out-degree of node fi in the function call graph. 3.1.2 Pairing algorithm based on function signatures Based on the definition of function signatures in, define the pairing of function αi in version A and function bj in version B, that is, P(αi) = bj, if and only if they simultaneously meet the following three conditions: the signatures of αi and bj are the same; except for bj, no other function in B has the same signature as αi; except for αi, no other function in A has the same signature as bj. Two functions that meet the above conditions can be considered to be the same function, expressed as p(αi) = bj and p(bj) = αi. The formal description is as follows:

[0227] P(aj)=bj|Sig-1(Sig(αi))|=1=|Sig-1(Sig(bj))|∧Sig(αi)=Sig(bj)(1)

[0228] After pairing the functions according to formula (1), we get an initial mapping p1:A1→B1 from the functions in version A to the functions in version B, where A1{a1,…,an}, B1{b1,…,bm}.

[0229] Mapping sequence p2,…,ph, where A1A2…Ah, B1B2…Bh. The purpose of expanding p1 is to make the functions between versions A and B pair as much as possible. The iterative algorithm for calculating pi from pi-1 is as follows:

[0230] ① Take all ai and pi-1(ai) that have entered pi-1;

[0231] ② Obtain the sub-function sets called by functions ai and pi-1(ai) through the function call graph, denoted as A′i and B′i respectively;

[0232] ③ Use the method similar to constructing p1 to construct p′i∶A′i→B′i;

[0233] ④ For ajAi-1, let pi(aj)=pi-1(aj). If ajAi-1 but

[0234] If a new pairing is added in ③, let pi(aj)=p′i(aj). From pi, pi+1 can be calculated, and this calculation continues until the number of function pairs that can be paired no longer increases. The pairing results are manually checked, and any errors can be adjusted. Then, the pairing function set is expanded using an iterative algorithm, which can prevent the cascade propagation of errors. Analysis of multiple patches shows that the above algorithm function matching ratio reaches 95%, and among the nearly 30,000 matching pairs of functions, no more than 10 pairs have matching errors.

[0235] Assessing vulnerability risks is a prerequisite for selecting vulnerability repair strategies, so many scholars have improved the CVSS scoring method to influence repair strategies. A vulnerability probability distribution model is proposed to evaluate the probability of vulnerability exploitability and patch exploitability, laying the foundation for further vulnerability repair.

[0236] VIII. Model Design

[0237] Vulnerability remediation based on vulnerability type clustering (VR-VTC) consists of three steps.

[0238] Step 1: Vulnerability clustering analysis.

[0239] (1) PSO-K-means clustering algorithm [9]: PSO (particle warm optimization) algorithm is used to find cluster centers, and K-means algorithm is used to cluster vulnerabilities after preprocessing. (2) Quantitative analysis of vulnerability type threat: The threat factor of each vulnerability type is calculated using the percentage of high risk, medium risk, and low risk of each vulnerability type.

[0240] Step 2: Vulnerability severity assessment.

[0241] (1) According to the host vulnerability report obtained by the vulnerability scanner based on OVAL (open vulnerability assessment language), the latest released relevant security patches are found. (2) The proposed vulnerability severity assessment method based on rough sets performs quantitative and qualitative evaluation on each vulnerability in the host.

[0242] Step 3: Select vulnerability repair strategy.

[0243] (1) Construct a hierarchical target host model for vulnerability types. The target host model is decomposed from top to bottom into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. A "bottom-up, first local and then global" vulnerability repair strategy is adopted. (2) A hierarchical vulnerability repair method based on vulnerability type is proposed, and a fine-grained vulnerability repair strategy is finally given. (3) The corresponding repair strategy is executed according to the vulnerability priority level.

[0244] VIII. Threat Factors by Vulnerability Type

[0245] The percentages of high risk, medium risk, and low risk in vulnerability type (VT) are expressed as follows:

[0246]

[0247] Among them, PVTi,high represents the high-risk percentage of vulnerability type VTi; NVTi,high represents the number of vulnerabilities with high risk level in vulnerability type VTi; AllNVTi represents the number of all vulnerabilities of vulnerability type VTi; PVTi,medium represents the medium-risk percentage of vulnerability type VTi; NVTi,medium represents the number of vulnerabilities with medium risk level in vulnerability type VTi; PVTi,low represents the low-risk percentage of vulnerability type VTi; NVTi,low represents the number of vulnerabilities with low risk level in vulnerability type VTi. Based on the percentages of high risk, medium risk and low risk of vulnerability type, the vulnerability type threat factor (VTTF) can be obtained, and its calculation formula is:

[0248] VTTFVTi=w1×PVTi,high+w2×PVTi,medium+w3×PVTi,low(3-40)

[0249] Among them, ω1, ω2, and ω3 represent the weights of the percentages of high-risk, medium-risk, and low-risk vulnerabilities, respectively, and satisfy ω1+ω2+ω3=1. The weight values ​​are based on the expert experience of security managers, and the threat factor of each vulnerability type is calculated according to formula (4), and then the value range of the threat factor VTTFVTi of all vulnerability types is determined, and finally the vulnerability type threat factor score is graded.

[0250] IX. Selection of repair strategies based on vulnerability type

[0251] The present invention proposes a method for constructing a hierarchical target host model oriented to vulnerability types. The hierarchical relationship of the target host model is decomposed into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. The strategy of "bottom-up, first local and then overall" is adopted. The specific steps are as follows:

[0252] (1) Using the OVAL-based vulnerability scanner

[12] , we obtain a total of N vulnerabilities Vi for the host Host, where the value range of i is 1≤i≤N.

[0253] (2) The vulnerability severity assessment method based on rough sets is used to calculate the severity score QS of each vulnerability and obtain the corresponding vulnerability hazard level.

[0254] (3) For M vulnerability types, vulnerabilities Vi of the same type are grouped into a vulnerability type VTk group, where the value range of k is 1≤k≤M.

[0255] (4) Put all vulnerabilities with a vulnerability type threat level of "weakly harmful" into the Ggreen group. Similarly, put vulnerabilities with a "medium-harm" and "strong-harm" level into the corresponding Gyellow and Gred groups, respectively.

[0256] The present invention proposes a hierarchical vulnerability repair method based on vulnerability type, the steps of which are:

[0257] (1) In the Ggreen group, the corresponding repair strategy is implemented for each vulnerability according to the Ggreen threat level rules. If the QS is high risk, the priority level is P1, and the patch installation time is no more than 1 week; if it is medium risk, the priority level is P2, and the patch installation time is no more than 5 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 9 weeks. (2) In the Gyellow group, the corresponding repair strategy is implemented for each vulnerability according to the Gyellow threat level rules. If the QS is high risk, the priority level is P1, and the patch installation time is no more than 2 weeks; if it is medium risk, the priority level is P2, and the patch installation time is no more than 6 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 10 weeks. (3) In the Gred group, the corresponding repair strategy is implemented for each vulnerability according to the Gred threat level rules. If the QS is high risk, the priority level is P1, and the patch installation time is up to 3 weeks; if it is medium risk, the priority level is P2, and the patch installation time is up to 7 weeks; if it is low risk, the priority level is P3, and the patch installation time is up to 11 weeks. 3.1 Vulnerability clustering result analysis This paper uses 65295 security vulnerability samples published by the NVD database during 2004-2015 for experiments, and uses the PSO-K-means algorithm to perform cluster analysis on all vulnerability samples. CNNVD

[0258] (China National Vulnerability Database of Information Security) manually marked all vulnerabilities by vulnerability type, and the result showed 26 vulnerability types. The vulnerability type corresponding to each vulnerability was obtained through the crawler program, and the performance was compared with the clustering result obtained by the PSO-K-means algorithm. The various parameter values ​​of the PSO-K-means algorithm are: the population size of the particle swarm m = 65295, the number of clusters k = 26, the maximum number of iterations maxTime = 200, the fitness variance threshold threδ of the particle swarm = 0.1, and the frequent dictionary keylib obtained by Algorithm 1 has 50. Therefore, the size of KSset is a two-dimensional vector of 50×65295. The horizontal axis represents the vulnerability type, and the vertical axis represents the number of vulnerabilities. It can be seen from the experimental results that the PSO-K-means algorithm has achieved a good clustering effect and can automatically and effectively classify and manage vulnerabilities.

[0259] Ⅹ. Vulnerability type threat level analysis

[0260] The percentage of high-risk, medium-risk, and low-risk vulnerabilities of each vulnerability type. Since the percentage distribution of vulnerability hazard levels for each vulnerability type is a dynamic variable, according to the expert experience and knowledge of security managers, the higher the score of the vulnerability hazard level, the higher the corresponding vulnerability hazard level percentage weight. Based on the score range of the three vulnerability hazard levels, the percentage weights of high-risk, medium-risk, and low-risk vulnerabilities are set to ω1=0.6, ω2=0.3, and ω3=0.1 respectively.

[0261] Vulnerability repair strategy analysis, using OVAL vulnerability scanner to detect vulnerabilities on host A in the LAN, and obtain 11 vulnerability information as shown. The vulnerability set is calculated using the vulnerability severity assessment method RAR based on rough sets to calculate the severity score of each vulnerability and obtain the corresponding vulnerability hazard level; the NVD database has been automatically labeled with vulnerability types for all vulnerability data published during 2004-2015, and the vulnerability types corresponding to the 11 vulnerabilities detected by host A are queried, and the corresponding threat levels are found. From a quantitative perspective, it can be seen that 5>v11>v7>v3>v1>v2>v4>v6>v8>v9>v10. According to the hierarchical target host model construction method for vulnerability types, vulnerabilities with a strong threat level are placed in the group Gred, including vulnerability numbers v1, v3, v4, v5, v9, and v11; vulnerabilities with a medium threat level are placed in the group Gyellow, including vulnerability number v7; and vulnerabilities with a weak threat level are placed in the group Ggreen, including vulnerability numbers v2, v6, v8, and v10. In Gred, Gyellow, and Ggreen, patch repair strategies are formulated according to their repair rules, and the relevant strategies are formulated as follows: the vulnerability numbers of P1 priority are v1, v3, v5, and v11, and their patch repair time is no more than 1 week; the vulnerability numbers of P2 priority are v7 and v9, and their patch repair time is no more than 2 weeks; the vulnerability number of P3 priority is "none"; the vulnerability number of P4 priority is v4, and its patch repair time is no more than 5 weeks; the vulnerability number of P5 priority is "none"; the vulnerability number of P6 priority is v2, v6, and v8, and its patch repair time is no more than 7 weeks; the vulnerability number of P7 priority is "none"; the vulnerability number of P8 priority is "none"; the vulnerability number of P9 priority is v10, and its patch repair time is no more than 11 weeks.

Claims

1. A method for online repairing cache patches of unknown vulnerabilities in power terminals, characterized in that: Firstly, the cache patch construction standard under heterogeneous computing platform is formulated, and the kernel-level multi-point hook and related function replacement are clarified; secondly, the cache code detection and vulnerability code segment precise positioning method of power intelligent terminal is proposed, the runtime cache patch injection replacement technology based on function redirection is proposed, and the "hot patch" repair component of power intelligent terminal is proposed.

2. According to claim 1, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: The cache patch construction process method is to first use the compiler to make the hot patch source code into a loadable dynamic link library, then load the hot patch into the address space of the target process through the loader, and finally replace the original code with the new code after confirming safety through the consistency model check to complete the online repair process.

3. According to claim 2, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: The hot patch itself and the hot patch loader specifically include: (1) Hot patch production Write the hot patch source code and compile it into a hot patch patch.so in the format of a dynamic link library. Patch.so contains the information of func and func_v2. When the hot patch patch.so is loaded into the address space of the target process T by the loader, the address of func is found through the dlsym call, and the entry instruction of func is changed to be writable, and at the same time, it is changed to jump to func_v2; At this point, all calls to func will be redirected to func_v2, and func_v2 will return after execution, and the program will continue to run; (2) Hot Patch Loader The loader finds the entry address of the dlopen function of the target process T; The loader attaches to the target process T through ptrace. The loader puts the name of the hot patch into the stack of the target process T and sets the IP register to the address of the dlopen function. Loader enables the target process T to continue running; because the IP register has been set to the entry point of the dlopen function, the target process T will call dlopen to load the hot patch into the address space of T; If you need to make a hot patch, you only need to write patch.so yourself. Loader is universal, and patch.so only needs a few lines of code to make corresponding replacements. (3) Hot patch implementation When the target process T executes dlopen, the function func_v1 replaces the function func during the loading process through the constructor function pre-written in the hot patch; (4) Hot Patch Loader 1) Loader obtains the dlopen entry address in the target process T address space; The dlopen function is provided by libdl. Not all programs load libdl. Fortunately, libc provides a function with the same function, libc_dlopen_mode, and the parameters accepted are the same as dlopen. Unless there are special circumstances, all programs will load libc. Therefore, it is necessary to find the function entry address of libc_dlopen_mode in the address space of the target process T. In different processes, libc will be loaded to different base addresses, but the offset of the address of the function in libc relative to the base address remains unchanged; Through the / proc / pid / maps of the Loader and the target process T, we can get the base address of libc loaded in the Loader and the target process T; by running dlsym in the Loader, we can get the base address in the Loader; The address of libc_dlopen_mode; this way, the address of libc_dlopen_mode in the target process T can be obtained; 2) Loader uses ptraceattach on the target process T and saves the register information of T at this time; 3) Set the %RIP of the target process T to point to dlopen, put the string of the hot patch name into the stack, write the address of the string into %rdi, and write the value of RTLD_NOW into %rsi as the flag of dlopen; at the same time, set the dlopen return address to the illegal address 0x0, so that the loader captures the SIGSEGV signal generated by the target process T and regains control of T; 4) Loader enables the target process T to continue running; after T completes executing dlopen, the SIGSEGV signal generated by T is captured by Loader, and Loader regains control of the T process; 5) Loader obtains the return value of dlopen by reading the %rax register of the target process T at this time, restores T's initial execution state, and finally releases control over T; 5) Hot patch repair process It is loaded into the target process by Loader, registers its own information to CoreRuntime, and uses the replacement code contained in itself to replace the problematic function after activation; when stopping all threads, it is necessary to first obtain all thread information, interact with libc in the process through the libthread_db library to obtain thread information, and obtain thread information directly from the kernel through the / proc / pid / tasks / directory; after stopping all threads, it is necessary to obtain all thread information again to check whether there are new threads, and if necessary, stop the new threads; repeat the above steps until no new threads appear; (6) Automatically generate hot patches Automatically generating hot patches is a technology that uses hot patch generation tools to process existing source code and patch files and automatically output hot patches. The basic principle of hot patches is to replace old functions with new ones, that is, to replace complete functions. The patch may contain modifications to one or more functions, and all of these modified functions will be replaced. The hot patch first puts the new function into the cache of the target process, and then modifies the entry of the old function to jump to the new function. The most important part of automatically generating hot patches is to automatically generate the binary code of the new function, also known as the replacement code. When generating the replacement code, it consists of automatically generating the replacement code and parsing the symbols used in the replacement code. (7) Compare the previous and next codes to generate replacement code A binary comparison method is used to extract all the information required to generate the replacement code by comparing the binary of the original program with the binary of the repaired program; the before and after comparison is performed at the level of the target file objectfile; First, any source code changes will be reflected in the binary code of the object file; Second, there is no need to deal with language-level features; Finally, we only care about the binary representation of the code; at the target file level, the binary code and code composition information are the most complete, and it is most reasonable to compare the code before and after here; (8) Symbol resolution in replacement code The replacement code only contains the changed function codes, which may reference other unchanged symbols, so it is necessary to follow the symbol reference rules; the offset of the address of the code segment of the dynamic link library in the cache is calculated by the formula Addr = Base + Offset; in other cases, the address of the symbol is an absolute address and does not need to be calculated; (9)POC: Generate replacement code and symbol resolution Extract the .text.func section in T-patched.o; According to the redirection information recorded previously, calculation (V=S+AP) is performed and func is written to the position offset by 0xa. After the redirection, the func function in the replacement code can correctly reference the print function in the original program. Finally, the behavior of the T program after the hot patch is inserted is observed through GDB, and the static and dynamic forms of the replacement code are verified through objdump and gdb.

4. According to claim 1, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: Function file replacement specifically includes: The first step is to load the ELF file header, check the file type and version, etc. It is important to find the address of the programheader and the number of headers. If the connector script is the default, the ELF file header will be loaded at the address 0x804800; The second step is to load the programheader, then scan the programheader and find a programheader of type PT_INTERP. This header contains the address of the interpreter. At this time, load the elf file header of the interpreter program. The third step is to scan the programheader. If the type is PT_LOAD, load the segment in. The fourth step is to determine whether an interpreter program is needed. If so, load the interpreter program and set the program entry to the address of the interpreter program; otherwise, it is the entry of the application program itself; disassemble it to the _start label; Step 5: Set the parameters passed in by the command line and other information required by the application; In the sixth step, the interpreter program starts running, loads the libraries required by the program, and fills in the address information in the redirection symbol table.

5. According to claim 1, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: The design of the hierarchical vulnerability repair VR-VTC model based on vulnerability type clustering includes three steps: Step 1: Vulnerability cluster analysis; PSO-K-means clustering algorithm: Use the PSO algorithm to find the cluster center, and use the K-means algorithm to cluster the vulnerability data after preprocessing; Quantitative analysis of vulnerability type threat: Calculate the threat factor of each vulnerability type using the percentage of each vulnerability type's high, medium, and low risk levels; Step 2: Vulnerability severity assessment; Find the latest relevant security patches based on the host vulnerability reports obtained by the OVAL-based vulnerability scanner; The proposed vulnerability severity assessment method based on rough sets performs quantitative and qualitative assessments on each vulnerability in the host; Step 3: Vulnerability repair strategy selection; Construct a hierarchical target host model for vulnerability types. The target host model is decomposed from top to bottom into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. The vulnerability repair strategy of "bottom-up, first local and then overall" is adopted; A hierarchical vulnerability repair method based on vulnerability type is proposed, and finally a fine-grained vulnerability repair strategy is given; Execute corresponding remediation strategies according to vulnerability priority.

6. According to claim 1, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: A hierarchical target host model construction method for vulnerability types is proposed. The hierarchical relationship of the target host model is decomposed into four levels: host, vulnerability type threat level, vulnerability type, and vulnerability. The strategy of "bottom-up, first local and then overall" is adopted. The specific steps are as follows: (1) Using the OVAL-based vulnerability scanner [12], we obtain a total of N vulnerabilities Vi for the host Host, where the value of i is in the range of 1≤i≤N; (2) Use the vulnerability severity assessment method based on rough sets proposed in the literature [11] to calculate the severity score QS of each vulnerability and obtain the corresponding vulnerability severity level; (3) For M vulnerability types, vulnerabilities Vi of the same type are grouped into a vulnerability type VTk group, where the value range of k is 1≤k≤M; (4) Put all vulnerabilities with a threat level of "weak hazard" into the Ggreen group; similarly, put vulnerabilities with a threat level of "medium hazard" and "strong hazard" into the corresponding Gyellow and Gred groups respectively.

7. According to claim 1, a method for online repairing cache patches of unknown vulnerabilities of power terminals is characterized in that: A hierarchical vulnerability repair method based on vulnerability type, the steps are: (1) In the Ggreen group, for each vulnerability, the corresponding repair strategy is implemented according to the Ggreen threat level rules; if the QS is high risk, the priority level is P1, and the patch installation time is no more than 1 week; if it is medium risk, the priority level is P2, and the patch installation time is no more than 5 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 9 weeks; (2) In the Gyellow group, the corresponding repair strategy is implemented for each vulnerability according to the Gyellow threat level rules; if the QS is high risk, the priority level is P1, and the patch installation time is no more than 2 weeks; if it is medium risk, the priority level is P2, and the patch installation time is no more than 6 weeks; if it is low risk, the priority level is P3, and the patch installation time is no more than 10 weeks; (3) In the Gred group, the corresponding repair strategy is executed for each vulnerability Gred threat level rule; if the QS is high risk, the priority level is P1, and the patch installation time is up to 3 weeks; if it is medium risk, the priority level is P2, and the patch installation time is up to 7 weeks; if it is low risk, the priority level is P3, and the patch installation time is up to 11 weeks; CNNVD manually marks the vulnerability types of all vulnerabilities, and the result is 26 vulnerability types. The vulnerability type corresponding to each vulnerability is obtained through the crawler program, and its performance is compared with the clustering result obtained by the PSO-K-means algorithm; the various parameter values ​​of the PSO-K-means algorithm are: the population size of the particle swarm m = 65295, the number of clusters k = 26, the maximum number of iterations maxTime = 200, and the fitness variance threshold threδ of the particle swarm = 0.1; therefore, the size of KSset is a two-dimensional vector of 50×65295; the horizontal axis represents the vulnerability type.

Images