Vulnerability mining method and device, equipment and storage medium

Abstract

The application discloses a vulnerability mining method and device, equipment and a storage medium, and relates to the technical field of computers. The vulnerability mining method comprises the following steps: using the context of a target language to execute a pre-set fuzzing process on a GPU driver to obtain a fuzzing result; wherein the target language is a programming language supported by a manufacturer corresponding to the GPU driver; and determining a vulnerability mining result corresponding to the GPU driver based on the fuzzing result, which is used to represent whether the GPU driver contains a vulnerability. The application uses the context of the programming language supported by the manufacturer corresponding to the GPU driver to assist in mining the vulnerability of the GPU driver in the case that the GPU instruction code is unknown, thereby effectively improving the vulnerability mining efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and particularly relates to a vulnerability mining method and device, equipment and a storage medium. BACKGROUND

[0002] In a related operating system, a GPU (Graphics Processing Unit) driver can be accessed by a common application, and its logic is very complex and prone to problems, so the GPU driver is a relatively ideal attack surface. In addition, a mobile GPU does not have independent memory, and it shares memory with a CPU (Central Processing Unit). An important function of the GPU driver is to manage the physical memory used by the CPU and the GPU, and the GPU driver abstracts it as a memory object. In order to avoid data copying and improve data processing efficiency, the physical memory can be simultaneously mapped into the virtual address space of the CPU and the GPU, or even mapped onto different virtual addresses in the same address space, and the mapped memory attributes can be different. The GPU driver provides a plurality of APIs (Application Programming Interface) for maintaining memory objects for this purpose, and there can be mutual influences between these APIs, leading to vulnerabilities.

[0003] At present, it is necessary to execute code in the GPU to detect whether a vulnerability exists, but GPU instruction encoding generally belongs to a business secret, and relevant personnel are difficult to directly write a GPU instruction sequence, leading to difficulty in determining whether a vulnerability exists in the GPU driver, and making it impossible to effectively mine vulnerabilities.

[0004] The above content is only used to assist in understanding the technical solutions of the present application and does not represent an admission that the above content is prior art. SUMMARY

[0005] The main purpose of the present application is to provide a vulnerability mining method, device, equipment and storage medium, aiming to solve the technical problems of difficulty in effectively mining GPU driver vulnerabilities and low vulnerability mining efficiency in related technologies.

[0006] To achieve the above purpose, the present application provides a vulnerability mining method, which comprises the following steps:

[0007] Performing a pre-set fuzzing process on the GPU driver by using the context of a target language to obtain a fuzzing result, wherein the target language is a programming language supported by a manufacturer corresponding to the GPU driver;

[0008] Based on the fuzzing result, determining a vulnerability mining result corresponding to the GPU driver, which is used to represent whether the GPU driver contains a vulnerability.

[0009] In an embodiment, before the step of performing the pre-set fuzzing process on the GPU driver using the context of the target language, the method further comprises:

[0010] loading a dynamic library corresponding to the target language;

[0011] initializing the context corresponding to the target language using symbols in the dynamic library.

[0012] In an embodiment, after the step of initializing the context corresponding to the target language, the method further comprises:

[0013] finding a target handle, wherein the target handle corresponds to the context corresponding to the target language;

[0014] The step of performing the pre-set fuzzing process on the GPU driver using the context of the target language comprises:

[0015] performing the pre-set fuzzing process on the GPU driver using the context corresponding to the target handle.

[0016] In an embodiment, the step of performing the pre-set fuzzing process on the GPU driver to obtain a fuzzing result comprises:

[0017] creating target memory objects with different access attributes for the GPU driver;

[0018] performing a corresponding pre-processing process on the target memory objects based on the access attributes of the target memory objects;

[0019] performing a target operation related to the target memory objects on the target memory objects after the pre-processing process;

[0020] determining a test result of the target memory objects as the fuzzing result after performing the target operation.

[0021] In an embodiment, the step of performing a corresponding pre-processing process on the target memory objects based on the access attributes of the target memory objects comprises:

[0022] when the access attribute of the target memory object is read-only, keeping and recording original memory data of the target memory object;

[0023] when the access attribute of the target memory object is writable, initializing the memory data of the target memory object as a target magic number.

[0024] In an embodiment, the target operation comprises at least one of:

[0025] mapping the target memory object to at least one of a CPU address space and a GPU address space with the same or different access attributes;

[0026] mapping the target memory object to different addresses of a CPU address space with the same or different access attributes;

[0027] mapping the target memory object to different addresses of a GPU address space with the same or different access attributes;

[0028] releasing the target memory object;

[0029] driving to reduce the memory of the target memory object.

[0030] In an embodiment, after performing the target operation, the step of determining the test result of the target memory object comprises:

[0031] after performing the target operation, the test result of the target memory object is determined as any one of:

[0032] a first result, representing that the read-only memory of the target memory object is writable, or the original memory data is changed;

[0033] a second result, representing that the memory of the released target memory object is supported to be accessed;

[0034] a third result, representing that the target magic number is changed, or the memory of the reduced target memory object is supported to be accessed.

[0035] In an embodiment, based on the fuzz test result, the step of determining the corresponding vulnerability mining result of the GPU driver comprises:

[0036] in the case that the fuzz test result is the first result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of unreasonable memory attribute setting;

[0037] in the case that the fuzz test result is the second result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of residual page table entry of CPU or GPU;

[0038] in the case that the fuzz test result is the third result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

[0039] In addition, in order to achieve the above-mentioned purpose, the present application further provides a vulnerability mining device, which comprises:

