Test device, test method, and test program

Abstract

A test device (10) is provided with: a fuzzing unit (21) that generates a fuzz to be processed by a test object processing unit (11), and acquires output information that is responded as a processing result of the fuzz from the test object processing unit (11), as fuzzing information associated with the information relating to the generated fuzz; a monitoring unit (22) that monitors monitoring information, which is the result of monitoring the inside of the test device (10) in which the test object processing unit (11) operates during processing of the fuzz; and a log recording unit (23) that records the fuzzing information and the monitoring information in association with each other as log information.

Description

Test device, test method, and test program

[0001] The present invention relates to a test device, a test method, and a test program.

[0002] Fuzzing is a testing technique that detects unknown vulnerabilities by providing unintended inputs, called fuzz, to the application under test from a fuzzing device. The fuzz can be unintended input content or an unintended amount of input. Fuzzing differs from other testing techniques, such as vulnerability scanning and penetration testing, in that it detects known vulnerabilities.

[0003] Synopsys' Defensics, described in Non-Patent Document 1, is a black-box fuzzing tool that covers a variety of protocols. Non-Patent Document 2 describes a method for identifying the fuzz that caused a problem suspected to be a vulnerability. Two methods for this identification are presented: a fuzzing technique that narrows down the causative fuzz from a large amount of fuzz, and a technique for identifying the cause by fuzzing with a fixed amount of fuzz.

[0004] Synopsys, "Defensics Fuzz Testing," [online], [Retrieved February 6, 2024], Internet <URL: https: / / www.synopsys.com / ja-jp / software-integrity / security-testing / fuzz-testing.html> IPA (Information-Technology Promotion Agency, Japan Security Center), "Guide to Using Fuzzing," July 2018, [online], [Retrieved February 6, 2024], Internet <URL: https: / / www.ipa.go.jp / security / vuln / fuzzing / ug65p9000001986g-att / 000057652.pdf>

[0005] 11 is an explanatory diagram of fuzzing. The fuzzing device 70 automatically generates fuzz, inputs the fuzz to the test target device 80, and monitors the response to the fuzz from the test target device 80, thereby reducing the labor required for testing. The fuzzing device 70 monitors the response to the fuzz from the test target device 80, and if the response is abnormal or there is no response, it detects a malfunction in the test target device 80.

[0006] 12 is a configuration diagram showing details of the fuzzing device 70 and the test target device 80. The fuzzing device 70 has a fuzz generation unit 71 that generates fuzz, a fuzz notification unit 72 that notifies the test target device 80 of the fuzz, a response detection unit 73 that detects a response from the test target device 80 to the fuzz, and a response recording unit 74 that records information about the fuzz and the content of the response to the fuzz as fuzzing information. The test target device 80 has a test target processing unit 81 that processes the fuzz, a system call unit 82 that is called by the test target processing unit 81, and a hardware unit 83 that is accessed by the system call unit 82.

[0007] Here, there are also vulnerabilities in the device under test 80 caused by fuzz that cannot be detected from the content of the response to the fuzz. Examples of such vulnerabilities include an unintended user privilege promotion process 89 that is called from the system call unit 82 (user privilege change processing unit) to the hardware unit 83 (user privilege storage unit). This user privilege promotion process 89 does not have a serious effect on its own, such as causing a crash, and therefore does not affect the response to the fuzz. However, it is a preprocessing step that can cause an unauthorized intrusion, and thus threatens security. Therefore, the fuzzing device 70 may not be able to detect vulnerabilities in the device under test 80 caused by fuzz based solely on the content of the response to the fuzz received by the response detection unit 73.

[0008] To detect such vulnerabilities, the internal state of the test target device 80 must also be monitored as monitoring information. The administrator then compares the fuzzing information in the response recording unit 74 with the monitoring information of the test target device 80 to analyze vulnerabilities of the test target device 80 caused by fuzzing. However, the comparison work by the administrator is time-consuming and requires operation for the analysis.

[0009] However, the prior art does not provide a means for supporting fuzz analysis by combining this fuzzing information with monitoring information. Non-Patent Document 1 does not describe a means for acquiring monitoring information. The fuzz identification method in Non-Patent Document 2 requires manual operations, which is time-consuming and requires time for analysis.

