Fuzzy test-oriented vulnerability repairing method and device

Abstract

The embodiment of the invention provides a bug fixing method and device oriented to a fuzzy test, in the bug fixing method, a crash log recorded in the process of conducting the fuzzy test on a target program is obtained, and the crash log at least comprises a code line where a bug triggering crash of the target program is located. A first prompt text is constructed based on the crash log, and the first prompt text indicates to modify the code line where the vulnerability is located so as to repair the vulnerability in the target program. And inputting the first prompt text into the large model to obtain a first patch code for repairing the vulnerability. And performing first correctness verification on the first patch code, and after the first correctness verification is passed, replacing the code line where the vulnerability in the target program is located by using the first patch code.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of program testing, and more particularly to a vulnerability repair method and device for fuzzy testing. Background Art

[0002] Fuzz testing is a commonly used dynamic software testing method that continuously generates and mutates test inputs, explores execution paths, and improves test coverage, thereby discovering potential vulnerabilities in software (or programs). However, vulnerabilities that trigger software crashes in shallow logic will cause fuzz testing to continue to crash here, making it impossible to execute deeper logic, destroying the effectiveness of fuzz testing. Summary of the invention

[0003] One or more embodiments of the present specification describe a vulnerability repair method and device for fuzz testing, which can use a large model to automatically repair vulnerabilities that trigger program crashes, thereby improving the effectiveness of fuzz testing.

[0004] Firstly, a vulnerability repair method for fuzz testing is provided, including:

[0005] Obtaining a crash log recorded during fuzz testing of a target program, wherein the crash log at least includes a code line where a vulnerability that triggers the crash of the target program is located;

[0006] Constructing a first prompt text based on the crash log, the first prompt text indicating that the code line where the vulnerability is located should be modified to fix the vulnerability;

[0007] Inputting the first prompt text into the large model to obtain a first patch code for repairing the vulnerability;

[0008] A first correctness verification is performed on the first patch code, and after the first correctness verification passes, the first patch code is used to replace the code line where the vulnerability in the target program is located.

[0009] In a second aspect, a vulnerability repair device for fuzz testing is provided, comprising:

[0010] An acquisition unit, used to acquire a crash log recorded during a fuzz test of a target program, wherein the crash log at least includes a code line where a vulnerability that triggers the crash of the target program is located;

[0011] A construction unit, configured to construct a first prompt text based on the crash log, wherein the first prompt text indicates that a code line where the vulnerability is located should be modified to repair the vulnerability;

[0012] An input unit, used for inputting the first prompt text into the large model to obtain a first patch code for repairing the vulnerability;

[0013] The verification unit is used to perform a first correctness verification on the first patch code, and after the first correctness verification passes, use the first patch code to replace the code line where the vulnerability in the target program is located.

[0014] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method of the first aspect.

[0015] In a fourth aspect, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method of the first aspect is implemented.

[0016] One or more embodiments of the present specification provide a vulnerability repair method and device for fuzz testing. For a vulnerability that triggers a program crash detected during the fuzz testing process, the vulnerability is automatically repaired based on a recorded crash log using a large model, thereby allowing the fuzz testing process to continue, thereby improving the effectiveness of the fuzz testing. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 A schematic diagram of an implementation scenario of an embodiment disclosed in this specification;

[0019] Figure 2 A flow chart of a vulnerability repair method for fuzzy testing according to an embodiment of the present specification is shown;

[0020] Figure 3 A schematic diagram showing a prompt text t1 in one example of this specification;

[0021] Figure 4 A schematic diagram showing a prompt text t2 in an example of this specification;

[0022] Figure 5 A schematic diagram showing a two-stage repair method for a vulnerability in a target program;

[0023] Figure 6A schematic diagram of a fuzzy testing vulnerability repair device according to an embodiment of the present specification is shown. DETAILED DESCRIPTION

[0024] The solution provided in this specification is described below in conjunction with the accompanying drawings.

[0025] As mentioned earlier, vulnerabilities in shallow logic that trigger software crashes will cause fuzz testing to be unable to continue, which will affect the effectiveness of fuzz testing.

[0026] At present, in order to ensure that fuzz testing can be carried out continuously, the following solutions have been proposed:

[0027] First, by setting parameters, vulnerabilities can be ignored and continued. However, this solution can only ensure that fuzz testing can be continued, but cannot fix shallow vulnerabilities or test deep logic.