[0040] a testing module, configured to execute a preset fuzzing test procedure on the GPU driver by using a context of the target language, to obtain a fuzzing test result, wherein the target language is a programming language supported by a vendor corresponding to the GPU driver;

[0041] a determining module, configured to determine a vulnerability mining result corresponding to the GPU driver based on the fuzzing test result, to represent whether the GPU driver contains a vulnerability.

[0042] In an embodiment, the apparatus further includes:

[0043] a loading module, configured to load a dynamic library corresponding to the target language;

[0044] an initializing module, configured to initialize a context corresponding to the target language by using a symbol in the dynamic library.

[0045] In an embodiment, the apparatus further includes:

[0046] a searching module, configured to search for a target handle, wherein the target handle corresponds to the context corresponding to the target language;

[0047] The testing module is specifically configured to execute the preset fuzzing test procedure on the GPU driver by using the context corresponding to the target handle.

[0048] In an embodiment, the testing module is further specifically configured to:

[0049] create a target memory object with different access attributes for the GPU driver;

[0050] execute a corresponding preprocessing procedure on the target memory object based on an access attribute of the target memory object;

[0051] execute a target operation related to the target memory object on the target memory object after the preprocessing procedure is executed;

[0052] determine a test result of the target memory object as the fuzzing test result after the target operation is executed.

[0053] In an embodiment, the testing module is further specifically configured to:

[0054] when the access attribute of the target memory object is read-only, maintain and record original memory data of the target memory object;

[0055] when the access attribute of the target memory object is writable, initialize memory data of the target memory object as a target magic number.

[0056] In an embodiment, the target operation includes at least one of the following:

[0057] mapping the target memory object to at least one of a CPU address space and a GPU address space with the same or different access attributes;

[0058] mapping the target memory object to different addresses of the CPU address space with the same or different access attributes;

[0059] mapping the target memory object to different addresses of the GPU address space with the same or different access attributes;

[0060] releasing the target memory object;

[0061] driving to reduce the memory of the target memory object.

[0062] In an embodiment, the test module is further configured to:

[0063] after performing the target operation, determine a test result of the target memory object as any one of:

[0064] a first result, representing that read-only memory of the target memory object is writable, or that the original memory data has changed;

[0065] a second result, representing that memory of the target memory object that has been released is supported to be accessed;

[0066] a third result, representing that the target magic number has changed, or that memory of the target memory object that has been reduced is supported to be accessed.

[0067] In an embodiment, the determining module is configured to:

[0068] in a case where the fuzz test result is the first result, determine that the vulnerability mining result represents that the GPU driver has a vulnerability of unreasonable memory attribute setting;

[0069] in a case where the fuzz test result is the second result, determine that the vulnerability mining result represents that the GPU driver has a vulnerability of residual page table entry of CPU or GPU;

[0070] in a case where the fuzz test result is the third result, determine that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

[0071] In addition, to achieve the above object, the present application further provides a vulnerability mining device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the vulnerability mining method as described above.

[0072] In addition, to achieve the above object, the present application also provides a storage medium, which is a computer readable storage medium, and a computer program is stored on the storage medium, and the computer program is executed by a processor to implement the steps of the vulnerability mining method.

[0073] In addition, to achieve the above object, the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the vulnerability mining method.

[0074] The one or more technical solutions provided by the present application have at least the following technical effects:

[0075] The present application utilizes the context of the programming language supported by the manufacturer of the GPU driver to assist in mining vulnerabilities, specifically utilizes the context of the target language in combination with the fuzzing process to implement fuzz testing on the GPU driver, obtains the corresponding fuzz testing result, and then determines the vulnerability mining result of the GPU driver based on the fuzz testing result, which can assist in mining vulnerabilities of the GPU driver in the case of unknown GPU instruction encoding, thereby effectively improving the vulnerability mining efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0076] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0077] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, those skilled in the art can obtain other drawings from these drawings without creative labor.

[0078] Figure 1 is one of the flowcharts of the vulnerability mining method provided by the present application;

[0079] Figure 2 is the second flowchart of the vulnerability mining method provided by the present application;

[0080] Figure 3 is the third flowchart of the vulnerability mining method provided by the present application;

[0081] Figure 4 is a schematic diagram of unreasonable memory attribute setting in the vulnerability mining method provided by the present application;

[0082] Figure 5 is a schematic diagram of CPU / GPU page table entry residual in the vulnerability mining method provided by the present application;

[0083] Figure 6 Figure 4 is a flowchart illustrating a fourth example of a vulnerability mining method according to the present application;

[0084] Figure 7 Figure 5 is a flowchart illustrating a process of a fuzzing test in a vulnerability mining method according to the present application;

[0085] Figure 8 Figure 6 is a structural diagram of a vulnerability mining device according to the present application;

[0086] Figure 9 Figure 7 is a structural diagram of a vulnerability mining device according to the present application.

[0087] The objectives, features, and advantages of the present application will be further illustrated in conjunction with the embodiments, with reference to the accompanying drawings. DETAILED DESCRIPTION

[0088] It should be understood that the specific embodiments described herein merely exemplify the technical solutions of the present application, and are not intended to limit the present application.

[0089] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the specification herein is for describing particular embodiments only and is not intended to be limiting of the application; the use herein of terms such as "comprise" and "have" and any variations thereof are intended to cover the inclusion but not the exclusion of any feature, step, or element of any described embodiment or aspect of the present application; the use of "including" and "comprising" and variations thereof herein is meant to be equivalent to the term "consisting of" to mean the inclusion, as the term is used in patent law, of any stated feature, step, or element but not to the exclusion of any other feature, step, or element.