[0010] Therefore, the main object of the present invention is to assist in the detection of vulnerabilities in fuzzing that are difficult to detect by simply responding to fuzz.

[0011] In order to solve the above problems, the testing apparatus of the present invention comprises the following means: a fuzzing unit that generates a fuzz to be processed by a processing unit to be tested, and acquires output information returned from the processing unit to be tested as a result of processing the fuzz, as fuzzing information associated with information about the generated fuzz, a monitoring unit that monitors monitoring information that is a result of monitoring within the device in which the processing unit to be tested operates while processing the fuzz, and a log recording unit that records the fuzzing information and the monitoring information in association with each other as log information.

[0012] According to the present invention, it is possible to assist in the detection of vulnerabilities in fuzzing that are difficult to detect by simply responding to fuzz.

[0013] 6 is a configuration diagram of a test device according to the present embodiment. FIG. 7 is a diagram for explaining details of the processing of a fuzzing unit in the test device according to the present embodiment. FIG. 8 is a sequence diagram showing a first example of the first half of fuzzing according to the present embodiment. FIG. 9 is a sequence diagram showing a first example of the second half of fuzzing according to the present embodiment. FIG. 10 is a sequence diagram showing a second example of the second half of fuzzing according to the present embodiment. FIG. 11 is a configuration diagram of a test system according to the present embodiment. FIG. 12 is a hardware configuration diagram of a test device and a pseudo-call device according to the present embodiment. FIG. 13 is a sequence diagram showing a second example of the first half of fuzzing performed by the test system of FIG. 6 according to the present embodiment. FIG. 14 is a sequence diagram showing a third example of the second half of fuzzing performed by the test system of FIG. 6 according to the present embodiment. FIG. 15 is a sequence diagram showing a fourth example of the second half of fuzzing performed by the test system of FIG. 6 according to the present embodiment. FIG. 16 is an explanatory diagram of fuzzing. FIG. 17 is a configuration diagram showing details of a fuzzing device and a device under test.

[0014] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0015] 1 is a configuration diagram of a test device 10. The test device 10 accommodates the fuzzing device 70 and the test target device 80 shown in FIG. 12 in a single housing, and also includes components for assisting in the detection of vulnerabilities that are difficult to detect through fuzz alone. Similar to the test target device 80, the test device 10 has a test target processing unit 11 that processes fuzz, a system call unit 12 that is called by the test target processing unit 11, and a hardware unit 13 that is accessed by the system call unit 12.

[0016] Furthermore, like the fuzzing device 70, the test device 10 has a fuzz generation unit 71 that generates fuzz, a fuzz notification unit 72 that notifies the test target processing unit 11 of the generated fuzz, and a response detection unit 73 that detects a response to the fuzz from the test target processing unit 11, within the fuzzing unit 21. Furthermore, while the fuzzing device 70 has a response recording unit 74 that records information about the fuzz and the content of the response to the fuzz as fuzzing information, the test device 10 has a log recording unit 23. The log recording unit 23 associates the fuzzing information recorded by the response recording unit 74 with monitoring information, which is the result of monitoring the inside of the test device 10, such as the system call unit 12, by the monitoring unit 22, and records the associated information as log information. The monitoring information includes, for example, OS (Operating System) information, kernel information, file information, application log information, memory information, and CPU information.

[0017] The following is an outline of the processing steps of the test device 10 in FIG. 1 . First, (Steps 1) to (Steps 3) are steps for recording log information during fuzz execution. (Step 1) The fuzzing unit 21 generates fuzz to be processed by the test target processing unit 11 using the fuzz generation unit 71. The fuzzing unit 21 then acquires output information from the test target processing unit 11 as a result of the fuzz processing, which is returned to the response detection unit 73 by the test target processing unit 11, as fuzzing information associated with information about the generated fuzz. (Step 2) The monitoring unit 22 monitors monitoring information, which is the monitoring result of the internal operation of the test device 10 in which the test target processing unit 11 is running while processing the fuzz (Step 1). For example, the monitoring unit 22 monitors the system call unit 12 and acquires, as monitoring information, unintended privilege escalation instructed by the test target processing unit 11 to the system call unit 12 in response to the execution of fuzz at a predetermined time. (Step 3) The log recording unit 23 associates the fuzzing information (Step 1) with the monitoring information (Step 2) and records them as log information. The association of the two pieces of information may not only be at the same time, but also may be such that the monitoring information indicating the influence of the fuzz is associated with each fuzz number (serial number).