[0028] Second, we start from the perspective of optimizing the generated test input (also called test cases), that is, combining the semantic information of the program under test, designing the test input generation and compilation strategy, and generating diversified test inputs that meet the specifications to increase the possibility of testing deep logic and improve the coverage of fuzz testing. However, this solution requires a lot of prior knowledge and manpower, has a high adaptation cost, and cannot repair shallow vulnerabilities.

[0029] Third, by analyzing the conditional restrictions in the fuzz test execution path, constructing runtime feedback information, and guiding the fuzz test framework to generate more legal and valid test inputs, try to satisfy the previously failed program execution branches to improve the effectiveness of fuzz testing. For example, combining taint analysis and formal verification to analyze the semantics of the execution path, or identifying important test input parts for focused input mutation, etc. However, the logic implementation of this method is complex, the execution efficiency is low, and it cannot repair shallow vulnerabilities.

[0030] Fourth, by tampering with the program under test, that is, manually removing key statements such as conditional branches that cause the program to be unable to continue executing, to assist fuzz testing in triggering deep execution logic. However, this method will introduce false positives, affecting the authority of fuzz testing and the authenticity of the vulnerabilities found.

[0031] It should be understood that the above solutions are all based on the perspective of avoiding vulnerabilities to ensure the sustainability of fuzz testing. Some solutions also ensure that fuzz testing can be continued by trying to fix shallow vulnerabilities. The following is a detailed description of them.

[0032] For example, some solutions use genetic generation to generate and evaluate patches for fixing vulnerabilities, or extract repair patterns based on artificially predefined patch templates to accelerate and guide patch generation. Other solutions use symbolic execution to simulate information such as data flow and control flow during program execution to generate patches that meet specific repair conditions. However, these methods require a lot of manpower and time, and are prone to introducing a large number of false positives, resulting in poor repair effects and efficiency. In addition, traditional machine learning and deep learning methods can also be used for repair, but this method requires a large number of pre-training tasks, and the repair effect is not ideal.

[0033] In view of the fact that the above-mentioned methods of repairing vulnerabilities all have corresponding defects, this solution proposes to use a large model to automatically repair the vulnerability that triggers the program crash detected during the fuzz testing process based on the recorded crash log, so that the fuzz testing process can continue, thereby improving the effectiveness of fuzz testing.

[0034] Figure 1 A schematic diagram of an implementation scenario of an embodiment disclosed in this specification. Figure 1 In , you can perform fuzz testing on the target program based on pre-generated test cases. During the test, if a test case triggers a vulnerability that causes the target program to crash, a corresponding crash log will be generated. The crash log will at least record the code line where the vulnerability is located. In addition, intermediate information related to the crash, such as the test case that triggered the vulnerability, will also be recorded.

[0035] After the target program crashes, a prompt text for the large model can be constructed based on the crash log. The prompt text is used to instruct the large model to modify the code line where the vulnerability is located to fix the vulnerability in the target program. After that, the prompt text is input into the large model to obtain the patch code for fixing the above vulnerability. Finally, the correctness of the patch code output by the large model can be verified, and if the correctness verification passes, the patch code is used to replace the code line where the vulnerability is located in the target program, thereby obtaining an updated target program.

[0036] Figure 2 The flowchart of the vulnerability repair method for fuzzy testing according to one embodiment of the present specification is shown. The method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 2 As shown, the method may include the following steps:

[0037] Step S202, obtaining a crash log recorded during the fuzz testing of the target program, which at least includes the code line where the vulnerability that triggers the crash of the target program is located.

[0038] As mentioned above, fuzz testing is to continuously input test cases into the target program to discover potential vulnerabilities in the target program. When the vulnerability triggered by the input test case causes the target program to crash, a corresponding crash log will be generated, which will at least record the code line where the vulnerability is located.

[0039] In addition, the above crash log will also record the test case that triggered the vulnerability and how it was used, as well as other vulnerability descriptions, which include but are not limited to one or more of the following: the code file where the vulnerability is located, the function name of the function where the vulnerability is located, the complete code of the function where the vulnerability is located, and detailed error information.

[0040] Step S204 , constructing a prompt text p1 based on the crash log, wherein the prompt text p1 indicates that the code line where the vulnerability is located should be modified to repair the vulnerability in the target program.

[0041] The above content indicated by the prompt text p1 can be understood as the task goal. In practice, in addition to the task goal, the prompt text p1 can also indicate one or more of the following: programming language type, vulnerability type, role of the model, modification requirements, modification steps, vulnerability description, and output content type, etc. The following is a detailed description of these contents.