[0090] In the description of the embodiments of the present application, the technical terms "first", "second", and the like are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order, or primary and secondary relationship of the technical features indicated. In the description of the embodiments of the present application, the meaning of "a plurality of" is two and more than two, unless otherwise explicitly and specifically limited.

[0091] In the present application, the term "embodiment" means that the specific features, structures, or properties described in conjunction with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily mean the same embodiment, nor is it an independent or alternative embodiment to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in the present application can be combined with other embodiments.

[0092] In the description of the embodiments of the present application, the term "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in this paper generally represents a "or" relationship between the front and rear associated objects.

[0093] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0094] In the related art, the GPU driver provides a variety of APIs for maintaining memory objects, and there may be mutual influences between these APIs, leading to vulnerabilities. Some vulnerabilities are very hidden, and the kernel has no exception information, so the conventional vulnerability mining method is invalid, for example: the GPU driver allows read-only memory to be mapped to the GPU address space with writable attributes, in this case, only by making the GPU modify the read-only memory can it be determined whether the vulnerability exists. At present, it is usually difficult to directly know the GPU instruction code, so it cannot be directly written into a GPU instruction sequence to verify the vulnerability.

[0095] To solve the above problems, the present application provides a vulnerability mining method, device, equipment and storage medium. At present, the mainstream mobile GPU supports Open Computing Language (OpenCL), so the present application can assist in mining vulnerabilities through OpenCL, and this is a general GPU driver vulnerability mining method, which can affect billions of mobile devices by mining a plurality of high-value vulnerabilities using this method.

[0096] It should be noted that the execution subject of the embodiments of the present application can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device, a vulnerability mining device, etc. capable of realizing the above functions. The following takes the vulnerability mining device as an example to describe the embodiments of the present application and the following embodiments.

[0097] The embodiments of the present application and the following embodiments will be described in detail below.

[0098] The embodiments of the present application provide a vulnerability mining method, which refers to Figure 1 , Figure 1 is one of the flowcharts of the vulnerability mining method provided by the present application, which comprises steps S101-S102:

[0099] Step S101, using the context of the target language, executing a pre-set fuzzing process on the GPU driver to obtain a fuzzing result;

[0100] Among them, the target language is a programming language supported by the manufacturer corresponding to the GPU driver.

[0101] In some embodiments, the target language is, for example, OpenCL, and can also be other programming languages supported by the GPU driver, which is not limited by the present application.

[0102] It should be noted that after creating and initializing the context corresponding to the target language, the pre-set fuzzing process can be combined with the context corresponding to the target language to perform the fuzzing process on the GPU driver and obtain the fuzzing results.

[0103] It should also be noted that the context corresponding to the target language can be understood as having a conversion function, which can convert the fuzzing process into content that the GPU driver can recognize, and then perform fuzzing based on this process to obtain the fuzzing results.

[0104] Step S102: Based on the fuzz test results, determine the vulnerability discovery results corresponding to the GPU driver, which are used to characterize whether the GPU driver contains vulnerabilities.

[0105] In some embodiments, vulnerability discovery results can be used to characterize whether a GPU driver contains vulnerabilities, and can also characterize the vulnerability scenarios corresponding to vulnerabilities.

[0106] In some embodiments, the vulnerability scenarios corresponding to the above-mentioned situations containing vulnerabilities may include: unreasonable memory attribute settings, residual CPU or GPU page table entries, and improper handling of physical memory reduction, etc.

[0107] This application provides a vulnerability discovery method that utilizes the context of the programming language supported by the GPU driver manufacturer to assist in vulnerability discovery. Specifically, it combines the context of the target language with a fuzzing process to perform fuzzing on the GPU driver, obtains the corresponding fuzzing results, and then determines the vulnerability discovery results corresponding to the GPU driver based on the fuzzing results. This method can assist in vulnerability discovery of GPU drivers even when the GPU instruction encoding is unknown, thereby effectively improving vulnerability discovery efficiency.

[0108] In some embodiments, a specific implementation is provided for creating and initializing a context for the target language. Figure 2 This is the second flowchart illustrating the vulnerability discovery method provided in this application, such as... Figure 2 As shown, in Figure 1 Based on the above step S101, steps S103 to S104 may also be included:

[0109] Step S103: Load the dynamic library corresponding to the target language.

[0110] In some embodiments, the OpenCL dynamic library can be loaded using the dlopen() function.

[0111] Step S104: Initialize the context corresponding to the target language using the symbols in the dynamic library.

[0112] For example, after loading the OpenCL dynamic library through the dlopen() function, the addresses of the following symbols can be obtained as shown in Table 1:

[0113] Table 1: List of imported OpenCL symbols

[0114] Number Symbol 1 clGetPlatformIDs 2 clGetPlatformInfo 3 clGetDeviceIDs 4 clGetDeviceInfo 5 clCreateContext 6 clCreateCommandQueue 7 clCreateProgramWithSource 8 clBuildProgram 9 clCreateKernel 10 clCreateBuffer 11 clEnqueueWriteBuffer 12 clSetKernelArg 13 clEnqueueNDRangeKernel 14 clFinish 15 clEnqueueReadBuffer 16 clReleaseMemObject 17 clReleaseCommandQueue 18 clReleaseContext

[0115] The OpenCL context is initialized in the following manner using the symbols in the dynamic library:

[0116]

[0117]

[0118] In some embodiments, a specific implementation of finding the target language corresponding context is provided. As shown in Figure 2 the above step S104, step S105 can be further included:

