Information processing device and information processing method

Abstract

To perform software fuzzing efficiently. [Solution] The information processing device acquires the software package to be inspected and executes the build process and test process of the software. The information processing device then monitors the execution of the build process and test process and collects the execution processes performed in the build process and test process, as well as the command-line arguments passed to each of these execution processes. The information processing device also acquires file information if the command-line arguments of the execution process include file information. Subsequently, the information processing device outputs the collected execution processes, their command-line arguments, and file information as configuration information used for fuzzing the software package.

Description

Technical Field

[0005] ,

[0001] The present invention relates to an information processing apparatus and an information processing method for software fading.

Background Art

[0002] Fuzzing is a type of software testing that automatically generates and inputs unexpected inputs or invalid data to software in order to detect bugs and vulnerabilities in the software. Fuzzing is usually performed in the following steps.

[0003] 1. Target selection: Select the software or program to be tested. 2. Input generation: Generate input data randomly or according to a specific pattern. This includes methods of slightly changing existing input data and methods of generating completely random data. 3. Execution: Supply the generated input data to the program and execute the program. 4. Monitoring: Monitor the operation of the program and detect crashes, errors, and unexpected behaviors. 5. Analysis: Analyze the detected anomalies and identify the causes of software bugs and vulnerabilities.

[0004] Fuzzing is an important tool for many companies and security researchers because it can automatically discover bugs that are difficult to find in manual testing. In particular, it is widely used in the testing of software that handles complex inputs, such as web browsers, protocol implementations, and system software.

Prior Art Documents

Non-Patent Documents

[0005]

Non-Patent Document 1

[0006] As mentioned above, fuzzing is a method for automatically finding bugs. However, actually performing fuzzing requires human preparation, and not all processes are necessarily automated. If there is only one target for fuzzing, the cost of human preparation is not much of a problem. However, when fuzzing multiple diverse software programs, the cost of the above-mentioned human preparation becomes significant, hindering efficient fuzzing. Factors that hinder the automation of fuzzing include, for example, the following:

[0007] (1) Harness preparation: In order to perform fuzzing, it is necessary to prepare a program that calls the software to be fuzzed. In particular, if the software to be fuzzed is software that provides library functions, a driver program (harness) that calls those library functions is essential.

[0008] (2) Preparation of Seed file: In the fuzzing operation, when modifying existing input data in step 2 above, it is necessary to prepare input data that will serve as a Seed (Seed file) in advance.

[0009] (3) Adjusting command-line options: Programs usually have multiple options (command-line arguments), and when starting a program, it is necessary to specify a combination of these options. Here, the combination of these options can determine which paths are executed and which are not within the program. Therefore, in order to obtain some results in fuzzing, it is necessary to prepare multiple combinations of options. For example, no matter how many times you execute a command like command-h, you cannot properly test a program.

[0010] Therefore, the present invention aims to solve the aforementioned problems and to perform software fuzzing efficiently. [Means for solving the problem]

[0011] To solve the aforementioned problems, the present invention is characterized by comprising: an acquisition unit that acquires a package of software to be inspected; an execution unit that executes a build process and a test process of the software included in the package; a collection unit that collects the execution process executed in the build process and the test process, and the command line arguments passed to each of the execution processes, by monitoring the execution of the build process and the test process; an information acquisition unit that acquires information about the file indicated by the file path if the collected command line arguments include a file path; and an information output unit that outputs the collected command line arguments and the file information as configuration information used for fuzzing the software. [Effects of the Invention]

[0012] According to the present invention, software fuzzing can be performed efficiently. [Brief explanation of the drawing]

[0013] [Figure 1] Figure 1 is a diagram illustrating the overview of the information processing system. [Figure 2] Figure 2 shows an example of the configuration of the information output device shown in Figure 1. [Figure 3] Figure 3 is a flowchart showing an example of a processing procedure performed by an information processing system. [Figure 4] Figure 4 is a flowchart showing an example of the process for extracting software configuration information in S1 of Figure 3. [Figure 5] Figure 5 shows an example of a computer that executes an information processing program. [Modes for carrying out the invention]

[0014] The following describes embodiments for carrying out the present invention with reference to the drawings. The present invention is not limited to these embodiments.

[0015] [overview] Referring to Figure 1, the outline of the information processing device (information processing system) of this embodiment will be described. The information processing system extracts configuration information necessary for fuzzing the software (for example, appropriate command-line arguments for starting the software, file information, etc.) from the software package to be inspected. The information processing system then performs fuzzing of the software using the extracted configuration information. When the information processing system detects input data that causes the software to crash (crash input) through fuzzing, it outputs that crash input. For example, the information processing system performs triage of the crash input (for example, duplicate removal, etc.) and outputs the triaged crash input.