[0042] The above-mentioned programming language types may be, for example, C / C++, C#, Java or Python, etc. The above-mentioned vulnerability types may include, but are not limited to, asan vulnerabilities, ubsan vulnerabilities, etc. The above-mentioned model may play a role, for example, as an expert in fixing vulnerabilities, a program or device that is good at fixing vulnerabilities, etc. The above-mentioned modification requirements at least include the conditions that the modified code (i.e., patch code) must meet, and the conditions restrict that the target program updated based on the patch code can correctly pass the test case that triggers the above-mentioned vulnerability. Among them, correctly passing the test case here can be understood as that the execution result of the updated target program based on the test case meets expectations, etc.

[0043] In practice, the above modification requirements may also include one or more of the following: code snippets to be modified, disallowed modifications, and patch code format requirements. It should be understood that the code snippets to be modified include the code lines where the vulnerability is located, and disallowed modifications may include, for example, "should not introduce undefined new variables, functions, etc.", and patch code format requirements may include but are not limited to: "give the complete modified code", "do not omit unchanged code", and "do not modify function signature information", etc.

[0044] The above modification steps are a refinement of the process of executing the vulnerability modification task. The above vulnerability description may include but is not limited to one or more of the following: the code file where the vulnerability is located, the function name of the function where the vulnerability is located, the complete code of the function where the vulnerability is located, the code line where the vulnerability is located, and detailed error information, etc.

[0045] Finally, the above-mentioned output content types may include patch codes and other content, wherein the other content may include one or more of the following: function analysis results, vulnerability analysis results, and modification reasons, etc.

[0046] Figure 3 A schematic diagram showing a prompt text t1 in one example of the present specification. Figure 3 In the example, the prompt text t1 includes task description, modification requirements, modification steps, vulnerability description, and output content type. Among them, the task description indicates that the programming language type is: "C / C++", the vulnerability type is: "asan / ubsan vulnerability", the role of the model is: "expert in fixing vulnerabilities", and the task goal is: "Fix vulnerabilities and ensure that test cases can pass through the error location and trigger deeper code". The modification requirements contain four parts. The first part indicates unallowed modifications, which also indicate the code snippet to be modified, and the code snippet to be modified is marked by "\{\}". The second part indicates the conditions that the patch code meets, and the "original test case" is the test case that triggers the vulnerability. The third part indicates unallowed modifications: "New undefined variables, functions, etc. should not be introduced". The fourth part indicates the format requirements of the patch code: "Output the complete modified code, do not omit the unchanged code, do not modify the function signature information", etc.

[0047] Figure 3 In the modification steps, not only the detailed process of executing the vulnerability modification task is indicated, but also the information that needs special attention when analyzing the cause of the vulnerability. The vulnerability description indicates three aspects of information: the complete code of the function where the vulnerability is located, the line number of the code line where the vulnerability is located, and the detailed error information. Here, the complete code of the function where the vulnerability is located will contain the line number, so based on the line number of the code line where the vulnerability is located, the code line where the vulnerability is located can be determined from the complete code of the function. Finally, the output content types in the prompt text p1 include: function analysis results, vulnerability analysis results, repair reasons, and patch codes.

[0048] Step S206, input the prompt text p1 into the large model to obtain the patch code f1 for repairing the above vulnerability.

[0049] The above-mentioned large model can be a BERT model, a GPT series (for example, GPT-2, GPT-3, GPT-4) model, etc.

[0050] Step S208, performing a first correctness verification on the patch code f1, and after the first correctness verification passes, using the patch code f1 to replace the code line where the vulnerability in the target program is located.

[0051] Specifically, the patch code f1 can be used to update the target program and obtain the temporary program c1. Based on the test case that triggers the above vulnerability, the temporary program c1 is executed, and it is determined whether the test case triggers the temporary program c1 to crash, and whether the execution result of the temporary program c1 meets expectations. Based on the two judgment results, it is determined whether the above first correctness verification passes.

[0052] The above-mentioned assumed update can be understood as temporarily replacing the code line where the vulnerability is located in the target program with the patch code f1.

[0053] In addition, when the crash log also records the usage of the test case that triggers the vulnerability, the test case that triggers the vulnerability can be input into the temporary program c1 based on the usage to execute the temporary program c1.

[0054] In one embodiment, if the test case does not trigger the temporary program c1 to crash and the execution result is as expected, it is determined that the first correctness verification has passed. Otherwise, if the test case does not trigger the temporary program c1 to crash and the execution result is as expected, and either of the two items is not satisfied, it is determined that the first correctness verification has failed.