[0119] Step S105: finding the target handle;

[0120] wherein the target handle corresponds to the context corresponding to the target language.

[0121] Correspondingly, the above step S101 is replaced by step S101-1:

[0122] Step S101-1: using the context corresponding to the target handle to execute the pre-set fuzzing process on the GPU driver.

[0123] Specifically, after creating and initializing the context corresponding to the target language, the context needs to be found before it can be combined with the fuzzing process. The present application can find the corresponding context by finding the target handle, for example, by searching for the target handle in the file list.

[0124] In some embodiments, a specific implementation of finding the target handle is provided. The above target language can be OpenCL; and a specific implementation of the above step S105 can include:

[0125] In the case where the GPU driver is a Mali GPU driver, the pre-set file list is traversed to match the handle corresponding to the driver device file name mali as the target handle.

[0126] Specifically, the OpenCL initialization opens the device file of the GPU driver. For example, the device file of the Mali GPU driver is / dev / mali0. The application needs to find the handle of the file so as to combine the OpenCL context with the fuzzing process. The target handle can be found by reading the content of the / proc / self / fd directory, which records the file handle associated with the file:

[0127] RE87BAL1: $ ls -l / proc / 1224 / fd;

[0128] total 0;

[0129] lrwx------ 1 shell shell 64 2025-01-03 11:24 0 -> / dev / pts / 0;

[0130] lrwx------ 1 shell shell 64 2025-01-03 11:24 1 -> / dev / pts / 0;

[0131] lrwx------ 1 shell shell 64 2025-01-03 11:24 2 -> / dev / pts / 0;

[0132] lrwx------ 1 shell shell 64 2025-01-03 11:24 3 -> / dev / mali0.

[0133] The application traverses the directory and matches the device file name (mali) of the driver to find the corresponding handle.

[0134] It should be noted that the device file name of the target handle corresponding to different GPU drivers is usually different, and can be matched according to the actual situation. The application is only used for illustration.

[0135] In some embodiments, a specific implementation of finding the context corresponding to the target language is provided. Figure 3 is a third flowchart of the vulnerability mining method provided by the application, as shown in Figure 3 , on the basis of Figure 1 , the above step S101 includes steps S101-21 to S101-24:

[0136] Step S101-21, creating a target memory object with different access attributes for the GPU driver;

[0137] In step S101-22, a corresponding preprocessing procedure is performed on the target memory object based on the access attribute of the target memory object by using the context corresponding to the target language.

[0138] In some embodiments, a specific implementation of step S101-22 is provided. Step S101-22 can specifically include:

[0139] <1> When the access attribute of the target memory object is read-only, the original memory data of the target memory object is maintained and recorded;

[0140] It should be noted that when the access attribute is read-only, the original memory data of the target memory object needs to be recorded, so that whether the target memory object has a vulnerability can be determined by comparing whether the original memory data has changed subsequently.

[0141] <2> When the access attribute of the target memory object is writable, the memory data of the target memory object is initialized as a target magic number.

[0142] It should be noted that the target magic number can be specially set according to actual conditions. Subsequently, whether there is a vulnerability can be determined according to whether the target magic number in the writable memory changes. It should be noted that the target magic number needs to be avoided from the common memory data of the target memory object to avoid difficulty in distinguishing the target magic number from the memory data of the target memory object.

[0143] In other embodiments, step S101-22 can specifically include any of the following:

[0144] 1) When the target memory object is a CPU and the access attribute is read-only, the original memory data of the target memory object is maintained and recorded;

[0145] 2) When the target memory object is a CPU and the access attribute is writable, the memory data of the target memory object is initialized as a first magic number;

[0146] It should be noted that the first magic number is set to 0xAB, for example, and can be set according to actual conditions. It should be noted that the first magic number needs to be avoided from the common memory data of the target memory object to avoid difficulty in distinguishing the first magic number from the memory data of the target memory object.

[0147] 3) When the target memory object is a GPU and the access attribute is read-only, the original memory data of the target memory object is maintained and recorded;

[0148] 4) When the target memory object is a GPU and the access attribute is writable, the memory data of the target memory object is initialized as a second magic number.

[0149] It should be noted that the second magic number is set to 0xCD for example, and can be set according to actual conditions. Note that the common memory data of the target memory object needs to be avoided to avoid difficulty in distinguishing the second magic number from the memory data of the target memory object.

[0150] In step S101-23, the target operation related to the target memory object after the pre-processing procedure is executed is executed on the target memory object.

[0151] In some embodiments, a specific implementation of the target operation is provided. The target operation includes at least one of the following:

[0152] mapping the target memory object to at least one of a CPU address space and a GPU address space with the same or different access attributes;

[0153] mapping the target memory object to different addresses of the CPU address space with the same or different access attributes;

[0154] <c>mapping the target memory object to different addresses of the GPU address space with the same or different access attributes;

[0155] <d>releasing the target memory object;

[0156] <e>The driver reduces the memory of the target memory object.

[0157] In some embodiments, the driver reduces the memory of the target memory object can be achieved by modifying the properties of the target memory object, so that the driver reduces the physical memory of the target memory object, that is, the test program requests the GPU driver to reduce the memory of a certain memory object; in addition, the physical memory of the target memory object can also be reduced by increasing the system physical memory pressure, that is, the kernel will try to clean up the infrequently used memory when the system memory pressure reaches a threshold, at this time the GPU driver will reduce the memory of the memory object. It should be noted that the present application does not limit the way the driver reduces the memory of the target memory object.