[0016] If the software being tested is library software (software that provides library functions), the software package typically includes a driver program (a program that calls the library functions) for testing that library software. This driver program is built together with the library software during the package build process or test process and executed during testing. Therefore, by capturing the execution of the executable file generated from the package's driver program, the information processing system can perform fuzzing even in the case of library software without having to prepare a separate harness. Furthermore, the information processing system can automatically extract the command-line arguments of the execution process necessary for fuzzing the software being tested, as well as the files that will serve as the basis for the seed file, thus enabling efficient fuzzing.

[0017] [Example Configuration] Such an information processing system includes, for example, as shown in FIG. 1, an information output device 10, a fuzzing unit 20, and a triage unit 30.

[0018] The information output device 10 downloads a package of software to be inspected and performs building and testing of the package. As a result, the information output device 10 selects a target for fuzzing without creating a harness, and also extracts information (configuration information) necessary for fuzzing. Although details regarding the configuration information will be described later, it is information indicating command line arguments of execution processes necessary for fuzzing, files, etc.

[0019] In addition, the information output device 10 generates a binary for fuzzing the software from the package of the software to be inspected. For example, the information output device 10 generates a binary for gray box fuzzing by specifying compilation options for generating the binary for gray box fuzzing in accordance with the rules of the build process of the package.

[0020] Then, the information output device 10 outputs the above configuration information and the binary for fuzzing to the fuzzing unit 20.

[0021] The fuzzing unit 20 performs fuzzing of the software using the configuration information of the software to be inspected and the binary for fuzzing the software output by the information output device 10.

[0022] For example, the fuzzing unit 20 starts a binary file for fuzzing the software using the command line arguments of the execution process shown in the configuration information and the file specified from the file information shown in the configuration information, and executes fuzzing of the software. When the fuzzing unit 20 detects input data (crash input) that causes a crash of the software during fuzzing, it saves the crash input. Thereafter, the fuzzing unit 20 outputs the saved crash input of the software to the triage unit 30.

[0023] The triage unit 30 performs triage on the crash inputs output by the fuzzing unit 20. Triage is performed, for example, by removing duplicate crash inputs, clustering crash inputs (for example, clustering groups of crash inputs with similar crash locations), and selecting crash inputs with a high risk level. The triage unit 30 then outputs the triaged crash inputs to the data storage unit.

[0024] Subsequently, the user can identify the cause of bugs or vulnerabilities in the software by analyzing the crash inputs of the software being tested, which are stored in the data storage unit.

[0025] Furthermore, if there are multiple software packages to be tested, the information processing system will execute the above process for each software package to be tested. In this way, the information processing system can efficiently fuzz multiple software packages.

[0026] [Information output device] Next, an example of the configuration of the information output device 10 will be described using Figure 2. The information output device 10 includes, for example, an input / output unit 11, a communication unit 12, a storage unit 13, and a control unit 14.

[0027] The input / output unit 11 is an interface that handles the input and output of various types of data. For example, the input / output unit 11 accepts input of information about the software package to be tested, and outputs configuration information of the software to be tested, fuzzing binaries, etc., output from the control unit 14. The communication unit 12 is an interface for communicating with external devices via a network. For example, the communication unit 12 downloads the software package to be tested via a network.

[0028] The memory unit 13 stores data, programs, etc., that are referenced when the control unit 14 performs various processes. The memory unit 13 is implemented using semiconductor memory elements such as RAM (Random Access Memory) or flash memory, or storage devices such as hard disks or optical discs. For example, the memory unit 13 stores the software package to be inspected, which is downloaded by the control unit 14.

[0029] The control unit 14 is responsible for controlling the entire information output device 10. The functions of the control unit 14 are realized, for example, by the CPU (Central Processing Unit) executing a program stored in the memory unit 13.

[0030] The control unit 14 includes a download unit (acquisition unit) 141, an execution unit 142, a recording unit (collection unit) 143, an information acquisition unit 144, an information output unit 145, and a binary file output unit 146.

[0031] The download unit 141 obtains the software package to be inspected. For example, the download unit 141 downloads the software package to be inspected via the network. Then, it stores the downloaded software package to be inspected in the storage unit 13.

[0032] The execution unit 142 executes the build process and test process included in the software package under inspection.

[0033] Furthermore, the execution unit 142 generates a binary (binary file) for fuzzing the software. For example, separately from executing the build process described above, the execution unit 142 executes a build process that specifies compilation options for generating a binary for fuzzing, in accordance with the build process rules of the software package under test. As a result, the execution unit 142 generates a binary (binary file) for fuzzing the software.

[0034] This eliminates the need for a person to understand how the software package is built and modify makefiles or config files when performing gray-box fuzzing on the software being tested.

[0035] Performing gray-box fuzzing on software requires instrumenting the software (for example, inserting measurement code at each conditional branch in the program to determine which path was taken in each conditional branch). Therefore, the software needs to be built with compilation options added to generate the fuzzing binary mentioned above. Traditionally, performing such a build required a person to understand the build method for each package and modify the package's makefile or config file.