[0055] In another embodiment, it is also possible to determine whether the first correctness verification has passed in combination with the judgment result of whether the execution result of the test case has affected the execution results of other test cases. For example, if the test case does not trigger the temporary program c1 to crash, the execution result is as expected, and the execution result of the test case does not affect the execution results of other test cases, it is determined that the first correctness verification has passed. Otherwise, if the test case does not trigger the temporary program c1 to crash, the execution result is as expected, and the execution result of the test case does not affect the execution results of other test cases, if any one of the three items is not satisfied, it is determined that the first correctness verification has not passed.

[0056] It should be noted that passing the first correctness verification means that the vulnerability in the target program can be fixed by using the patch code f1. Thus, the code line where the vulnerability in the target program is located is replaced by the patch code f1 to obtain an updated target program.

[0057] After obtaining the updated target program, fuzz testing can then be performed on the target program, thereby ensuring the sustainability of the fuzz testing.

[0058] Failure of the first correctness verification means that the vulnerability in the target program cannot be fixed.

[0059] As mentioned above, the goal of this solution is to ensure that fuzz testing can be performed continuously, so that when it is determined that the above-mentioned vulnerability cannot be fixed, the reason why it cannot be fixed or the reason why the first correctness verification fails can be further determined.

[0060] As mentioned above, the reason for the failure of the first correctness verification may be that the test case triggered the temporary program c1 to crash, and / or the execution result of the test case did not meet expectations. Of course, it may also be that the execution result of the test case that triggered the vulnerability affected the execution results of other test cases. Since the fuzz test cannot be continued only when the test case triggers the temporary program c1 to crash. Therefore, when it is determined that the reason for the failure of the first correctness verification includes that the test case that triggers the vulnerability triggers the crash based on the temporary program c1, the vulnerability bypass process is executed.

[0061] In other words, in this solution, for the vulnerabilities detected by fuzz testing, the first stage of vulnerability repair can be performed first. If the repair is unsuccessful, the second stage of vulnerability bypass can be performed. The second stage vulnerability bypass process is described in detail below.

[0062] Specifically, a prompt text p2 can be constructed based on the crash log, and the prompt text p2 indicates that the code line where the vulnerability is located should be modified to bypass the vulnerability in the target program. The prompt text p2 is input into the large model to obtain a patch code f2 for bypassing the above vulnerability. The patch code f2 is subjected to a second correctness verification, and after the second correctness verification passes, the patch code f2 is used to replace the code line where the vulnerability is located in the target program to obtain an updated target program. The level of the second correctness verification here is lower than the first correctness verification mentioned above.

[0063] Similarly, the above content indicated by the prompt text p2 can be understood as the task goal. In practice, in addition to the task goal, the prompt text p2 can also indicate one or more of the following: the role of the model, modification requirements, modification steps, vulnerability description, and output content type, etc. The following is a detailed description of these contents.

[0064] The above-mentioned model may play the role of, for example, an assistant for fuzz testing, a program or device that helps complete fuzz testing, etc. The above-mentioned modification requirements at least include the conditions that the modified code (i.e., patch code) needs to meet, and the condition limits the test case that triggers the vulnerability and does not trigger the crash of the target program updated based on the patch code.

[0065] In practice, the modification requirements may also include one or more of the following: unallowed modifications and patch code format requirements. The unallowed modifications may, for example, be: "undefined new identifiers should not be introduced", etc. The patch code format requirements may include, but are not limited to: "give the complete modified code", "do not omit unchanged code", and "pay attention to the return value type", etc.

[0066] The above modification steps are a refinement of the process of executing the vulnerability bypass task. The above vulnerability description may include but is not limited to one or more of the following: the code file where the vulnerability is located, the function name of the function where the vulnerability is located, the complete code of the function where the vulnerability is located, the code line where the vulnerability is located, and detailed error information, etc.

[0067] Finally, the above-mentioned output content types may include patch codes and other content, wherein the other content may include one or more of the following: function analysis results, vulnerability analysis results, and modification reasons, etc.

[0068] Figure 4 A schematic diagram showing a prompt text t2 in one example of the present specification. Figure 4 In the example, the prompt text t2 includes task description, modification requirements, modification steps, vulnerability description and output content type. The task description indicates that the model plays the role of "assistant for fuzz testing" and the task goal is "handle program errors and do not let test cases execute to errors and trigger crashes". The modification requirements contain three parts. The first part indicates the conditions that the patch code must meet: "do not crash", and the second part indicates the modifications that are not allowed: "new undefined identifiers should not be introduced". The third part indicates the format requirements of the patch code: "give the complete modified code, do not omit the unchanged code, and pay attention to the return value type".