[0158] It should be noted that at least one of the above target operations can be set according to actual conditions, and the order of execution when multiple target operations are executed can also be set according to actual conditions. Other target operations can also be executed to test the target memory object according to actual conditions, and the present application does not limit this.

[0159] Step S101-24, after executing the target operation, determining the test result of the target memory object as the fuzz test result.

[0160] In some embodiments, a specific implementation of the above step S101-24 is provided. The above step S101-24 can specifically include:

[0161] After executing the target operation, the test result of the target memory object is determined as any of the following:

[0162] 1) The first result represents that the read-only memory of the target memory object is writable, or the original memory data changes;

[0163] 2) The second result represents that the memory of the target memory object that has been released is supported to be accessed;

[0164] 3) The third result represents that the target magic number changes, or the memory of the target memory object that has been reduced is supported to be accessed.

[0165] In some embodiments, a specific implementation of the above step S102 is provided. The above step S102 can specifically include:

[0166] <1> In the case where the fuzz test result is the first result, it is determined that the vulnerability mining result represents that the GPU driver has an unreasonable memory property setting vulnerability;

[0167] Need to explain, GPU drive exists memory attribute setting unreasonable problem, can cause GPU can modify read-only memory.< / e> < / d> < / c> Figure 4 is a diagram of unreasonable memory attribute setting in the vulnerability mining method provided in the present application, as shown in Figure 4 for example, all processes of the system share the libc dynamic library code segment, the memory attribute of this read-only code segment in all processes is read-only executable (CPU address space), the process cannot modify its logic, otherwise the control flow of other privileged processes can be hijacked. If the GPU driver maps this memory with writable attribute, a malicious process can tamper with the libc code segment, that is, the GPU driver has a vulnerability.

[0168] <2>in the case where the fuzz test result is the second result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of residual CPU or GPU page table entry;

[0169] It should be noted that, under normal circumstances, when the memory of a memory object is released, the GPU driver will synchronously delete the corresponding CPU or GPU page table entry; and under abnormal circumstances, the memory of the memory object has been released, but the CPU or GPU page table entry has not been deleted, and the test program can still access the released memory. Figure 5 is a diagram of residual CPU / GPU page table entry in the vulnerability mining method provided in the present application, as shown in Figure 5 When the GPU driver maintains the CPU and GPU page tables, the page table entry corresponding to the released physical memory can not be deleted, which can cause the process to still be able to access the released memory, and the memory can be used by the kernel or the application. In this case, a malicious process can tamper with the memory data, resulting in a vulnerability.

[0170] <3>in the case where the fuzz test result is the third result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

[0171] It should be noted that when the available physical memory of the system is tight, the driver will reduce the memory occupied by the memory object, and if the released memory can still be accessed, a malicious process can tamper with the memory data, resulting in a vulnerability.

[0172] The following illustrates the vulnerability mining method provided in the embodiments of the present application.

[0173] The current mainstream mobile GPU supports OpenCL, and the present application can assist in mining vulnerabilities through OpenCL, Figure 6 is the fourth flowchart of the vulnerability mining method provided in the present application, as shown in Figure 6 , mainly comprising the following steps:

[0174] Step S601, start;

[0175] Step S602, load OpenCL dynamic library and initialize OpenCL context;

[0176] Step S603, combine OpenCL context;

[0177] Step S604, execute the fuzzing test process by means of OpenCL to perform state detection;

[0178] Step S605, end.

[0179] First, load OpenCL dynamic library, initialize OpenCL context, then find and reuse the dynamic library to open the GPU driver device file handle (fd, file descriptor) to combine the fuzzing test process with the OpenCL context, then execute the fuzzing test process, finally run the OpenCL program to detect the state of the GPU driver and confirm whether a vulnerability exists. Specifically:

[0180] (1) Load OpenCL dynamic library;

[0181] Load OpenCL dynamic library through dlopen(), get the symbols shown in Table 1 above, and then initialize the OpenCL context.

[0182] (2) Combine OpenCL context;

[0183] When OpenCL is initialized, the GPU driver device file is opened. Taking the Mali GPU driver as an example, the device file is / dev / mali0. The handle of this file needs to be found in order to combine the OpenCL context with the fuzzing test process. The target handle can be found by reading the contents of the / proc / self / fd directory, for example, the directory can be traversed and the drive device file name (mali) can be matched to find the corresponding handle.

[0184] (3) Execute fuzzing test;

[0185] First, introduce GPU driver API. The GPU driver provides a variety of APIs for maintaining memory objects. Table 2 below lists the related APIs provided by KGSL driver and Mali driver:

[0186] Table 2 Partial API description of GPU driver

[0187]

[0188]

[0189] The above APIs can manage the entire life cycle of the memory object:

[0190] a) allocating a memory object, allocating physical memory for it;

[0191] b) releasing a memory object, canceling address mapping, releasing physical memory;

[0192] c) mapping the physical memory of a memory object to the CPU and GPU address space according to a certain memory access attribute;

[0193] d) The physical memory of the same memory object can be mapped to different virtual addresses in the address space;

[0194] e) The physical memory of a memory object can be reduced and increased on demand;

[0195] f) updating the attributes of a memory object as needed.

[0196] The above API may have the following three vulnerability scenarios in maintaining the life cycle of a memory object. For specific vulnerability scenario descriptions, refer to the above embodiments, which will not be repeated here:

[0197] 1) Unreasonable memory attribute setting;

[0198] 2) CPU / GPU page table entry residual;

[0199] 3) improper physical memory reduction processing.