[0036] However, the execution unit 142, in executing the package build process, generates a fuzzing binary by specifying compilation options for generating a fuzzing binary in accordance with the rules of the build process. This eliminates the need for a person to modify makefiles or config files to generate a fuzzing binary.

[0037] The recording unit 143 monitors the execution of the build process and test process of the software under inspection, collects the execution processes performed in the build process and test process, and the command-line arguments passed to each execution process, and records them in a log file.

[0038] The information acquisition unit 144 acquires information about a file if the command-line arguments recorded in the log file contain file information (for example, a file path).

[0039] For example, the information acquisition unit 144 parses the log file recorded by the recording unit 143 and determines whether there are any command-line arguments containing a file path among the command-line arguments passed to the executable file (execution process) generated by the build process. If there are any command-line arguments containing a file path, the information acquisition unit 144 retrieves the file from the file system based on the file path contained in those command-line arguments. After that, the information acquisition unit 144 saves the command-line arguments and the retrieved file to the storage unit 13.

[0040] The information output unit 145 outputs the execution process recorded in the log file, the command-line arguments passed to that execution process, and the file information (or the file itself) obtained by the information acquisition unit 144 as configuration information used for fuzzing the software under inspection.

[0041] The binary file output unit 146 outputs the fuzzing binary (fuzzing binary file) generated by the execution unit 142.

[0042] The information output device 10 outputs configuration information of the software to be inspected, allowing the fuzzing unit 20 to obtain the command-line arguments necessary for fuzzing the software to be inspected, the source file for the seed file, and the binary for fuzzing.

[0043] According to the information processing system described above, software fuzzing can be performed automatically, thus enabling efficient fuzzing.

[0044] [Example of processing procedure] Next, using Figure 3, an example of a processing procedure performed by the information processing system will be explained. First, the information output device 10 downloads the software package to be inspected, extracts the configuration information of the software package to be inspected, and generates a binary for fuzzing (S1). Then, the information output device 10 outputs the extracted configuration information and the binary for fuzzing to the fuzzing unit 20.

[0045] After S1, the fuzzing unit 20 performs fuzzing using the configuration information of the software under test and the fuzzing binary output from the information output device 10 (S2). The fuzzing unit 20 then outputs the input data that causes a crash in the software under test (crash input), which was detected by fuzzing, to the triage unit 30. Subsequently, the triage unit 30 performs triage on the input data that causes a crash in the software under test (crash input), which was detected by fuzzing, and outputs the results (S3).

[0046] Next, using Figure 4, an example of the processing procedure for extracting configuration information in S1 of Figure 3 will be explained. First, the information output device 10 receives input of information about the software package to be inspected (S11). For example, the information output device 10 receives input from the user of information about the software package to be inspected (for example, the URL from which the package is downloaded). Then, the download unit 141 downloads the software package to be inspected based on the information entered in S11 (S12).

[0047] After S12, the execution unit 142 builds the software package downloaded in S12 (S13). For example, in the case of a Debina package, commands and scripts for building the package, such as dpkg-buildpackage, are provided. Therefore, the execution unit 142 uses these commands and scripts to build the software package to be inspected.

[0048] Then, the recording unit 143 determines whether or not the executable file generated by the build is being executed during the build process in S13 (S14: Is the built executable file being executed?). For example, the recording unit 143 uses kernel drivers, virtual machines, monitoring tools, etc., to determine whether or not the executable file (execution process) generated in the build process by the execution unit 142 is being executed.

[0049] In S14, if the recording unit 143 determines that the executable file (execution process) generated by the build is running (Yes in S14), it records the command-line arguments of that execution process to the log file (S15).

[0050] For example, if the recording unit 143 determines that an execution process other than the compiler toolchain is running, it records the startup command-line arguments of that execution process in a log file. Alternatively, if the recording unit 143 determines that an executable file built from the source code of the software being inspected is running, it may also record the startup command-line arguments of that execution process in a log file. In other words, since the recording unit 143 monitors the entire build process, it can associate which executable file was generated from which source code. Therefore, the recording unit 143 uses the above association to record the startup command-line arguments of the execution processes it determines should be logged in a log file. If the recording unit 143 determines that multiple execution processes are running, it records the command-line arguments of all of those execution processes in the log file.

[0051] Furthermore, if the recording unit 143 determines that no execution processes other than the compiler toolchain have been started, it determines that the executable file (execution process) generated by the build has not been executed (No in S14) and terminates the process.

[0052] After S15, the information acquisition unit 144 determines whether or not a file has been passed as a command-line argument to the execution process recorded in the log file (S16).