[0069] Figure 4 In the modification step, not only the detailed process of executing the vulnerability bypass task is indicated, but also the task goal is indicated: "Process the original test case normally to avoid crash". The vulnerability description indicates three aspects of information: the complete code of the function where the vulnerability is located, the line number of the code line where the vulnerability is located, and the detailed error message. As mentioned above, based on the line number, the code line where the vulnerability is located can be determined from the complete code of the function. Finally, the output content types in the prompt text p2 include: function analysis results, vulnerability analysis results, repair reasons, and patch codes.

[0070] Regarding the second correctness verification of the patch code f2, it can specifically include, based on the patch code f2, assuming that the target program is updated, to obtain a temporary program c2. Based on the test case that triggers the above vulnerability, the temporary program c2 is executed, and it is determined whether the test case triggers the temporary program c2 to crash. If the test case does not trigger the temporary program c2 to crash, it is determined that the second correctness verification passes, otherwise it is determined that the second correctness verification fails.

[0071] The above-mentioned assumed update can be understood as temporarily replacing the code line where the vulnerability is located in the target program with the patch code f2.

[0072] In addition, when the crash log also records the usage of the test case that triggers the vulnerability, the test case that triggers the vulnerability can be input into the temporary program c2 based on the usage to execute the temporary program c2.

[0073] It should be noted that the passing of the second correctness verification means that the vulnerability in the target program can be bypassed by using the patch code f2. Thus, the patch code f2 is used to replace the code line where the vulnerability in the target program is located to obtain an updated target program.

[0074] After obtaining the updated target program, fuzz testing can then be performed on the target program, thereby ensuring the sustainability of the fuzz testing.

[0075] Failure of the second correctness verification means that the vulnerability bypass has failed, and the vulnerability can be repaired or bypassed manually.

[0076] This completes the two-stage repair of the vulnerability in the target program.

[0077] To sum up the above, the overall idea of ​​this solution is that for the vulnerabilities in the target program detected by fuzz testing, the first stage of vulnerability repair can be performed first, and if the repair is unsuccessful, the second stage of vulnerability bypass can be performed.

[0078] Figure 5 A schematic diagram of a two-stage repair method for a vulnerability in a target program is shown. Figure 5 In the process of fuzz testing the target program, the crash log recorded during the fuzz testing is first obtained. Then, a prompt text p1 for the large model can be constructed based on the crash log. The prompt text p1 is also called a repair prompt text, which is used to instruct the large model to modify the code line where the vulnerability is located to repair the vulnerability in the target program. After that, the prompt text p1 is input into the large model to obtain the patch code f1 for repairing the above vulnerability. Finally, the correctness of the patch code f1 output by the large model is verified, and if the correctness verification passes, the patch code f1 is used to replace the code line where the vulnerability is located in the target program, thereby obtaining an updated target program.

[0079] If the above correctness verification fails, a prompt text p2 for the large model is constructed based on the crash log. The prompt text p2 is also called the bypass prompt text, which is used to instruct the large model to modify the code line where the vulnerability is located to bypass the vulnerability in the target program. After that, the prompt text p2 is input into the large model to obtain the patch code f2 used to bypass the above vulnerability. Finally, the correctness of the patch code f2 output by the large model is verified, and if the correctness verification passes, the patch code f2 is used to replace the code line where the vulnerability is located in the target program, thereby obtaining an updated target program. Otherwise, the vulnerability is repaired or bypassed manually.

[0080] It can be seen that this solution implements a two-stage automatic vulnerability repair process based on a large model. Combined with the fuzz testing framework, it can ensure the sustainability of fuzz testing and thus improve the effectiveness of fuzz testing. In addition, this solution can be used as a pluggable component to flexibly adapt to a variety of fuzz testing scenarios.

[0081] The advantages of this solution are described in detail below:

[0082] First, this solution solves the defects of the existing basic fuzz testing framework that it cannot repair shallow vulnerabilities, cannot test deep logic, and cannot perform continuous testing. This solution uses the intermediate information generated during the fuzz testing process to achieve automatic vulnerability repair based on a large model, which can repair shallow vulnerabilities and allow the fuzz testing framework to continuously test deeper into the deep code logic, thereby improving its testing effect.