[0018] Next, (Step 4) to (Step 5) are processes for utilizing the recorded log information. (Step 4) When the monitoring unit 22 detects an abnormal state (such as an unintended privilege escalation) from the monitoring information of the log information recorded by the log recording unit 23, the monitoring unit 22 obtains fuzzing information corresponding to the monitoring information by matching it. (Step 5) The monitoring unit 22 outputs information to an administrator or the like indicating that the fuzzing information obtained in (Step 4) is the cause of the monitoring information of the abnormal state detected in (Step 4).

[0019] 2 is a diagram for explaining the details of the processing of the fuzzing unit 21 in the test device 10. The fuzzing unit 21 formed in the user space 14 generates fuzz and notifies the test target processing unit 11. The fuzz generated by the fuzzing unit 21 is data generated according to protocols supported by the test target processing unit 11, such as HTTP (Hypertext Transfer Protocol), FTP (File Transfer Protocol), and DHCP (Dynamic Host Configuration Protocol). Examples of fuzz are listed below: - A packet in which a value different from the original value is set for the "Fragment Offset" in the IP header. - A packet in which a value different from the original value is set for the "Sequence Number" in the TCP header. - A packet in which an HTTP header is set to an invalid value.

[0020] The fuzzing unit 21 then detects the response to the fuzz output from the test target processing unit 11 and records information about the fuzz (see S102 in FIG. 3 for details) and the response to the fuzz as fuzzing information in the log recording unit 23. The fuzzing unit 21 and the test target processing unit 11 exist within the same test device 10, and are implemented in separate VMs (Virtual Machines) or separate containers. The fuzzing unit 21 then notifies the monitoring unit 22 of a monitoring start instruction and a monitoring end instruction.

[0021] The monitoring unit 22 formed in the kernel space 15 monitors the test device 10 at the OS / kernel level using eBPF (extended Berkley Packet Filter) systems such as eBPF, BCC (BPF Compiler Collection), and bpftrace. For each fuzz for which the fuzzing unit 21 detects fuzzing information, the monitoring unit 22 monitors the inside of the test device 10 (mainly the system call unit 12) from the generation of the fuzz to the detection of the response to the fuzz, and records the monitoring information in the log recording unit 23. The system call unit 12 issues instructions as system calls to the hardware unit 13, which is composed of a CPU 13A, a memory 13B, a storage 13C, and the like.

[0022] The log recording unit 23, which is accessible from both the user space 14 and the kernel space 15, records the fuzzing information received from the fuzzing unit 21 in association with the monitoring information within the test device 10 received from the monitoring unit 22. The log recording unit 23 may be configured as external storage for the test device 10. The monitoring unit 22 may also monitor the resource usage status, such as the utilization rate of the CPU 13A, and control the amount of fuzz generated by the fuzzing unit 21 so that it does not affect the test target processing unit 11.

[0023] Examples of what the monitoring unit 22 monitors are shown below in (Example 1) to (Example 3). (Example 1) Monitoring system calls The monitoring unit 22 acquires the process ID (PID) of the test target processing unit 11 and monitors the system calls of that PID. The monitoring unit 22 hooks the "exec" or "execve" system call when the test target processing unit 11 is started, and acquires the PID of the test target processing unit 11. Alternatively, the monitoring unit 22 may manually check the PID of the test target processing unit 11. System call monitoring may be implemented using ptrace or a kernel module.

[0024] (Example 2) Monitoring of system logs The monitoring unit 22 hooks system calls related to file operations (open, read, write, etc.) and monitors additions to files under / var / log. The monitoring unit 22 may be implemented using a file monitoring tool such as inotify-tools.