[0200] Regarding the fuzzing process, Figure 7 is a schematic diagram of the fuzzing process in the vulnerability mining method provided by the present application, as shown in Figure 7 , mainly includes the following steps:

[0201] Step S701, start;

[0202] Step S702, initialize the memory object with a specific magic number;

[0203] Step S703, perform a target operation on the memory object to change its state;

[0204] Step S704, detect the memory object on the CPU and GPU side;

[0205] Step S705, end.

[0206] First, allocate and initialize a memory object. The memory type of the memory object includes GPU driver allocation, process memory import, and DMA (Direct Memory Access) memory import. The fuzzing process writes a specific magic number in the memory according to the access attribute of the memory object, and then detects whether these magic numbers change in the subsequent detection, so as to judge whether a vulnerability occurs:

[0207] a) When the CPU space mapping attribute is read-only, keep and record the original memory data;

[0208] b) When the CPU space mapping attribute is writable, initialize the memory data as 0xAB;

[0209] c) When the GPU space mapping attribute is read-only, keep and record the original memory data;

[0210] d) When the GPU space mapping attribute is writable, initialize the memory data as 0xCD.

[0211] For the above three vulnerability scenarios, the memory object is subjected to the target operation in Table 3 as follows:

[0212] Table 3 Target operations supported by the fuzzing process

[0213]

[0214] The fuzzing process modifies the memory object attributes, releases the memory object, and increases the system physical memory pressure, etc. These operations will change the state of the memory object, and the program will record the state of the memory object in synchronization, including the following contents: identification (ID), CPU mapping address and attribute, GPU mapping address and attribute, physical memory reduction, and memory data.

[0215] After the fuzzing process performs the target operation, the state of the memory object is detected. For the memory object mapped to the CPU address space, memory access can be directly performed to determine whether the memory access mode meets the expectations and to check whether the magic number has changed, thereby determining whether there is a vulnerability.

[0216] For the memory object mapped to the GPU address space, the program detects it by running OpenCL code, the core of which is how to access the memory through the GPU. The relevant OpenCL code is as follows:

[0217]

[0218]

[0219] With the help of OpenCL, the memory in the CPU and GPU address spaces can be detected simultaneously.

[0220] When the following conditions occur, the fuzzing program considers that the GPU driver has a vulnerability. Table 4 represents the correspondence between the situation description and the vulnerability scenario:

[0221] Table 4 Correspondence between situation description and vulnerability scenario

[0222]

[0223] It should be noted that the above examples are only used for understanding the present application and do not constitute a limitation on the vulnerability mining method of the present application, and more forms of simple changes based on this technical concept are within the protection scope of the present application.

[0224] The present application also provides a vulnerability mining device, Figure 8 is a structural schematic diagram of the vulnerability mining device provided by the present application, as Figure 8 shown, the vulnerability mining device comprises:

[0225] The test module 801 is configured to execute a pre-set fuzzing test process on the GPU driver by using the context of the target language, to obtain a fuzzing test result; wherein the target language is a programming language supported by a manufacturer corresponding to the GPU driver.

[0226] The determination module 802 is configured to determine a vulnerability mining result corresponding to the GPU driver based on the fuzzing test result, to represent whether the GPU driver contains a vulnerability.

[0227] In some embodiments, the device further comprises:

[0228] The loading module is configured to load a dynamic library corresponding to the target language.

[0229] The initialization module is configured to initialize the context corresponding to the target language by using a symbol in the dynamic library.

[0230] In some embodiments, the device further comprises:

[0231] The searching module is configured to search for a target handle; wherein the target handle corresponds to the context corresponding to the target language.

[0232] The test module 801 is specifically configured to execute a pre-set fuzzing test process on the GPU driver by using the context corresponding to the target handle.

[0233] In some embodiments, the test module 801 is specifically configured to:

[0234] Create a target memory object with different access attributes for the GPU driver;

[0235] Execute a corresponding pre-processing process on the target memory object based on the access attribute of the target memory object;

[0236] Execute a target operation related to the target memory object on the target memory object after executing the pre-processing process;

[0237] After executing the target operation, determine a test result of the target memory object as the fuzzing test result.

[0238] In some embodiments, the test module 801 is further specifically configured to:

[0239] when the access attribute of the target memory object is read-only, keeping and recording the original memory data of the target memory object;

[0240] when the access attribute of the target memory object is writable, initializing the memory data of the target memory object as a target magic number.

[0241] In some embodiments, the target operation includes at least one of:

[0242] mapping the target memory object to at least one of a CPU address space and a GPU address space with the same or different access attribute;

[0243] mapping the target memory object to different addresses of a CPU address space with the same or different access attribute;

[0244] mapping the target memory object to different addresses of a GPU address space with the same or different access attribute;

[0245] releasing the target memory object;

[0246] driving to reduce the memory of the target memory object.

[0247] In some embodiments, the test module 801 is further specifically configured to:

[0248] after performing the target operation, determining the test result of the target memory object as any one of:

[0249] a first result, representing that the read-only memory of the target memory object is writable, or the original memory data has changed;

[0250] a second result, representing that the memory of the released target memory object is supported to be accessed;

[0251] a third result, representing that the target magic number has changed, or the memory of the reduced target memory object is supported to be accessed.

[0252] In some embodiments, the determination module 802 is specifically configured to:

[0253] when the fuzz test result is the first result, determining that the vulnerability mining result represents that the GPU driver has a vulnerability of unreasonable memory attribute setting;

[0254] when the fuzz test result is the second result, determining that the vulnerability mining result represents that the GPU driver has a vulnerability of residual page table entry of CPU or GPU.