[0083] Second, this solution solves the problem that existing fuzz testing tools that optimize test inputs need to spend a lot of overhead to extract semantic information and generate legitimate test cases. This solution does not require the analysis of the program under test in advance, and does not require the preparation of a large amount of prior knowledge to generate effective test cases. This solution focuses on repairing shallow vulnerabilities in the program under test during the execution of fuzz testing to solve the problem of the effectiveness of fuzz testing.

[0084] Third, this solution solves the limitations of some static analysis tools, such as high time consumption and high false positive rate. This solution uses a large model to repair vulnerabilities. Compared with static analysis technology, it is simple to implement, has low time consumption, and has excellent repair effect.

[0085] Corresponding to the above-mentioned vulnerability repair method for fuzzy testing, an embodiment of the present specification also provides a vulnerability repair device for fuzzy testing, such as Figure 6 As shown, the device may include:

[0086] The acquisition unit 602 is used to acquire the crash log recorded in the process of fuzz testing the target program, which at least includes the code line where the vulnerability that triggers the crash of the target program is located.

[0087] The construction unit 604 is used to construct a first prompt text based on the crash log, where the first prompt text indicates that the code line where the vulnerability is located should be modified to repair the vulnerability.

[0088] The input unit 606 is used to input the first prompt text into the large model to obtain a first patch code for repairing the vulnerability.

[0089] The verification unit 608 is used to perform a first correctness verification on the first patch code, and after the first correctness verification passes, use the first patch code to replace the code line where the vulnerability in the target program is located.

[0090] In one embodiment, the first prompt text further indicates one or more of the following:

[0091] Programming language type, vulnerability type, role of the model, modification requirements, modification steps, vulnerability description and output content type, etc.

[0092] In a more specific embodiment, the modification requirement in the first prompt text includes at least a first condition satisfied by the patch code, and the first condition restricts the target program updated based on the patch code to correctly pass the test case that triggers the above vulnerability.

[0093] In another more specific embodiment, the vulnerability description includes one or more of the following:

[0094] The code file where the vulnerability is located;

[0095] The name of the function where the vulnerability is located;

[0096] The complete code of the function where the vulnerability is located;

[0097] The line of code where the vulnerability is located;

[0098] Detailed error information.

[0099] In yet another more specific embodiment, the modifying step comprises:

[0100] Based on the detailed error information, analyze the complete code of the function where the vulnerability is located to find out the cause of the vulnerability;

[0101] Modify the code line where the vulnerability is located based on the cause of the vulnerability.

[0102] In yet another more specific embodiment, the output content types include patch codes and other content, and the other content includes one or more of the following: function analysis results, vulnerability analysis results, and modification reasons, etc.

[0103] In one embodiment, the crash log also includes a test case that triggers the vulnerability;

[0104] The verification unit 608 includes:

[0105] An updating submodule 6082 is used to update the target program using the first patch code to obtain a first temporary program;

[0106] An execution submodule 6084 is used to execute the first temporary program based on the test case;

[0107] The judgment submodule 6086 is used to judge whether the test case will trigger the first temporary program crash;

[0108] The judging submodule 6086 is further used to judge whether the execution result of the first temporary program meets expectations;

[0109] The determination submodule 6088 is used to determine that the first correctness verification has passed if the test case does not trigger the first temporary program to crash and the execution result is as expected, otherwise determine that the first correctness verification has failed.

[0110] In one embodiment, the construction unit 604 is further configured to construct a second prompt text based on the crash log when the first correctness verification fails and the reason for the failure includes that the test case triggering the vulnerability triggers the crash of the target program updated based on the first patch code, and the second prompt text indicates that the code line where the vulnerability is located should be modified to bypass the vulnerability in the target program;

[0111] The input unit 606 is further used to input the second prompt text into the large model to obtain a second patch code for bypassing the vulnerability;

[0112] The verification unit 608 is further configured to perform a second correctness verification on the second patch code, and after the second correctness verification passes, use the second patch code to replace the code line where the vulnerability in the target program is located; the level of the second correctness verification is lower than the first correctness verification.

[0113] In one embodiment, the second prompt text further indicates one or more of the following:

[0114] The role of the model, modification requirements, modification steps, vulnerability description and output content types, etc.

[0115] In a more specific embodiment, the modification requirement in the second prompt text includes at least a second condition satisfied by the patch code, and the second condition restricts the test case that triggers the vulnerability from triggering a crash of a target program updated based on the patch code.