[0025] (Example 3) Monitoring of file system The monitoring unit 22 hooks system calls related to file operations (open, read, write, etc.) and monitors file editing. In this way, the monitoring unit 22 can grasp the resources used by the test target processing unit 11 by monitoring the resource usage status via system calls.

[0026] 3 is a sequence diagram showing a first example of the first half of fuzzing. The fuzzing unit 21 generates a fuzz (S101) and notifies the log recording unit 23 of information related to the fuzz as fuzzing information (S102). The notified fuzzing information is, for example, at least one of an Ethernet header, an IP header, a TCP header, application data, and time information. The log recording unit 23 records the fuzzing information notified in S102 (S121).

[0027] The fuzzing unit 21 notifies the monitoring unit 22 that it has generated the fuzz packet in S101 (S103), causing the monitoring unit 22 to start monitoring the inside of the test apparatus 10 (S131). The fuzzing unit 21 then notifies the test target processing unit 11 of the fuzz packet (S104), causing the test target processing unit 11 to start processing the fuzz packet (S111). The fuzzing unit 21 also starts measuring the time required to process the fuzz packet (S105). The time measured in S105 is used by the fuzzing unit 21 to determine that there is no output due to a malfunction of the test target processing unit 11 when a certain period of time or more has elapsed (S106B in FIG. 5).

[0028] 4 is a sequence diagram showing a first example of the second half of fuzzing, which is executed following the first half of FIG. 3. When the test target processing unit 11 finishes processing the fuzz packet started in S111 (S112), it notifies the fuzzing unit 21 of output information, which is the processing result of the fuzz packet (S112B). The output information here may be normal output or abnormal output resulting from the processing of the fuzz packet. The fuzzing unit 21 detects the output information of S112B (S106) and notifies the monitoring unit 22 of the end of monitoring (S107).

[0029] As a result, the monitoring unit 22 ends the monitoring of the inside of the test device 10 that began in S131 (S132), and obtains the monitoring results for the monitoring period from S131 to S132 as monitoring information. The monitoring information here includes, for example, system calls (IO-related system calls, system calls related to file operations), information added to log files under / var / log, memory and CPU information, time information, etc.

[0030] The fuzzing unit 21 notifies the log recording unit 23 of the output information detected in S106 (S108), causing the log recording unit 23 to record the output information of S108 and the fuzzing information of S121 in association with each other (S122). The monitoring unit 22 also notifies the log recording unit 23 of the acquired monitoring information (S133), causing the log recording unit 23 to record the monitoring information of S133 and the fuzzing information of S121 in association with each other (S123). The log recording unit 23 then notifies the fuzzing unit 21 of the end of recording in S123 (S124).

[0031] Fig. 5 is a sequence diagram showing a second example of the second half of fuzzing, which is executed following the first half of Fig. 3. The differences from Fig. 4 are as follows: (Difference 1) The process of ending fuzz packet processing (S112), the process of notifying the output information (S112B), and the process of detecting the output information (S106) in Fig. 4 are replaced in Fig. 5 with a process of timing out (S106B) without detecting any output information even after a specified time has elapsed since S105. (Difference 2) The process of notifying the log recording unit 23 of the output information (S108) from the fuzzing unit 21 and the process of the log recording unit 23 correlating the output information with the fuzzing information and recording it (S122) are replaced with a process of notifying that no output has occurred (S108B) and a process of correlating the fact that no output has occurred with the fuzzing information and recording it (S122B).

[0032] 1 to 5, fuzzing completed within the test device 10 has been described. Below, fuzzing in the test system 100 in which the test device 10 and the pseudo-call device 30 cooperate with each other will be described with reference to FIG.