[0255] In a case where the fuzzing result is the third result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

[0256] The vulnerability mining device provided in the present application adopts the vulnerability mining method in the above embodiments, and can solve the technical problems in the related art that it is difficult to determine whether the GPU driver has a vulnerability, and the vulnerability mining efficiency is low. Compared with the prior art, the vulnerability mining device provided in the present application has the same beneficial effects as the vulnerability mining method provided in the above embodiments, and other technical features in the vulnerability mining device are the same as the features disclosed in the above embodiments, which will not be repeated here.

[0257] The present application provides a vulnerability mining device, which comprises at least one processor and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the vulnerability mining method in the above embodiments.

[0258] Reference will be made to the following Figure 9 , Figure 9 is a structural schematic diagram of the vulnerability mining device provided in the present application, which shows a structural schematic diagram of the vulnerability mining device suitable for implementing the embodiments of the present application. The vulnerability mining device in the embodiments of the present application can include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 9 The vulnerability mining device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0259] As Figure 9 As shown, the vulnerability mining device can include a processing device 901 (e.g., a central processor, a graphics processor, etc.) that can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 902 or loaded from a storage device 903 into a random access memory (RAM) 904. In the RAM 904, various programs and data required for the operation of the vulnerability mining device are also stored. The processing device 901, the ROM 902, and the RAM 904 are connected to each other through a bus 905. An input / output (I / O) interface 906 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 906: an input device 907 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 908 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage device 903 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 909. The communication device 909 can allow the vulnerability mining device to communicate with other devices wirelessly or by wire to exchange data. Although the vulnerability mining device with various systems is shown in the figure, it should be understood that all the systems shown are not required to be implemented or possessed. More or fewer systems can be alternatively implemented or possessed.

[0260] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network through the communication device, or installed from the storage device 903, or installed from the ROM 902. When the computer program is executed by the processing device 901, the above-mentioned functions defined in the methods of the embodiments of the present disclosure are performed.

[0261] The vulnerability mining device provided by the present disclosure adopts the vulnerability mining method in the above embodiments, and can solve the technical problems in the related art that it is difficult to determine whether the GPU driver has a vulnerability, and the vulnerability mining efficiency is low. Compared with the prior art, the beneficial effects of the vulnerability mining device provided by the present disclosure are the same as those of the vulnerability mining method provided by the above embodiments, and other technical features in the vulnerability mining device are the same as those disclosed in the previous embodiment method, which will not be repeated here.

[0262] It should be understood that various aspects of the disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0263] The above description is merely illustrative of the application and not restrictive.

[0264] The application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., a computer program) for performing the vulnerability mining method in the above-described embodiments.

[0265] The computer readable storage medium provided by the application may, for example, be a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), etc., or any suitable combination of the above.

[0266] The above computer readable storage medium can be included in a vulnerability mining device; or can exist separately and not be assembled into a vulnerability mining device.

[0267] The above computer readable storage medium carries one or more programs, which, when executed by the vulnerability mining device, cause the vulnerability mining device to perform the following steps:

[0268] The GPU driver is executed by using the context of the target language to perform a preset fuzz test process, to obtain a fuzz test result; wherein the target language is a programming language supported by a manufacturer corresponding to the GPU driver;

[0269] Based on the fuzz test result, a vulnerability mining result corresponding to the GPU driver is determined, to represent whether the GPU driver contains a vulnerability.

[0270] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0271] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architectures, functions, and operations of the systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a program segment, or a portion of code that contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in a different order than that noted in the accompanying drawings. For example, two blocks that are shown in succession can actually be executed substantially concurrently, or they can be executed in reverse order, depending on the involved functions. It should also be noted that each block in the block diagrams and / or flowcharts, and the combination of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0272] The modules involved in the embodiments of the present application can be implemented in a software manner or in a hardware manner. In some cases, the name of the module does not constitute a limitation on the module itself.

[0273] The readable storage medium provided in the application is a computer readable storage medium, and the computer readable storage medium stores computer readable program instructions (i.e., a computer program) for executing the vulnerability mining method described above, and can solve the technical problems of difficulty in determining whether a GPU driver has a vulnerability and low vulnerability mining efficiency in the related art. Compared with the prior art, the computer readable storage medium provided in the application has the same beneficial effects as the vulnerability mining method provided in the above embodiments, and will not be described here.

[0274] The application further provides a computer program product comprising a computer program, which, when executed by a processor, implements the steps of the vulnerability mining method as described above.

[0275] The computer program product provided in the application can solve the technical problems of difficulty in determining whether a GPU driver has a vulnerability and low vulnerability mining efficiency in the related art. Compared with the prior art, the computer program product provided in the application has the same beneficial effects as the vulnerability mining method provided in the above embodiments, and will not be described here.

[0276] The above only describes some embodiments of the application, and does not limit the patent scope of the application, and any equivalent structural transformation made by using the content of the specification and drawings of the application, or direct / indirect application in other related technical fields is included in the patent protection scope of the application.

Claims