[0116] In one embodiment, the crash log also includes,a test case that triggered the vulnerability;

[0117] The updating submodule 6082 is further used to update the target program based on the second patch code to obtain a second temporary program;

[0118] The execution submodule 6084 is further used to execute the second temporary program based on the test case;

[0119] The judgment submodule 6086 is further used to judge whether the test case will trigger the second temporary program crash;

[0120] The determination submodule 6088 is further used to determine that the second correctness verification has passed if the test case does not trigger the second temporary program crash, and otherwise determine that the second correctness verification has failed.

[0121] The functions of the functional units of the device in the above-mentioned embodiment of this specification can be implemented through the steps of the above-mentioned method embodiment. Therefore, the specific working process of the device provided by one embodiment of this specification will not be repeated here.

[0122] An embodiment of the present specification provides a vulnerability repair device for fuzz testing, which can improve the effectiveness of fuzz testing.

[0123] According to another embodiment, there is also provided a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute a combination of Figure 2 The method described.

[0124] According to another embodiment of the present invention, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the Figure 2 The method described.

[0125] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the medium or device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0126] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0127] The specific implementation methods described above further illustrate the purpose, technical solutions and beneficial effects of this specification. It should be understood that the above description is only the specific implementation method of this specification and is not intended to limit the protection scope of this specification. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of this specification should be included in the protection scope of this specification.

Claims

1. A vulnerability repair method for fuzz testing, comprising: Obtaining a crash log recorded during fuzz testing of a target program, wherein the crash log at least includes a code line where a vulnerability that triggers the crash of the target program is located; Constructing a first prompt text based on the crash log, the first prompt text indicating that the code line where the vulnerability is located should be modified to fix the vulnerability; Inputting the first prompt text into the large model to obtain a first patch code for repairing the vulnerability; A first correctness verification is performed on the first patch code, and after the first correctness verification passes, the first patch code is used to replace the code line where the vulnerability in the target program is located.

2. The method according to claim 1, wherein: The first prompt text also indicates one or more of the following: Programming language type, vulnerability type, role played by the model, modification requirements, modification steps, vulnerability description, and output content type.

3. The method according to claim 2, wherein: The modification requirements in the first prompt text include at least a first condition satisfied by the patch code, and the first condition restricts the target program updated based on the patch code to correctly pass the test case that triggers the vulnerability.

4. The method according to claim 2, wherein: The vulnerability description includes one or more of the following: The code file where the vulnerability is located; The name of the function where the vulnerability is located; The complete code of the function where the vulnerability is located; The line of code where the vulnerability is located; Detailed error information.

5. The method according to claim 2, wherein: The modification steps include: Based on the detailed error information, analyze the complete code of the function where the vulnerability is located to find out the cause of the vulnerability; Modify the code line where the vulnerability is located based on the cause of the vulnerability.

6. The method according to claim 2, wherein: The output content types include patch codes and other content; the other content includes one or more of the following: function analysis results, vulnerability analysis results, and modification reasons.

7. The method according to claim 1, wherein: The crash log also includes a test case that triggers the vulnerability; The performing a first correctness verification on the first patch code includes: Using the first patch code, assuming that the target program is updated, a first temporary program is obtained; Based on the test case, executing the first temporary program; Determining whether the test case will trigger the first temporary program to crash; Determining whether the execution result of the first temporary program meets expectations; If the test case does not trigger the first temporary program to crash and the execution result meets expectations, it is determined that the first correctness verification has passed; otherwise, it is determined that the first correctness verification has failed.

8. The method according to claim 1, further comprising: If the first correctness verification fails, and the reason for the failure includes that the test case triggering the vulnerability triggers a crash of the target program updated based on the first patch code, constructing a second prompt text based on the crash log, the second prompt text indicating that the code line where the vulnerability is located should be modified to bypass the vulnerability; Inputting the second prompt text into the large model to obtain a second patch code for bypassing the vulnerability; Perform a second correctness verification on the second patch code, and after the second correctness verification passes, use the second patch code to replace the code line where the vulnerability in the target program is located; the level of the second correctness verification is lower than that of the first correctness verification.

9. The method according to claim 8, wherein: The second prompt text further indicates one or more of the following: The role of the model, modification requirements, modification steps, vulnerability description and output content types.

10. The method according to claim 9, wherein: The modification requirements in the second prompt text include at least a second condition satisfied by the patch code, wherein the second condition restricts the test case that triggers the vulnerability from triggering a crash of a target program updated based on the patch code.