[0033] FIG. 6 is a configuration diagram of the test system 100. Below, we will explain the outline of the processing steps of the test system 100 in FIG. 6. First, (Steps 1B) to (Steps 3B) are steps for recording log information during fuzz execution. (Step 1B) The fuzzing unit 21 modifies packets sent from the pseudo-call device 30 to the test target processing unit 11 into fuzz, and acquires output information returned from the test target processing unit 11 to the pseudo-call device 30 as a result of the fuzz processing, as fuzzing information associated with information about the modified fuzz. (Step 2B) The monitoring unit 22 monitors monitoring information, which is the monitoring result within the test device 10 in which the test target processing unit 11 operates while processing the fuzz in (Step 1B). For example, the monitoring unit 22 monitors the system call unit 12 and acquires, as monitoring information, any unintended privilege escalation instructed by the test target processing unit 11 to the system call unit 12 in response to the execution of fuzz at a predetermined time. (Procedure 3B) The log recording unit 23 associates the fuzzing information of (Procedure 1B) with the monitoring information of (Procedure 2B) and records them as log information. The association of the two pieces of information may be performed not only at the same time, but also by associating the monitoring information indicating the impact of the fuzz with each fuzz number (serial number). (Procedures 4) and 5, which the test system 100 in FIG. 6 executes after (Procedure 3B), are the same as those described for the test device 10 in FIG. 1.

[0034] In order to execute each of these procedures, the test system 100 of Fig. 6 is modified as follows from the test device 10 of Fig. 2. (Modification 1) In the test system 100 of Fig. 6, a pseudo-call device 30 is added to the test device 10 of Fig. 2. The pseudo-call device 30 may be provided outside the test device 10, or may be provided as a process inside the pseudo-call device 30. The pseudo-call device 30 transmits a normal call, which is the source of fuzz generation, as a pseudo call to the test target processing unit 11 of the test device 10. Unlike fuzz, a normal call is a normal packet whose packet content itself complies with the protocol specifications.

[0035] (Modification 2) In FIG. 2 , the fuzzing unit 21 of the test device 10 generates fuzz and notifies the test target processing unit 11. On the other hand, when the fuzzing unit 21 of FIG. 6 detects (hooks) a normal call sent from the pseudo-call device 30 to the test target processing unit 11 on the transmission path (within the kernel space 15) leading to the test target processing unit 11 in the test device 10, it rewrites (modifies) the normal call into a fuzz packet and notifies the test target processing unit 11. Specifically, the fuzzing unit 21 hooks network events using the eBPF system to detect and rewrite packets, as shown in the following example: - Hooks packet reception events using XDP (eXpress Data Path) or TC (Traffic Control) and rewrites various headers, etc. - Hooks packet notification events using XDP or TC, detects output, and acquires the output content.

[0036] 2, the fuzzing unit 21 of the test device 10 obtains the response to the fuzz directly from the test target processing unit 11. On the other hand, when the fuzzing unit 21 of FIG. 6 detects (hooks) a response to the fuzz sent from the test target processing unit 11 to the pseudo-call device 30 on the transmission path (within the kernel space 15) within the test device 10, it causes the log recording unit 23 to record the response to the fuzz.

[0037] The fuzzing unit 21 may rewrite the output information returned from the test target processing unit 11 to the pseudo-call device 30 into a normal response before transmitting it to the pseudo-call device 30. The fuzzing unit 21 may also monitor the status of the pseudo-call device 30, and output an alarm if it detects that the pseudo-call device 30 has gone down.

[0038] FIG. 7 is a hardware configuration diagram of the test device 10 and the pseudo-call device 30. The test device 10 (FIGS. 1, 2, and 6) and the pseudo-call device 30 are each configured as a computer 900 having a CPU 901, RAM 902, ROM 903, HDD 904, communication I / F 905, input / output I / F 906, and media I / F 907. The communication I / F 905 is connected to an external communication device 915. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917. Furthermore, the CPU 901 controls each unit by executing a program (test program) loaded into RAM 902. This program (also called an application, or an app for short) can be distributed via a communication line or recorded on a recording medium 917 such as a USB memory.

[0039] 8 is a sequence diagram showing a second example of the first half of fuzzing performed by the test system 100 of FIG. 6. The difference from the sequence diagram of the first example performed by the test device 10 of FIG. 3 is that the fuzz generation process (S101) of FIG. 3 is replaced with S101A to S101D of FIG. 8. When the fuzzing unit 21 detects the reception of a normal packet, which is a pseudo call, from the pseudo call device 30 (S101A), it determines whether or not the current state allows notification of a fuzz packet (S109B of FIG. 9) (S101B). If the result of S101B is No, the fuzzing unit 21 discards the normal packet detected in S101A (S101D). If the result of S101B is Yes, the fuzzing unit 21 rewrites the normal packet detected in S101A into a fuzz packet (S101C), thereby completing the process of replacing the fuzz generation process (S101).