1. A vulnerability exploitation method characterized by comprising: The method comprises: performing a pre-set fuzzing process on the GPU driver using a context of a target language to obtain a fuzzing result, wherein the target language is a programming language supported by a manufacturer corresponding to the GPU driver; based on the fuzzing result, determining a vulnerability mining result corresponding to the GPU driver, for representing whether the GPU driver contains a vulnerability; wherein the step of performing a pre-set fuzzing process on the GPU driver using a context of a target language to obtain a fuzzing result comprises: creating a target memory object with different access attributes for the GPU driver; based on the access attribute of the target memory object, performing a corresponding preprocessing process on the target memory object; performing a target operation related to the target memory object on the target memory object after the preprocessing process; after performing the target operation, determining the test result of the target memory object as the fuzzing result; the step of performing a corresponding preprocessing process on the target memory object based on the access attribute of the target memory object comprises: when the access attribute of the target memory object is read-only, maintaining and recording the original memory data of the target memory object, so as to determine whether the target memory object has a vulnerability by comparing whether the original memory data has changed; when the access attribute of the target memory object is writable, initializing the memory data of the target memory object as a target magic number, so as to determine whether the target memory object has a vulnerability according to whether the target magic number in the writable memory has changed.

2. The method of claim 1, wherein, Before the step of performing a pre-set fuzzing process on the GPU driver using a context of a target language, the method further comprises: loading a dynamic library corresponding to the target language; initializing the context corresponding to the target language using the symbols in the dynamic library.

3. The method of claim 2, wherein, After the step of initializing the context corresponding to the target language, the method further comprises: finding a target handle; wherein the target handle corresponds to the context corresponding to the target language; the step of performing a pre-set fuzzing process on the GPU driver using a context of a target language comprises: performing a pre-set fuzzing process on the GPU driver using the context corresponding to the target handle.

4. The method according to any one of claims 1 to 3, characterized in that, The target operation comprises at least one of: mapping the target memory object to at least one of the CPU address space and the GPU address space with the same or different access attributes; mapping the target memory object to different addresses of the CPU address space with the same or different access attributes; mapping the target memory object to different addresses of the GPU address space with the same or different access attributes; releasing the target memory object; reducing the memory of the target memory object by the driver.

5. The method of claim 4, wherein, The step of determining the test result of the target memory object after performing the target operation comprises: after performing the target operation, determining the test result of the target memory object as any one of the following: a first result representing that the read-only memory of the target memory object is writable, or the original memory data has changed; a second result, representing that the memory of the target memory object accessed is released; a third result, representing that the magic number of the target memory object is changed, or that the memory of the target memory object accessed is reduced.

6. The method of claim 5, wherein, The step of determining the vulnerability mining result of the GPU driver based on the fuzzing result comprises: in a case where the fuzzing result is the first result, determining that the vulnerability mining result represents that the GPU driver has a vulnerability of unreasonable memory attribute setting; in a case where the fuzzing result is the second result, determining that the vulnerability mining result represents that the GPU driver has a vulnerability of residual page table entry of CPU or GPU; in a case where the fuzzing result is the third result, determining that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

7. A vulnerability exploitation device, characterized by, The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the vulnerability mining method according to any one of claims 1 to 6.

8. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the vulnerability mining method according to any one of claims 1 to 6.

9. A vulnerability exploitation apparatus characterized by comprising: The apparatus comprises: a test module configured to perform a preset fuzzing process on a GPU driver by using a context of a target language to obtain a fuzzing result, wherein the target language is a programming language supported by a vendor of the GPU driver; a determination module configured to determine a vulnerability mining result of the GPU driver based on the fuzzing result, the vulnerability mining result being used to represent whether the GPU driver contains a vulnerability. The test module is further configured to: create a target memory object with different access attributes for the GPU driver; perform a corresponding preprocessing process on the target memory object based on the access attribute of the target memory object; perform a target operation related to the target memory object on the target memory object after the preprocessing process is performed; determine a test result of the target memory object after the target operation is performed, as the fuzzing result; The test module is further configured to: when the access attribute of the target memory object is read-only, maintain and record original memory data of the target memory object, so as to determine whether the target memory object has a vulnerability by comparing whether the original memory data is changed; when the access attribute of the target memory object is writable, initialize memory data of the target memory object as a target magic number, so as to determine whether the target memory object has a vulnerability according to whether the target magic number in the writable memory is changed.

10. The apparatus of claim 9, wherein, The apparatus further comprises: a loading module configured to load a dynamic library corresponding to a target language; an initialization module configured to initialize a context corresponding to the target language by using a symbol in the dynamic library.

11. The apparatus of claim 10, wherein, The apparatus further comprises: a searching module configured to search for a target handle, wherein the target handle corresponds to the context corresponding to the target language; a searching module configured to search for a target handle, wherein the target handle corresponds to the context corresponding to the target language; The test module is specifically configured to execute a preset fuzz test procedure on the GPU driver by using the context corresponding to the target handle.

12. The device of any one of claims 9 to 11, wherein, The target operation includes at least one of the following: mapping the target memory object to at least one of a CPU address space and a GPU address space with the same or different access attributes; mapping the target memory object to different addresses of the CPU address space with the same or different access attributes; mapping the target memory object to different addresses of the GPU address space with the same or different access attributes; releasing the target memory object; reducing the memory of the target memory object by the driver.

13. The apparatus of claim 12, wherein, The test module is further specifically configured to: determine a test result of the target memory object as any one of the following after executing the target operation: a first result, representing that the read-only memory of the target memory object is writable, or the original memory data is changed; a second result, representing that the memory of the released target memory object is supported to be accessed; a third result, representing that the target magic number is changed, or the memory of the reduced target memory object is supported to be accessed.

14. The apparatus of claim 13, wherein, In a case where the fuzz test result is the first result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of unreasonable memory attribute setting; in a case where the fuzz test result is the second result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of residual page table entry of CPU or GPU; in a case where the fuzz test result is the third result, it is determined that the vulnerability mining result represents that the GPU driver has a vulnerability of improper physical memory reduction processing.

Images