11. The method according to claim 8, wherein: The crash log also includes a test case that triggers the vulnerability; The performing a second correctness verification on the second patch code includes: Based on the second patch code, assuming that the target program is updated, a second temporary program is obtained; Based on the test case, executing the second temporary program; Determining whether the test case will trigger the second temporary program to crash; If the test case does not trigger the second temporary program to crash, it is determined that the second correctness verification has passed; otherwise, it is determined that the second correctness verification has failed.

12. A vulnerability repair device for fuzz testing, comprising: An acquisition unit, used to acquire a crash log recorded during a fuzz test of a target program, wherein the crash log at least includes a code line where a vulnerability that triggers the crash of the target program is located; A construction unit, configured to construct a first prompt text based on the crash log, wherein the first prompt text indicates that a code line where the vulnerability is located should be modified to repair the vulnerability; An input unit, used for inputting the first prompt text into the large model to obtain a first patch code for repairing the vulnerability; The verification unit is used to perform a first correctness verification on the first patch code, and after the first correctness verification passes, use the first patch code to replace the code line where the vulnerability in the target program is located.

13. The device according to claim 12, wherein: The first prompt text also indicates one or more of the following: Programming language type, vulnerability type, role played by the model, modification requirements, modification steps, vulnerability description, and output content type.

14. The device according to claim 13, wherein: The modification requirements in the first prompt text include at least a first condition satisfied by the patch code, and the first condition restricts the target program updated based on the patch code to correctly pass the test case that triggers the vulnerability.

15. The device according to claim 13, wherein: The vulnerability description includes one or more of the following: The code file where the vulnerability is located; The name of the function where the vulnerability is located; The complete code of the function where the vulnerability is located; The line of code where the vulnerability is located; Detailed error information.

16. The device according to claim 13, wherein: The modification steps include: Based on the detailed error information, analyze the complete code of the function where the vulnerability is located to find out the cause of the vulnerability; Modify the code line where the vulnerability is located based on the cause of the vulnerability.

17. The device according to claim 13, wherein: The output content types include patch codes and other content; the other content includes one or more of the following: function analysis results, vulnerability analysis results, and modification reasons.

18. The device according to claim 12, wherein: The crash log also includes a test case that triggers the vulnerability; The verification unit comprises: An updating submodule, used for updating the target program using the first patch code to obtain a first temporary program; An execution submodule, configured to execute the first temporary program based on the test case; A judgment submodule, used to judge whether the test case will trigger the first temporary program to crash; The judging submodule is further used to judge whether the execution result of the first temporary program meets expectations; The determination submodule is used to determine that the first correctness verification passes when the test case does not trigger the first temporary program to crash and the execution result meets expectations; otherwise, determine that the first correctness verification fails.

19. The device according to claim 12, The construction unit is further configured to construct a second prompt text based on the crash log when the first correctness verification fails and the reason for the failure includes that the test case triggering the vulnerability triggers a crash of a target program updated based on the first patch code, the second prompt text indicating that the code line where the vulnerability is located should be modified to bypass the vulnerability; The input unit is further used to input the second prompt text into the large model to obtain a second patch code for bypassing the vulnerability; The verification unit is further used to perform a second correctness verification on the second patch code, and after the second correctness verification passes, use the second patch code to replace the code line where the vulnerability in the target program is located; the level of the second correctness verification is lower than that of the first correctness verification.

20. The device according to claim 19, wherein The second prompt text further indicates one or more of the following: The role of the model, modification requirements, modification steps, vulnerability description and output content types.

21. The device according to claim 20, wherein: The modification requirements in the second prompt text include at least a second condition satisfied by the patch code, wherein the second condition restricts the test case that triggers the vulnerability from triggering a crash of a target program updated based on the patch code.

22. The device according to claim 19, wherein The crash log also includes a test case that triggers the vulnerability; The verification unit comprises: An updating submodule, configured to update the target program based on the second patch code to obtain a second temporary program; An execution submodule, used for executing the second temporary program based on the test case; A judgment submodule, used to judge whether the test case will trigger the second temporary program to crash; The determination submodule is used to determine that the second correctness verification passes when the test case does not trigger the second temporary program to crash, and otherwise determine that the second correctness verification fails.

23. A computer-readable storage medium having a computer program stored thereon, wherein: When the computer program is executed in a computer, the computer is caused to execute the method according to any one of claims 1 to 11.

24. A computing device comprising a memory and a processor, wherein: The memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 11 is implemented.

Images