[0040] FIG. 9 is a sequence diagram showing a third example of the second half of fuzzing, which is executed following the first half of FIG. 8 . The differences from the sequence diagram of the first example executed by the test apparatus 10 in FIG. 4 are as follows: Before S112 in FIG. 4 , a process (S109A) is added in which the fuzzing unit 21 transitions to a fuzz packet notification disabled state. After S124 in FIG. 4 , a process (S109B) is added in which the fuzzing unit 21 transitions to a fuzz packet notification enabled state. This allows the test system 100 to execute the process (S101B) of FIG. 8 to determine whether a fuzz packet is notification enabled. Furthermore, by setting the second fuzz packet notification disabled state while the test target processing unit 11 is processing the first fuzz packet, the log recording unit 23 can record a log in a way that uniquely identifies which fuzz packet is being monitored during the monitoring period from S131 to S132.

[0041] 10 is a sequence diagram showing a fourth example of the second half of fuzzing, which is executed following the first half of FIG. 8. The differences from the second example executed by the test device 10 in FIG. 5 are as follows: - Before S106B in FIG. 5, a process (S109A) is added in which the fuzzing unit 21 transitions to a fuzz packet notification disabled state. - After S124 in FIG. 5, a process (S109B) is added in which the fuzzing unit 21 transitions to a fuzz packet notification enabled state. As a result, similar to FIG. 9, the test system 100 can execute the process (S101B) in FIG. 8 to determine whether a fuzz packet notification is enabled.

[0042] [Effect] The test device 10 of the present invention is characterized by having a fuzzing unit 21 that generates a fuzz to be processed by the test target processing unit 11, and acquires output information returned from the test target processing unit 11 as a result of processing the fuzz, as fuzzing information associated with information about the generated fuzz; a monitoring unit 22 that monitors monitoring information, which is the monitoring result inside the test device 10 in which the test target processing unit 11 is operating while processing the fuzz; and a log recording unit 23 that associates the fuzz information with the monitoring information and records it as log information.

[0043] As a result, the testing device 10 can assist in detecting vulnerabilities that are difficult to detect through responses to fuzz alone, since the monitoring information records clues to vulnerabilities that are difficult to detect through responses to fuzz alone. Furthermore, the following effects can also be achieved: By monitoring the inside of the testing device 10, it is possible to detect anomalies that cannot be detected through output information alone returned from the test target processing unit 11. By recording fuzzing information and monitoring information in association with each other within the testing device 10, it becomes easy to match the fuzzing information that caused the anomaly with the corresponding monitoring information. By arranging the fuzzing unit 21 and monitoring unit 22 within the testing device 10, there is no need to prepare a dedicated fuzzing device, and fuzzing can be easily performed.

[0044] The testing device 10 of the present invention is characterized in that when the monitoring unit 22 detects an abnormal state from the monitoring information of the log information recorded by the log recording unit 23, it obtains fuzzing information corresponding to the monitoring information by matching it, and outputs information to the effect that the obtained fuzzing information is the cause of the monitoring information of the detected abnormal state.

[0045] As a result, when the test device 10 monitors the inside of the test device 10, the fuzzing information and the monitoring information are stored in correspondence with each other, thereby reducing the effort required to match abnormal monitoring information with the corresponding fuzzing information.

[0046] The test device 10 of the present invention is characterized by having a fuzzing unit 21 that modifies packets sent from a pseudo-call device 30 to a test target processing unit 11 into fuzz, and acquires output information returned from the test target processing unit 11 to the pseudo-call device 30 as a result of processing the fuzz, as fuzzing information associated with information about the modified fuzz; a monitoring unit 22 that monitors monitoring information, which is the monitoring result inside the test device 10 in which the test target processing unit 11 is operating while processing the fuzz; and a log recording unit 23 that associates the fuzzing information with the monitoring information and records it as log information.