[0053] For example, if the information acquisition unit 144 finds that a file path is included in the command-line arguments of an execution process recorded in the log file, it determines that a file has been passed as a command-line argument to that execution process (Yes in S16). The information acquisition unit 144 then retrieves the file at that file path from the file system and saves it (S17).

[0054] On the other hand, if the command-line arguments of the execution process recorded in the log file do not include a file path, the information acquisition unit 144 determines that no file was passed as a command-line argument (No in S16) and terminates processing.

[0055] The information output device 10 performs the above processing to extract configuration information of the software being inspected.

[0056] [Other embodiments] Furthermore, the triage unit 30 of the information processing system (see Figure 1) may determine whether or not a crash actually occurs in the software under verification based on the crash input output by the fuzzing unit 20.

[0057] In this case, the triage unit 30 obtains the binary package of the same software being verified that was handled by the information output device 10. The triage unit 30 then applies the crash input output by the fuzzing unit 20 to the binary package of the software being verified to determine whether or not a crash occurs. The triage unit 30 then outputs the crash input for which a crash has been confirmed to occur.

[0058] In this way, the triage unit 30 can output a crash input that confirms a crash has indeed occurred in the software being tested.

[0059] Furthermore, the execution unit 142 of the information output device 10 generates and outputs a fuzzing binary for the software under inspection, but is not limited to this. For example, the fuzzing unit 20 may perform fuzzing using a fuzzing binary for the software under inspection generated by an external device.

[0060] [System configuration, etc.] Furthermore, the components of each part shown in the diagram are functional concepts and do not necessarily need to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown in the diagram, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions. Moreover, all or any part of the processing functions performed by each device can be realized by a CPU and the program executed on that CPU, or by hardware using wired logic.

[0061] Furthermore, among the processes described in the embodiments described above, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above document and drawings can be arbitrarily changed unless otherwise specified.

[0062] [program] The aforementioned information processing system can be implemented by installing a program (information processing program) as packaged software or online software on a desired computer. For example, the system can function as an information processing system by running the above program on a computer. The term "computer" here includes mobile communication terminals such as smartphones, mobile phones and PHS (Personal Handyphone System), as well as terminals such as PDA (Personal Digital Assistant).

[0063] Figure 5 shows an example of a computer that executes an information processing program. Computer 1000 has, for example, memory 1010 and a CPU 1020. Computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0064] Memory 1010 includes ROM (Read Only Memory) 1011 and RAM (Random Access Memory) 1012. ROM 1011 stores, for example, a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1090. The disk drive interface 1040 is connected to the disk drive 1100. For example, a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.

[0065] The hard disk drive 1090 stores, for example, the OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, the programs that define each process executed by the above-mentioned information processing system are implemented as program modules 1093 in which executable code for the computer is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing processes similar to the functional configuration in the information processing system is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0066] Furthermore, the data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, memory 1010 or hard disk drive 1090. The CPU 1020 then reads the program module 1093 and program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as needed and executes them.

[0067] Furthermore, the program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090; for example, they may be stored in a removable storage medium and read by the CPU 1020 via a disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via a network interface 1070. [Explanation of Symbols]

[0068] 10. Information output device 11 Input / output section 12 Communications Department 13 Storage section 14 Control Unit 141 Download Section 142 Execution Unit 143 Records Department 144 Information Acquisition Department 145 Information output section 146 Binary file output section

Claims

1. An acquisition unit that acquires the software package to be inspected, An execution unit that executes the build process and test process of the software included in the package, A collection unit that monitors the execution of the build process and the test process and collects the execution processes performed in the build process and the test process, and the command-line arguments passed to each of the execution processes, If the collected command-line arguments include file information, an information acquisition unit obtains the file information, An information output unit outputs the collected execution process, the command-line arguments of the execution process, and the file information as configuration information used for fuzzing the software. An information processing device characterized by comprising:

2. The execution unit further, When executing the build process for the software, the fuzzing binary file is generated by specifying compilation options for generating a fuzzing binary file for the software based on the build process. The aforementioned information processing device is Binary file output unit that outputs a binary file for fuzzing the generated software. The information processing apparatus according to claim 1, further comprising:

3. A fuzzing unit launches a binary file for software fuzzing using the command-line arguments of the execution process shown in the software configuration information and a file identified from the information in the file, and then performs software fuzzing. The information processing apparatus according to claim 1, further comprising:

4. An information processing method performed by an information processing device, The process of obtaining the software package to be inspected, The process of executing the build process and test process of the software included in the package, The process of monitoring the execution of the build process and the test process, and collecting the execution processes performed in the build process and the test process, and the command-line arguments passed to each of the execution processes, If the collected command-line arguments include a file path, the process includes obtaining information about the file indicated by the file path, A step of outputting the collected execution process, the command-line arguments of the execution process, and the file information as configuration information to be used for fuzzing the software. An information processing method characterized by including

Images