[0047] As a result, the test device 10 can perform testing by rewriting the data into a fuzz packet in the fuzzing unit 21, eliminating the need for dedicated fuzzing equipment and enabling fuzzing to be performed with reduced test operating load, regardless of the protocol of the test target processing unit 11.

[0048] The test device 10 of the present invention is characterized in that the fuzzing unit 21 further rewrites the output information returned from the test target processing unit 11 to the pseudo-call device 30 into a normal response before transmitting it to the pseudo-call device 30.

[0049] As a result, the test device 10 can directly notify the pseudo-call device 30 of unexpected output caused by fuzz input, thereby preventing the pseudo-call device 30 from stopping due to an error.

[0050] The test device 10 of the present invention is characterized in that the fuzzing unit 21 further monitors the alive state of the pseudo-call device 30, and outputs an alarm when it detects that the pseudo-call device 30 has gone down.

[0051] This allows the test device 10 to allow an administrator or the like to understand any problems that may occur when the pseudo-call device 30 remains down and fuzzing stops due to reasons such as no response from the test target processing unit 11 to the pseudo-call device 30.

[0052] REFERENCE SIGNS LIST 10 Test device 11 Test target processing unit 12 System call unit 13 Hardware unit 13A CPU 13B Memory 13C Storage 14 User space 15 Kernel space 21 Fuzzing unit 22 Monitoring unit 23 Log recording unit 30 Pseudo-call device (other device) 70 Fuzzing device 71 Fuzz generation unit 72 Fuzz notification unit 73 Response detection unit 74 Response recording unit 80 Test target device 81 Test target processing unit 82 System call unit 83 Hardware unit 100 Test system

Claims

1. A test device characterized by having: a fuzzing unit that generates fuzz to be processed by a processing unit to be tested, and acquires output information returned from the processing unit to be tested as a result of processing the fuzz, as fuzzing information associated with information about the generated fuzz; a monitoring unit that monitors monitoring information, which is the monitoring result within the device in which the processing unit to be tested is operating while processing the fuzz; and a log recording unit that associates the fuzzing information with the monitoring information and records it as log information.

2. The test device according to claim 1, wherein when the monitoring unit detects an abnormal condition from the monitoring information of the log information recorded by the log recording unit, it obtains the fuzzing information corresponding to the monitoring information by comparing it, and outputs information indicating that the obtained fuzzing information is the cause of the monitoring information of the detected abnormal condition.

3. A test device characterized by having: a fuzzing unit that modifies packets sent from another device to a processing unit under test into fuzz, and acquires output information returned from the processing unit under test to the other device as a result of processing the fuzz, as fuzzing information associated with information about the modified fuzz; a monitoring unit that monitors monitoring information, which is the monitoring result within the device in which the processing unit under test is operating while processing the fuzz; and a log recording unit that associates the fuzzing information with the monitoring information and records it as log information.

4. The test device according to claim 3, wherein the fuzzing unit further rewrites the output information returned from the test target processing unit to the other device into a normal response before transmitting it to the other device.

5. The test device according to claim 3, wherein the fuzzing unit further monitors whether the other device is alive or dead, and outputs an alarm if it detects that the other device is down.

6. A testing method comprising: a testing device having a fuzzing unit, a monitoring unit, and a log recording unit; the fuzzing unit generates fuzz to be processed by a processing unit to be tested; and acquires output information returned from the processing unit to be tested as a result of processing the fuzz, as fuzzing information associated with information related to the generated fuzz; the monitoring unit monitors monitoring information which is the monitoring result within the device in which the processing unit to be tested is operating while processing the fuzz; and the log recording unit associates the fuzzing information with the monitoring information and records it as log information.

7. A testing method comprising: a testing device having a fuzzing unit, a monitoring unit, and a log recording unit; the fuzzing unit modifies packets sent from another device to a processing unit to be tested into fuzz; and acquires output information returned from the processing unit to the other device as a result of processing the fuzz, as fuzzing information associated with information related to the modified fuzz; the monitoring unit monitors monitoring information which is the monitoring result within the device in which the processing unit to be tested operates while processing the fuzz; and the log recording unit associates the fuzzing information with the monitoring information and records it as log information.

8. A test program for causing a computer to function as the test device according to any one of claims 1 to 5.

Images