WO2024079793A1 - Vulnerability discovery device, vulnerability discovery method, and vulnerability discovery program - Google Patents

Abstract

This vulnerability discovery device (10) includes: a virtual machine analyzing unit (121) that analyzes the VM of a script engine; a command set architecture analyzing unit (122) that analyzes a command set architecture that is a system of VM commands, collects the VM commands, and determines the command content of the collected VM commands; and a vulnerability discovery unit (123) that uses a mutated code to perform fuzzing on the VM on the basis of architecture information acquired by the virtual machine analyzing unit (121) and the command set architecture analyzing unit (122).

Description

Vulnerability detection device, vulnerability detection method, and vulnerability detection program

The present invention relates to a vulnerability detection device, a vulnerability detection method, and a vulnerability detection program.

There is a technique called dynamic testing that can be used to discover latent defects in software. Dynamic testing is a type of software testing. Software testing involves actually providing input values to the target program, running it, and observing its behavior.

One type of dynamic testing is fuzzing. Fuzzing is a technique for discovering vulnerabilities that may exist in software. Fuzzing discovers vulnerabilities by repeatedly generating and mutating input values, running the target program, observing the program's execution state, and searching for inputs that may cause problems that could lead to vulnerabilities, such as crashes.

In this case, what is used as the input value and how the input value is generated or mutated are important factors in determining the efficiency of vulnerability discovery. For example, if there is a path that can only be executed within a specific range of input values and a vulnerability exists there, it will take a long time to discover the vulnerability unless the input values required to follow that path can be found efficiently.

In current fuzzing, it is common to provide an initial input value called a seed, which is then mutated. For this reason, it is important to decide what to use as the seed and how to mutate it.

In recent years, it has become increasingly important to discover vulnerabilities in software such as script engines (also known as interpreters). Because such script engines may execute untrusted scripts from outside, it is important to discover vulnerabilities before attackers do.

There are two main methods for fuzzing execution environments that use a Virtual Machine (VM), such as script engines. The first method uses a script as a fuzzing seed, mutating it while inputting it into the script engine to search for vulnerabilities. The second method uses the bytecode generated from the script as a seed, and similarly inputs it into the script engine.

In Non-Patent Document 1, as the first method, a unique intermediate representation is defined to fuzz the PHP script engine. First, in the technology described in Non-Patent Document 1, the PHP script is converted into this intermediate representation, mutated in that state, and then converted back into the PHP script to be used as an input value.

In addition, the technology described in Non-Patent Document 2 fuzzes JavaScript (registered trademark) engines by statically analyzing JavaScript code to obtain type information, and by performing mutations using abstract syntax trees, it is possible to perform mutations that maintain types and structures.

On the other hand, as a second method, Non-Patent Document 3 proposes a method of mutating the DEX bytecode to fuzz Android's ART VM.

In the technology described in Non-Patent Document 4, in order to efficiently fuzz Java VMs (JVMs), when mutating Java bytecode, the type of mutation to be made is selected using Markov Chain Monte Carlo, with the uniqueness of code coverage at runtime as an indicator.

The technology described in Non-Patent Document 5 uses a mutation and selection technique to use fuzzing to discover defects hidden deeper within the JVM, with the aim of maintaining the correct bytecode that the JVM can execute when mutation occurs.

However, the techniques described in Non-Patent Documents 1 and 2 perform fuzzing only by mutating scripts, which means there is a problem that there is a limit to the comprehensiveness of tests when viewed from the bytecode sequence.

Furthermore, the techniques described in Non-Patent Documents 3, 4, and 5 use VM information to mutate the bytecode, which means that they cannot be applied to VMs whose internal specifications are unknown.

In order to mutate bytecode, it is necessary to know in advance information indicating where in the VM the bytecode generated by the script engine will be stored, and information on the bytecode instruction set architecture that the VM can interpret. This information is necessary because the current bytecode must be taken from the script engine's VM, mutated within the correct range as a bytecode instruction, and then embedded back into the VM.

However, the internal specifications of a VM are often not made public, and cannot be easily learned. Therefore, it is generally necessary to reverse engineer the VM to reveal the internal specifications and obtain the information independently.

　Manually and individually analyzing, designing and implementing this in a script engine is not realistic in terms of the amount of effort involved.

The present invention has been made in consideration of the above, and aims to provide a vulnerability discovery device, a vulnerability discovery method, and a vulnerability discovery program that can realize fuzzing using bytecode as an input value, even for script engines whose VM internal specifications are unknown, without requiring individual manual analysis, design, and implementation.

In order to solve the above problems and achieve the objectives, the vulnerability detection device of the present invention is characterized by having a first analysis unit that analyzes the virtual machine of a script engine, a second analysis unit that analyzes the instruction set architecture, which is the instruction system of the virtual machine, to collect virtual machine instructions and determine the instruction contents of the collected virtual machine instructions, and an execution unit that fuzzes the virtual machine using mutated code based on the architecture information obtained by the first analysis unit and the second analysis unit.

According to the present invention, fuzzing can be performed using bytecode as input, even for script engines whose VM internal specifications are unknown, without the need for individual manual analysis, design, and implementation.

FIG. 1 is a diagram illustrating an example of the configuration of a script engine. FIG. 2 is a diagram showing pseudo code of a VM included in the script engine. FIG. 3 is a diagram illustrating an example of a configuration for detecting vulnerabilities according to an embodiment. FIG. 4 is a diagram showing an example of a test script used for detecting a virtual program counter (VPC). FIG. 5 is a diagram showing an example of a test script used for detecting a branch VM instruction. FIG. 6 is a diagram illustrating an example of an execution trace. FIG. 7 illustrates an example of a VM execution trace. FIG. 8 is a diagram illustrating the process of the VM instruction boundary detection unit. FIG. 9 is a diagram for explaining the process of the virtual program counter detection unit. FIG. 10 is a diagram illustrating the process of the dispatcher detection unit. FIG. 11 is a diagram illustrating the process of the code cache detection unit. FIG. 12 is a diagram illustrating the process of the VM command determination unit. FIG. 13 is a diagram for explaining the process of the mutation unit. FIG. 14 is a flowchart illustrating a processing procedure of the analysis process according to the embodiment. FIG. 15 is a flowchart illustrating the procedure of the execution trace acquisition process shown in FIG. FIG. 16 is a flowchart illustrating a procedure of the VM instruction boundary detection process illustrated in FIG. FIG. 17 is a flowchart showing the processing procedure of the virtual program counter detection processing shown in FIG. FIG. 18 is a flowchart illustrating the procedure of the dispatcher detection process shown in FIG. FIG. 19 is a diagram for explaining the conditional branch flag detection process shown in FIG. FIG. 20 is a flowchart illustrating the processing procedure of the code cache detection processing shown in FIG. FIG. 21 is a flowchart illustrating the procedure of the VM execution trace acquisition process illustrated in FIG. 14 . FIG. 22 is a flowchart illustrating the procedure of the VM command collection process illustrated in FIG. FIG. 23 is a flowchart illustrating a processing procedure of the VM command determination processing shown in FIG. FIG. 24 is a flowchart of the branch VM instruction determination process shown in FIG. FIG. 25 is a flowchart illustrating the procedure of the conditional branch VM instruction determination process illustrated in FIG. FIG. 26 is a flowchart illustrating the procedure of the called VM instruction determination process illustrated in FIG. FIG. 27 is a flowchart illustrating the procedure of the return VM instruction determination process illustrated in FIG. FIG. 28 is a flowchart of the bytecode extraction process shown in FIG. FIG. 29 is a flowchart showing the procedure of the mutation process shown in FIG. FIG. 30 is a flowchart showing the procedure of the execution process shown in FIG. FIG. 31 is a diagram illustrating an example of a computer in which a program is executed to realize vulnerability discovery.

Below, embodiments of the vulnerability discovery device, vulnerability discovery method, and vulnerability discovery program according to the present application are described in detail with reference to the drawings. Furthermore, the present invention is not limited to the embodiments described below.

[Embodiment]
The vulnerability detection device of the embodiment is a vulnerability detection device that can perform fuzzing using bytecode as input value, even for script engines whose VM internal specifications are unknown, without requiring individual manual analysis, design, and implementation.

The vulnerability discovery device according to the embodiment executes test scripts while monitoring the binaries of the script engine, and obtains branch traces and memory access traces as execution traces. The vulnerability discovery device analyzes the VM based on the execution traces, and obtains, as architecture information, VM instruction boundaries, a virtual program counter (VPC), a dispatcher, a conditional branch flag, and a code cache in which executed VM instructions are stored.

The vulnerability detection device executes test scripts while monitoring the VPC and dispatcher to obtain VM execution traces. By analyzing the VM execution traces, the vulnerability detection device collects VM instructions, determines the contents of the VM instructions, and obtains information on the instruction set architecture.

Then, the vulnerability detection device uses the mutated code to fuzz the VM based on the acquired architecture information. The vulnerability detection device achieves fuzzing by repeatedly extracting, mutating, embedding, and executing bytecode based on the acquired architecture information. The vulnerability detection device executes a seed script while monitoring the code cache to extract bytecode from the code cache, mutates the extracted bytecode, and embeds it back into the code cache to perform fuzzing.

The configuration and function of a typical script engine will be described with reference to Figures 1 and 2. Figure 1 is a diagram for explaining an example of the configuration of a script engine. As shown in Figure 1, script engine 1 has a bytecode compiler 2 and a VM 3. Furthermore, bytecode compiler 2 has a syntax analysis unit 4 and a bytecode generation unit 5. Furthermore, VM 3 has a code cache unit 6, a fetch unit 7, a decode unit 8, and an execution unit 9. These fetch unit 7, decode unit 8, and execution unit 9 are executed repeatedly and are called an interpreter loop. Then, script engine 1 accepts the input of a script.

The syntax analysis unit 4 receives the script as input, and through lexical and syntactic analysis generates an Abstract Syntax Tree (AST), which it outputs to the bytecode generation unit 5. The bytecode generation unit 5 receives the AST as input, converts it into bytecode, and stores it in the code cache unit 6.

The fetch unit 7 fetches the VM opcode from the code cache unit 6 and outputs it to the decode unit 8. Here, the VM opcode refers to the opcode portion of the VM instruction. The decode unit 8 receives the VM opcode as input, interprets the VM opcode using a decoder/dispatcher, and dispatches it to the corresponding program. The execution unit 9 executes the program corresponding to the VM instruction. The contents written in the script are executed by executing the VM instructions one after another through a repeated interpreter loop.

The functions of the components of the script engine will be described with reference to Figure 2. Figure 2 is a diagram showing pseudocode for a VM in the script engine. As shown in Figure 2, the pseudocode first initializes the VPC (line 1). In the pseudocode, the while loop is the interpreter loop (line 2). In the pseudocode, the VM opcode pointed to by the VPC is obtained from the code cache (line 3), and is decoded and dispatched using a Switch statement (lines 4, 5, and 7). Then, in the pseudocode, the program corresponding to the VM opcode that was dispatched is executed (lines 6 and 8).

In addition, a branch VM command is a VM command that causes a branch to occur within a script, and a conditional branch flag is an area that holds a flag indicating whether or not a branch will be taken when a conditional branch occurs.

[Configuration of vulnerability detection device]
Next, the configuration of the vulnerability discovering device 10 according to the embodiment will be specifically described with reference to Fig. 3. Fig. 3 is a diagram illustrating an example of the configuration of the vulnerability discovering device according to the embodiment.

As shown in FIG. 3, the vulnerability discovery device 10 has an input unit 11, a control unit 12, a memory unit 13, and an output unit 14. The vulnerability discovery device 10 accepts inputs of a test script, a script engine binary, and a seed script.

The input unit 11 is composed of input devices such as a keyboard and a mouse, and accepts information input from the outside and inputs it to the control unit 12. The input unit 11 also has a communication interface for sending and receiving various information to and from other devices connected via a wired connection or a network, etc., and accepts input of information sent from other devices. The input unit 11 accepts input of test scripts, script engine binaries, and seed scripts, and outputs them to the control unit 12.

A test script is a script that is input when dynamically analyzing a script engine to obtain an execution trace and a VM execution trace. Details of test scripts are described later. A script engine binary is an executable file that constitutes a script engine. A script engine binary may be composed of multiple executable files. A seed script is a script that contains bytecode that serves as the initial input value.

The control unit 12 has an internal memory for storing programs that define various processing procedures and the necessary data, and executes various processes using these. For example, the control unit 12 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). The control unit 12 has a virtual machine analysis unit 121 (first analysis unit), an instruction set architecture analysis unit 122 (second analysis unit), and a vulnerability discovery unit 123.

The virtual machine analysis unit 121 analyzes the VM of the script engine. The virtual machine analysis unit 121 obtains multiple execution traces by changing the conditions at run time, analyzes the multiple execution traces using differential execution analysis, and obtains VPCs and conditional branch flags. The virtual machine analysis unit 121 also analyzes the script engine binary to obtain VM instruction boundaries and dispatchers. The virtual machine analysis unit 121 detects a code cache from the VM execution trace. The VM instructions to be executed are stored in the code cache.

The virtual machine analysis unit 121 has an execution trace acquisition unit 1211 (first acquisition unit), a VM instruction boundary detection unit 1212 (first detection unit), a virtual program counter detection unit 1213 (second detection unit), a dispatcher detection unit 1214 (third detection unit), a conditional branch flag detection unit 1215 (fourth detection unit), and a code cache detection unit 1216 (fifth detection unit).

The execution trace acquisition unit 1211 accepts the test script and the script engine binary as input. The execution trace acquisition unit 1211 acquires an execution trace by executing the test script while monitoring the execution of the script engine binary.

An execution trace consists of a branch trace and a memory access trace. A branch trace records the type of branch instruction at the time of execution, the branch source address, and the branch destination address. A memory access trace records the type of memory operation and the memory address of the operation target. It is known that branch traces and memory access traces can be acquired by instruction hooks. The execution trace acquired by the execution trace acquisition unit 1211 is stored in the execution trace DB 131.

The VM instruction boundary detection unit 1212 clusters the execution traces to detect the boundaries of each VM instruction. The VM instruction boundary detection unit 1212 clusters the execution traces to detect clusters with a threshold or more of execution counts as VM instructions. In clustering, consecutive code regions that are executed multiple times are detected. For example, executed instructions that are close in distance to each other in the code may be grouped together, common subsequences of executed code blocks may be searched for, or other methods may be used. The vulnerability discovery device 10 detects the start and end points of consecutive instruction sequences that make up the detected VM instruction as boundaries. The VM instruction boundaries detected here are used in VPC detection and dispatcher detection.

The virtual program counter detection unit 1213 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131 to detect the VPC. The virtual program counter detection unit 1213 analyzes multiple execution traces using differential execution analysis focusing on the number of memory reads and the boundaries of each VM instruction detected by the VM instruction boundary detection unit 1212 to detect the VPC. The virtual program counter detection unit 1213 makes use of the fact that a read into the memory that holds the VPC always occurs after the execution of each VM instruction, and detects the VPC by discovering the destination of this read.

For this reason, the virtual program counter detection unit 1213 uses differential execution analysis that focuses on the number of memory reads to detect VPCs. The virtual program counter detection unit 1213 compares execution traces of multiple test scripts acquired using the test scripts, and finds memories whose memory read counts change in proportion to both the increase or decrease in the number of repetitions and the number of repeated statements. The virtual program counter detection unit 1213 then refers to the boundaries of each VM instruction detected by the VM instruction boundary detection unit 1212, and narrows down the memory values that have been read to those that always point to the start point of the VM instruction. The virtual program counter detection unit 1213 detects this memory as a VPC.

The dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary based on the boundaries of the VM instructions detected by the VM instruction boundary detection unit 1212, and detects the parts with high similarity between each VM instruction as dispatchers. As a premise, the dispatcher is realized by referencing the pointer cache and jumping to the pointer of the next VM instruction handler. The dispatchers are placed in a distributed manner at the rear of each VM instruction handler, and the code therein is generally highly identical. The vulnerability detection device detects the dispatcher using a specified method by searching for code with high similarity that exists at the rear of such VM instruction handlers. To detect the parts with high similarity, for example, a series alignment algorithm may be used, or other methods may be used.

The conditional branch flag detection unit 1215 extracts and analyzes the execution trace for the second test script stored in the execution trace DB 131 to discover the conditional branch flag. The conditional branch flag detection unit 1215 analyzes multiple execution traces using differential execution analysis that focuses on the number of times memory is read, and detects the conditional branch flag. The conditional branch flag detection unit 1215 executes conditional branches in various patterns, and detects the memory that stores the conditional branch flag by comparing the pattern of memory changes at that time with the conditional branch pattern in the test script.

The code cache detection unit 1216 detects the code cache, which is a cache in which the VM instructions to be executed are stored, from the VM execution trace based on the execution trace, VPC, and VM execution trace.

The code cache detection unit 1216 detects the memory area pointed to by the VPC as a code cache from the VM execution trace. The code cache detection unit 1216 detects the code location from which the memory allocation function that allocated this code cache was called from the execution trace. The code cache detection unit 1216 detects all memory areas allocated at this code location from the VM execution trace as code caches.

The code cache detection unit 1216 detects code locations that are writing to the code cache from the execution trace. The code cache detection unit 1216 detects writing by these code locations in the VM execution trace as updates to the code cache.

The instruction set architecture analysis unit 122 analyzes the instruction set architecture, which is the system of VM instructions. The instruction set architecture analysis unit 122 collects VM instructions. It determines the instruction content of the collected VM instructions.

The instruction set architecture analysis unit 122 has a VM execution trace acquisition unit 1221 (second acquisition unit), a VM instruction collection unit 1222 (first collection unit), and a VM instruction determination unit 1223 (first determination unit).

Like execution trace acquisition unit 1211, VM execution trace acquisition unit 1221 accepts test scripts and script engine binaries as input. VM execution trace acquisition unit 1221 acquires VM execution traces by monitoring VPCs and pointers to VM instruction handlers dispatched by the dispatcher. VM execution trace acquisition unit 1221 acquires VM execution traces, which are execution traces executed on a VM, by executing test scripts while monitoring the execution of script engine binaries. When detecting branch VM instructions, VM execution trace acquisition unit 1221 executes multiple test scripts to acquire VM execution traces. VM execution trace acquisition unit 1221 links pointers to VM instructions with VM instructions, and virtually assigns VM opcodes as identifiers to each.

A VM execution trace is an execution trace executed in a VM, in which a VM opcode is virtually assigned as an identifier, and in which a pointer to the executed VM handler and a VPC are recorded. A VM execution trace is a record of a pointer to an executed VM instruction handler and a VPC. Specifically, a VM execution trace is composed of a VPC and a VM opcode for each executed VM instruction. The recording of a VPC can be achieved by monitoring the memory of the VPC detected by the virtual program counter detection unit 1213. A VM opcode is an identifier virtually assigned to each of a pointer to a VM instruction and a VM instruction that are linked together. The VM execution trace acquired by the VM execution trace acquisition unit 1221 is stored in the VM execution trace DB 133.

The VM command collection unit 1222 receives the VPC and dispatcher as input, executes the script while monitoring the VPC and dispatcher, and obtains the VM execution trace. The VM command collection unit 1222 collects VM commands from the VM execution trace.

The VM instruction determination unit 1223 determines the instruction content of the VM instruction collected by the VM instruction collection unit 1222. First, the VM instruction determination unit 1223 determines whether it is a branch VM instruction based on the variation in the amount of change in VPC for each VM opcode in the VM execution trace.

The VM instruction determination unit 1223 retrieves and analyzes the VM execution traces stored in the VM execution trace DB 133 to determine whether the VM instruction is a branch VM instruction. For each VM opcode assigned as an identifier, the VM instruction determination unit 1223 collects the amount of change in VPC before and after its execution. If the VM opcode is other than a branch VM instruction, the amount of change in VPC is almost constant. On the other hand, if the VM opcode is a branch VM instruction, the VPC varies depending on the branch destination.

The VM instruction determination unit 1223 therefore determines whether an instruction is a branch VM instruction based on the variance in the amount of change in the virtual program counter for each VM opcode in the VM execution trace. The VM instruction determination unit 1223 focuses on the fact that the amount of variance in the VPC value differs between branch VM instructions and other VM instructions, determines a threshold value, and determines instructions with greater variance in the VPC value as branch VM instructions. Specifically, the VM instruction determination unit 1223 evaluates the variance in the amount of change in the VPC for each VM opcode using variance, and determines instructions with variance equal to or greater than a certain threshold as branch VM instructions.

In addition, in order to construct an accurate control flow graph, the VM instruction determination unit 1223 determines which of the branch VM instructions are conditional branch VM instructions. When a conditional branch occurs, access to a conditional branch flag is always generated to determine the branch destination. Therefore, a conditional branch VM instruction can be determined by verifying whether the conditional branch flag is accessed when each branch VM instruction is executed. In other words, if the conditional branch flag is accessed when a branch VM instruction is executed, it can be determined that it is a conditional branch VM instruction, and if it is not accessed, it is not a conditional branch VM instruction. Therefore, the VM instruction determination unit 1223 determines that, among the branch VM instructions, those that involve access to a conditional branch flag are conditional branch VM instructions based on the VM execution trace and memory access trace.

Furthermore, the VM instruction determination unit 1223 also determines call and return VM instructions. A branch caused by a call VM instruction is characterized in that the address immediately following the caller's bytecode is saved, and after the called subroutine is executed, the return VM instruction returns to that saved address. Thus, when a certain branch VM instruction is designated as instruction 1, and another subsequent branch VM instruction is designated as instruction 2, and instruction 2 returns to the address immediately following instruction 1's bytecode, the VM instruction determination unit 1223 determines that the pair of instructions 1 and 2 are call and return VM instructions.

Next, the VM instruction determination unit 1223 determines that, among the branch VM instructions, a branch VM instruction that accesses a conditional branch flag is a conditional branch VM instruction. In this case, the VM instruction determination unit 1223 retrieves a list of opcodes of branch VM instructions from the architecture information DB 132, retrieves one VM execution trace from the VM execution trace DB 133, and retrieves the corresponding execution trace from the execution trace DB 131.

The VM instruction determination unit 1223 extracts one location where a branch VM instruction is being executed from the VM execution trace, and extracts a memory access trace corresponding to the execution of the extracted branch VM instruction from the execution trace.

The VM instruction determination unit 1223 determines whether the retrieved branch VM instruction is accessing a conditional branch flag based on the memory access trace. If the conditional branch flag is being accessed, the VM instruction determination unit 1223 determines that the retrieved branch VM instruction is a conditional branch VM instruction.

Then, the VM instruction determination unit 1223 scans the VM execution trace for any branch VM instruction, and if there is a branch instruction that branches immediately after this arbitrary branch VM instruction, it determines that this arbitrary branch VM instruction is a call VM instruction.

In this case, the VM instruction determination unit 1223 extracts a list of opcodes of branch VM instructions from the architecture information DB 132, and extracts one VM execution trace from the VM execution trace DB 133. The VM instruction determination unit 1223 extracts one location where a branch VM instruction is being executed from the VM execution trace.

The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the fetched branch VM instruction. Then, based on the scan results, the VM instruction determination unit 1223 determines whether or not there is a branch VM instruction that branches immediately after the fetched branch VM instruction. If there is a branch VM instruction that branches immediately after the fetched branch VM instruction, the VM instruction determination unit 1223 determines that the fetched branch VM instruction is a call VM instruction.

Furthermore, the VM instruction determination unit 1223 extracts a call VM instruction from the VM execution trace, and if there is a branch VM instruction that branches immediately after the extracted call VM instruction, it determines that the branch VM instruction that branches immediately after the extracted call VM instruction is a return VM instruction.

In this case, the VM instruction determination unit 1223 extracts a list of opcodes of branch VM instructions from the architecture information DB 132, and extracts one VM execution trace from the VM execution trace DB 133. The VM instruction determination unit 1223 extracts one location where a calling VM instruction is being executed from the VM execution trace.

The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the retrieved call VM instruction, and determines whether there is a branch VM instruction that branches immediately after the retrieved call VM instruction.

If there is a branch VM instruction that branches immediately after the fetched call VM instruction, the VM instruction determination unit 1223 determines that the branch VM instruction that branches immediately after the fetched call VM instruction is a return VM instruction.

The vulnerability discovery unit 123 fuzzes the VM using the mutated code based on the architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122. The vulnerability discovery unit 123 executes a seed script while monitoring the code cache to extract bytecode from the code cache. The vulnerability discovery unit 123 then mutates the extracted bytecode and embeds it again in the code cache for execution. The vulnerability discovery unit 123 has a mutation unit 1231 and a fuzzing execution unit 1232.

The mutation unit 1231 mutates the bytecode extracted by the fuzzing execution unit 1232 using a predetermined method such as adding, deleting, or changing VM instructions, and outputs the updated bytecode dictionary to the fuzzing execution unit 2132.

The fuzzing execution unit 1232 accepts the seed script, VPC, and code cache as input. The fuzzing execution unit 1232 then executes the seed script while monitoring the code cache to extract bytecode from the code cache. The fuzzing execution unit 2132 re-embeds the mutated code at the destination pointed to by the VPC in the code cache and resumes execution. The fuzzing execution unit 1232 outputs the input value (bytecode) that caused a problem such as a crash during execution.

The storage unit 13 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk, and stores the processing program that operates the vulnerability detection device 10, data used during the execution of the processing program, etc. The storage unit 13 has an execution trace database (DB) 131, a VM execution trace DB 133, and an architecture information DB 132 that stores architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122.

The execution trace DB 131 and the VM execution trace DB 133 store the execution traces and VM execution traces acquired by the execution trace acquisition unit 1211 and the VM execution trace acquisition unit 1221, respectively. The execution trace DB 131 and the VM execution trace DB 133 are managed by the vulnerability discovery device 10. Of course, the execution trace DB 131 and the VM execution trace DB 133 may be managed by other devices (servers, etc.), in which case the execution trace acquisition units 1211 and 1221 output the acquired execution traces and VM execution traces to management servers, etc., of the execution trace DB 131 and the VM execution trace DB 133 via the communication interface of the output unit 14, and store them in the execution trace DB 131 and the VM execution trace DB 133.

The output unit 14 is, for example, an LCD display or a printer, and outputs various information including information related to the vulnerability detection device 10. The output unit 14 may also be an interface that handles the input and output of various data between an external device, and may output various information to an external device.

[Test script configuration]
Let us now explain the test script. A test script is a script that is input when dynamically analyzing a script engine. This test script focuses on the number of branch instruction executions and memory reads and writes, and is used to capture the difference in the behavior of the script engine that occurs when the test script is executed a different number of times. This test script is prepared in advance of the analysis and is created manually. Creating it requires knowledge of the specifications of the target script language.

Figure 4 shows an example of a test script (first test script) used to detect VPCs. The first test script uses a repetitive process (line 2). The first test script changes the execution conditions and generates differences by increasing or decreasing the number of repetitions (line 2) and the number of repeated statements (lines 3 to 5) in the test script.

FIG. 5 is a diagram showing an example of a test script (second test script) used to detect branch VM instructions. The second test script uses multiple conditional branches (lines 4 to 8). In the second test script, the branch conditions are controlled so that the multiple conditional branches are either taken or not taken in a specific order pattern (lines 1 and 5). In the second test script, the number of conditional branches and the order pattern of branch success or failure are changed to generate differences.

Execution Trace Configuration
Next, the execution trace will be described. Fig. 6 is a diagram showing an example of an execution trace. As described above, an execution trace is composed of a branch trace and a memory access trace. Fig. 6 shows an excerpt of an execution trace. The structure of an execution trace will be described below with reference to Fig. 6.

An execution trace has an element called trace. Trace indicates whether the log line is a branch trace or a memory access trace.

A branch trace log line has the format shown, for example, in lines 1 to 10 of Figure 6, and consists of three elements: type, src, and dst. type indicates whether the executed branch instruction was a call instruction, a jmp instruction, or a ret instruction. src indicates the address of the branch source, and dst indicates the address of the branch destination.

A log line of a memory access trace has the format shown, for example, in lines 11 to 13 of Figure 6, and consists of three elements: type, target, and value. Type indicates whether the memory access is a read or write. Target indicates the memory address that is the target of the memory access. Value stores the result of the memory access.

[VM Execution Trace Configuration]
Next, a VM execution trace will be described. Fig. 7 is a diagram showing an example of a VM execution trace. As described above, a VM execution trace is a record of a VM opcode and a VPC. Fig. 7 shows a part of a VM execution trace. The configuration of a VM execution trace will be described below with reference to Fig. 7.

A log line of a VM execution trace is, for example, in the format shown in Figure 7, and consists of two elements: vpc and vmop (vm opcode). vpc indicates the value of the VPC. Also, vmop indicates the value of the VM opcode that is virtually assigned to each pointer that points to the beginning of the VM instruction handler to be executed, obtained from the pointer cache.

[Processing of VM instruction boundary detection unit]
Next, a description will be given of the processing of the VM instruction boundary detection unit 1212. FIG.

The VM instruction boundary detection unit 1212 detects the boundaries of each VM instruction. At this time, the VM instruction boundary detection unit 1212 detects VM instructions and their boundaries for threaded code type VMs, which do not have an interpreter loop and therefore make it difficult to grasp the boundaries of VM instructions. Specifically, the VM instruction boundary detection unit 1212 extracts execution traces from the execution trace DB 131. Then, as shown in FIG. 8, the VM instruction boundary detection unit 1212 clusters the execution traces using a predetermined method, and detects clusters with a threshold or more of execution counts as VM instructions (e.g., VM instruction handlers 1 to 3). The VM instruction boundary detection unit 1212 detects the start and end points of the consecutive instruction strings that make up a VM instruction as boundaries.

[Processing of Virtual Program Counter Detection Unit]
Next, the processing of the virtual program counter detection unit 1213 will be described. The virtual program counter detection unit 1213 detects the VPC and the pointer cache. The detection of the virtual program counter is realized by analyzing the log of the memory access trace of the acquired execution trace. The virtual program counter detection unit 1213 uses differential execution analysis focusing on the number of times memory is read. FIG. 9 is a diagram for explaining the processing of the virtual program counter detection unit 1213.

The virtual program counter detection unit 1213 extracts one execution trace by the first test script from the execution trace DB 131. The number of times the VPC is read is proportional to the number of repetitions in the test script and the number of statements in the repetitive process. If the number of repetitions is N and the number of repeated statements is M, then approximately MN VPC reads will occur. For this reason, the virtual program counter detection unit 1213 extracts memory that has increased by 4MN and 9MN in the execution trace for the first test script in which N and M have been increased to 2N and 2M, respectively, and 3N and 3M. Specifically, as shown in FIG. 9, the virtual program counter detection unit 1213 extracts memory areas that have a monotonically increasing read/write for each VM instruction execution ((1) in FIG. 9).

Then, the virtual program counter detection unit 1213 detects as a VPC a memory value that has been read and that always points to the start point of a VM instruction. Specifically, the virtual program counter detection unit 1213 compares the VPC's pointing destination with the address of the VM instruction handler, and narrows it down to matching memory areas ((2) in FIG. 9).

[Dispatcher Detection Processing]
Next, a description will be given of the processing of the dispatcher detection unit 1214. The dispatcher detection unit 1214 detects a dispatcher by analyzing the binary of the script engine using a predetermined method. FIG. 10 is a diagram for explaining the processing of the dispatcher detection unit 1214.

The dispatcher detection unit 1214 detects dispatchers. Based on the boundaries of VM instructions detected by the VM instruction boundary detection unit 1212, the dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary. Then, based on the assumption that the similarity of dispatcher code is high ((1) in FIG. 10), the dispatcher detection unit 1214 calculates the similarity between the codes of each VM instruction and detects the portion with high similarity between all VM instructions as a dispatcher. The dispatcher detection unit 1214 can detect the code that is commonly executed in the latter half of the VM instructions as a dispatcher ((1) in FIG. 10).

[Code cache detection part]
Next, a description will be given of the processing of the code cache detection unit 1216. FIG.

The code cache detection unit 1216 detects the memory area pointed to by the VPC as a code cache from the VM execution trace ((1) in FIG. 11).

The code cache detection unit 1216 detects the code location that called the memory allocation function that allocated this code cache from the execution trace ((2) in FIG. 11). The code cache detection unit 1216 detects all memory areas allocated at this code location from the VM execution trace as code caches ((3) in FIG. 11).

The code cache detection unit 1216 detects the code location that is writing to the code cache from the execution trace ((4) in FIG. 11). The code cache detection unit 1216 detects the writing by this code location in the VM execution trace as an update to the code cache ((5) in FIG. 11).

[VM command determination unit]
Next, the process of the VM instruction determination unit 1223 will be described. The VM instruction determination unit 1223 first analyzes the acquired VM execution trace log to determine a branch VM instruction. The test script here may be any script that includes a branch VM instruction and includes a branch control syntax. For example, the test script is prepared by collecting information from the Internet or obtaining information from official documents.

First, the VM instruction determination unit 1223 associates a pointer to a VM instruction with a VM instruction for each VM execution trace in the VM execution trace DB 133, and virtually assigns a VM opcode as an identifier to each of them. Figure 12 is a diagram explaining the processing of the VM instruction determination unit 1223.

Here, if a VM instruction is a branch instruction, the advance of the VPC changes depending on the branch destination. On the other hand, if it is not a branch instruction, the advance of the VPC changes depending on the size of the VM instruction. For this reason, when pairs of VM instruction opcodes and pointers to VM instructions are collected and the advance of the VPC is examined for each opcode, if it is a branch instruction, the advance of the VPC will vary depending on the branch destination.

Therefore, the VM instruction determination unit 1223 uses variance to evaluate the variance of the pointer to this VM instruction. The VM instruction determination unit 1223 calculates the variance of the amount of change in the VPC for each VM opcode, and narrows it down to only VM opcodes whose calculated variance is greater than a threshold. In this way, the VM instruction determination unit 1223 associates the pointer with the VM instruction, and determines that the VM instruction with variance in the advance of the VPC (VM instruction handler 3 in the example of FIG. 12) is a branch VM instruction ((1) in FIG. 12).

When the set O of VPC advances for a certain opcode is O={ _o0 , _o1 , ..., _oN } (see equation (1) for the average of VPCo) and t is a threshold, whether or not an instruction is a branch instruction is determined based on the variance s (see equation (2)) as shown in equation (3). In this way, the VM instruction determination unit 1223 determines whether an instruction is a branch VM instruction.

In addition, for VM instructions other than branches, there is almost no variation, and the boundary between branch VM instructions and other VM instructions is often clear. For this reason, the threshold value is set to a value that can divide the two groups obtained by plotting the obtained variance value on a number line, for example. The VM instruction determination unit 1223 determines whether the VM instruction is a conditional branch VM instruction, a call VM instruction, or a return VM instruction based on the branch VM instruction.

[Treatment of mutated parts]
Next, a description will be given of the processing of the mutation unit 1231. FIG.

The mutation unit 1231 refers to the list of VM instructions ((1) in FIG. 13). This list of VM instructions is collected by the VM instruction collection unit 1222. Then, one bytecode is extracted from the bytecode dictionary ((2) in FIG. 13). The mutation unit 1231 mutates the extracted bytecode in a predetermined manner, such as by adding, deleting, or changing a VM instruction ((3) in FIG. 13).

[Processing procedure of vulnerability detection device]
Next, a description will be given of the procedure of the analysis process performed by the vulnerability discovering device 10. Fig. 14 is a flowchart showing the procedure of the analysis process according to the embodiment.

First, the input unit 11 receives a test script and a script engine binary as input (step S1).

Then, the execution trace acquisition unit 1211 performs an execution trace acquisition process in which the test script is executed while monitoring the binary of the script engine to acquire branch traces and memory access traces (step S2).

The VM instruction boundary detection unit 1212 detects VM instructions and performs VM instruction boundary detection processing to detect VM instruction boundaries (step S3). The virtual program counter detection unit 1213 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131, and performs virtual program counter detection processing to discover the VPC (step S4).

The dispatcher detection unit 1214 performs dispatcher detection processing to extract each VM command portion from the script engine binary and detect the portion with high similarity between each VM command as a dispatcher (step S5).

The conditional branch flag detection unit 1215 performs a conditional branch detection process to extract and analyze the execution trace for the second test script stored in the execution trace DB 131 and discover the conditional branch flag (step S6).

The code cache detection unit 1216 performs a code cache detection process based on the execution trace and VPC to detect the area of the code location from which the memory allocation function was called as a code cache, and to detect the area in which writing is being done to the code location area as an update to the code cache (step S7).

The VM execution trace acquisition unit 1221 receives the test script and the script engine binary as input, and executes the test script while monitoring the execution of the script engine binary, thereby performing a VM execution trace acquisition process to acquire a VM execution trace (step S8).

The VM instruction collection unit 1222 performs a VM instruction collection process to acquire VM instructions from the VM execution trace (step S9). The VM instruction determination unit 1223 performs a VM instruction determination process to determine the instruction content of the collected VM instructions (step S10).

When the input unit 11 accepts the input of a seed script (step S11), the fuzzing execution unit 1232 executes a bytecode extraction process to execute the seed script while monitoring the code cache and extract bytecode from the code cache (step S12).

The mutation unit 1231 performs a mutation process to mutate the bytecode extracted by the fuzzing execution unit 1232 using a predetermined method such as adding, deleting, or changing a VM instruction (step S13). The fuzzing execution unit 1232 re-embeds the mutated code at the destination pointed to by the VPC in the code cache, and performs an execution process (step S14).

The vulnerability discovery unit 123 determines whether or not a problem such as a crash has occurred during the execution process (step S15). If a problem such as a crash has occurred (step S15: Yes), the vulnerability discovery unit 123 outputs the input value where the problem occurred (step S16). If a problem such as a crash has not occurred (step S15: No), the process returns to the mutation process of step S13 and continues fuzzing the VM.

[Processing procedure for execution trace acquisition processing]
Next, a flow of the execution trace acquisition process shown in Fig. 14 will be described below. Fig. 15 is a flowchart showing the processing procedure of the execution trace acquisition process shown in Fig. 14.

First, the execution trace acquisition unit 1211 receives a test script and a script engine binary as input (step S21). Then, the execution trace acquisition unit 1211 hooks the received script engine to acquire a branch trace (step S22). The execution trace acquisition unit 1211 also hooks the received script engine to acquire a memory access trace (step S23).

Then, the execution trace acquisition unit 1211 inputs the test script received in this state into the script engine and executes it (step S24), and stores the execution trace acquired thereby in the execution trace DB 131 (step S25).

The execution trace acquisition unit 1211 determines whether or not all of the input test scripts have been executed (step S26). If all of the input test scripts have been executed (step S26: Yes), the execution trace acquisition unit 1211 ends the process. On the other hand, if all of the input test scripts have not been executed (step S26: No), the execution trace acquisition unit 1211 returns to the execution of the test scripts in step S24 and continues the process.

[Procedure of VM instruction boundary detection process]
Next, a description will be given of the flow of the VM instruction boundary detection process shown in Fig. 14. Fig. 16 is a flowchart showing the processing procedure of the VM instruction boundary detection process shown in Fig. 14.

First, the VM instruction boundary detection unit 1212 extracts execution traces from the execution trace DB 131 (step S31). The VM instruction boundary detection unit 1212 clusters the execution traces using a predetermined method (step S32). Any method may be used for the clustering.

The VM instruction boundary detection unit 1212 detects clusters whose execution count is equal to or exceeds a threshold as VM instructions (step S33). Then, the VM instruction boundary detection unit 1212 determines the start and end points of a sequence of consecutive instructions that constitute a VM instruction as boundaries (step S34). The VM instruction boundary detection unit 1212 outputs the VM instruction boundary as a return value (step S35), and ends the VM instruction boundary detection process.

[Procedure for Virtual Program Counter Detection Processing]
Next, a description will be given of the flow of the virtual program counter detection process shown in Fig. 14. Fig. 17 is a flowchart showing the processing procedure of the virtual program counter detection process shown in Fig. 14.

First, the virtual program counter detection unit 1213 extracts one execution trace by the first test script from the execution trace DB 131 (step S41). Next, the virtual program counter detection unit 1213 focuses on memory access traces among the execution traces, and counts up the number of reads for each memory read destination (step S42).

The virtual program counter detection unit 1213 receives as input the first test script used to obtain the execution trace (step S43), and analyzes the first test script to obtain the number of repetitions and the number of repeated statements (step S44).

Then, the virtual program counter detection unit 1213 extracts from the execution trace DB 131 another execution trace by the first test script, which has a different number of repetitions and number of repeated statements (step S45). Then, the virtual program counter detection unit 1213 focuses on the memory access trace and counts the number of reads for each memory read destination (step S46). The virtual program counter detection unit 1213 also receives as input the first test script used to obtain the execution trace (step S47), analyzes the test script, and obtains the number of repetitions and the number of repeated statements (step S48).

Here, the virtual program counter detection unit 1213 narrows down the memory read destinations to only those whose read counts change in proportion to the number of repetitions or the increase or decrease in the number of repeated statements (step S49). Furthermore, the virtual program counter detection unit 1213 narrows down the memory read destinations narrowed down in step S49 to those whose read memory values always point to the start point of the VM instruction (step S50).

Then, the virtual program counter detection unit 1213 determines whether the memory read destinations have been narrowed down to only one (step S51). If the virtual program counter detection unit 1213 has not narrowed down the memory read destinations to only one (step S51: No), the process returns to step S45, where the virtual program counter detection unit 1213 retrieves the next execution trace and continues processing. On the other hand, if the virtual program counter detection unit 1213 has narrowed down the memory read destinations to only one (step S51: Yes), the virtual program counter detection unit 1213 stores the narrowed down memory read destination as a virtual program counter in the architecture information DB 132 (step S52), and ends processing.

[Processing procedure for dispatcher detection processing]
Next, a description will be given of the flow of the dispatcher detection process shown in Fig. 14. Fig. 18 is a flowchart showing the processing procedure of the dispatcher detection process shown in Fig. 14.

First, the dispatcher detection unit 1214 receives the script engine binary as input (step S61). The dispatcher detection unit 1214 receives the VM command boundary from the VM command boundary detection unit 1212 (step S62).

The dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary based on the boundaries of the VM instructions received from the VM instruction boundary detection unit 1212 (step S63). The dispatcher detection unit 1214 calculates the similarity between the codes of each VM instruction using a predetermined method (step S64). Any method for calculating the similarity may be used as long as it is a method that can calculate the similarity between codes.

The dispatcher detection unit 1214 extracts the part with high similarity among all VM commands based on the similarity calculated in step S64 (step S65). The dispatcher detection unit 1214 then determines whether it is the end part of the VM command (step S66).

If it is not the end of the VM command (step S66: No), the dispatcher detection unit 1214 returns to step S65 and continues processing. If it is the end of the VM command (step S66: Yes), the dispatcher detection unit 1214 outputs the extracted part as a dispatcher (step S67) and ends processing.

[Conditional Branch Flag Detection Processing Procedure]
Next, a description will be given of the flow of the conditional branch flag detection process shown in Fig. 14. Fig. 19 is a flowchart showing the processing procedure of the conditional branch flag detection process shown in Fig. 14.

First, the conditional branch flag detection unit 1215 extracts one execution trace by the second test script from the execution trace DB 131 (step S71). Then, the conditional branch flag detection unit 1215 focuses on the memory access trace and counts the number of reads for each memory read destination (step S72).

The conditional branch flag detection unit 1215 also receives as input the second test script used to obtain the execution trace (step S73), analyzes this second test script, and obtains the number of conditional branches and the True/False sequence pattern (step S74). The conditional branch flag detection unit 1215 then narrows down the memory read destinations to only those whose read count changes in proportion to the number of conditional branches (step S75). Furthermore, the conditional branch flag detection unit 1215 narrows down the memory read destinations to only those whose read memory value alternates between two values in accordance with the True/False sequence pattern (step S76).

The conditional branch flag detection unit 1215 determines whether the memory read destinations have been narrowed down to only one (step S77). If the conditional branch flag detection unit 1215 has not narrowed down the memory read destinations to only one (step S77: No), it returns to step S71, retrieves the next execution trace, and continues processing. On the other hand, if the conditional branch flag detection unit 1215 has narrowed down the memory read destinations to only one (step S77: Yes), it stores the narrowed down read destination in the architecture information DB 132 as a virtual program counter (step S78), and ends processing.

[Code cache detection process procedure]
Next, a description will be given of the flow of the code cache detection process shown in Fig. 14. Fig. 20 is a flowchart showing the processing procedure of the code cache detection process shown in Fig. 14.

When the code cache detection unit 1216 receives the execution trace, the VPC, and the VM execution trace as input (step S81), it acquires the memory area pointed to by the VPC from the VM execution trace (step S82). The VM execution trace is acquired by the VM execution trace acquisition unit 1221.

The code cache detection unit 1216 obtains from the execution trace the code location that called the memory allocation function that allocated the memory area obtained in step S82 (step S83). The code cache detection unit 1216 detects all areas that were allocated at the code location obtained in step S83 from the VM execution trace as code caches (step S84).

The code cache detection unit 1216 acquires the code location that is writing to the code cache from the execution trace (step S85). The code cache detection unit 1216 detects all areas in the VM execution trace that are written to at the code location acquired in step S85 as code cache updates (step S86). The code cache detection unit 1216 returns the detected code cache and its updated location (step S87), and ends the code cache detection process.

[Procedure of VM Execution Trace Acquisition Processing]
Next, a flow of the VM execution trace acquisition process shown in Fig. 14 will be described below. Fig. 21 is a flowchart showing the procedure of the VM execution trace acquisition process shown in Fig. 14.

First, the VM execution trace acquisition unit 1221 receives a test script and a script engine binary as input (step S91). Then, the VM execution trace acquisition unit 1221 hooks the received script engine to record the VPC and VM opcode (step S92).

The VM execution trace acquisition unit 1221 inputs the received test script in this state into the script engine for execution (step S93), and stores the VM execution trace acquired thereby in the VM execution trace DB 133 (step S94).

The VM execution trace acquisition unit 1221 determines whether or not all of the input test scripts have been executed (step S95). If all of the input test scripts have been executed (step S95: Yes), the VM execution trace acquisition unit 1221 ends the process. If all of the input test scripts have not been executed (step S95: No), the VM execution trace acquisition unit 1221 returns to the execution of the test scripts in step S93 and continues the process.

[Procedure of VM command collection process]
Next, a description will be given of the flow of the VM command collection process shown in Fig. 14. Fig. 22 is a flowchart showing the procedure of the VM command collection process shown in Fig. 14.

The VM command collection unit 1222 receives the VPC and dispatcher as input (step S101) and acquires various scripts from the Internet (step S102). The VM command collection unit 1222 executes the scripts while monitoring the VPC and dispatcher, and acquires a VM execution trace (step S103).

The VM instruction collection unit 1222 acquires VM instructions from the VM execution trace (step S104) and adds them to a list of VM instructions (step S105). If the VM instruction collection unit 1222 finds a VM instruction that is not in the list (step S106: No), it returns to step S102. If the VM instruction collection unit 1222 finds no VM instructions that are not in the list (step S106: Yes), it returns the list of VM instructions (step S107) and ends the VM instruction collection process.

[Processing Procedure of VM Command Determination Processing]
Next, a description will be given of the flow of the VM command determination process shown in Fig. 14. Fig. 23 is a flowchart showing the processing procedure of the VM command determination process shown in Fig. 14.

The VM instruction determination unit 1223 performs a branch VM instruction determination process to determine branch VM instructions from among the VM instructions collected by the VM instruction collection unit 1222 (step S111). The VM instruction determination unit 1223 determines that, among the branch VM instructions, a branch VM instruction that accesses a conditional branch flag is a conditional branch VM instruction (step S112).

The VM instruction determination unit 1223 scans the VM execution trace for any branch VM instruction, and if there is a branch instruction that branches immediately after the arbitrary branch VM instruction, performs a call VM instruction determination process to determine that the arbitrary branch VM instruction is a call VM instruction (step S113).

The VM instruction determination unit 1223 extracts the calling VM instruction from the VM execution trace, and performs a return VM instruction determination process to determine whether the extracted VM instruction is a return VM instruction (step S114).

The VM instruction determination unit 1223 determines other VM instructions using a predetermined method based on the difference in the VM execution traces obtained using multiple test scripts in which the VM instruction is called (step S115).

Then, the VM command determination unit 1223 adds the determined VM command to a VM command list (step S116). The VM command determination unit 1223 returns the list of VM commands (step S117) and ends the VM command determination process.

[Processing Procedure for Branch VM Instruction Determination Processing]
FIG. 24 is a flowchart of the branch VM instruction determination process shown in FIG.

The VM instruction determination unit 1223 extracts one VM execution trace from the VM execution trace DB 133 (step S121). The VM instruction determination unit 1223 links a pointer to the VM instruction with the VM instruction, and assigns a VM opcode to each as an identifier (step S122). Then, the VM instruction determination unit 1223 counts the amount of change in VPC before and after execution for each VM opcode (step S123).

The VM instruction determination unit 1223 determines whether all VM execution traces in the VM execution trace DB 133 have been processed (step S124). If all VM execution traces in the VM execution trace DB 133 have not been processed (step S124: No), the VM instruction determination unit 1223 returns to step S121 and retrieves and processes the next VM execution trace.

If all VM execution traces in the VM execution trace DB 133 have been processed (step S124: Yes), the VM instruction determination unit 1223 calculates the variance of the amount of change in VPC for each VM opcode (step S125). Then, the VM instruction determination unit 1223 receives a threshold value as an input (step S126). The VM instruction determination unit 1223 narrows down to only VM opcodes whose variance is greater than the threshold value (step S127), stores them as branch VM instructions in the architecture information DB 132 (step S128), and ends the process.

[Procedure for Conditional Branch VM Instruction Determination Processing]
FIG. 25 is a flowchart illustrating the procedure of the conditional branch VM instruction determination process illustrated in FIG.

The VM instruction determination unit 1223 extracts a list of opcodes of branch VM instructions from the architecture information DB 132 (step S131). The VM instruction determination unit 1223 extracts one VM execution trace from the VM execution trace DB 133 (step S132). The VM instruction determination unit 1223 extracts the corresponding execution trace from the execution trace DB 131 (step S133).

The VM instruction determination unit 1223 extracts one location where a branch VM instruction is being executed from the VM execution trace (step S134). The VM instruction determination unit 1223 extracts a memory access trace corresponding to the execution of the extracted branch VM instruction from the execution trace (step S135).

The VM instruction determination unit 1223 determines whether the branch VM instruction extracted in step S134 accesses a conditional branch flag based on the memory access trace (step S136).

If the conditional branch flag is being accessed (step S136: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction extracted in step S134 is a conditional branch VM instruction (step S137). The VM instruction determination unit 1223 stores the opcode of this conditional branch VM instruction in the architecture information DB 132 (step S138).

If the conditional branch flag has not been accessed (step S136: No), or after step S138 is completed, the VM instruction determination unit 1223 determines whether all locations where the branch VM instruction is being executed have been processed (step S139).

If not all locations where a branch VM instruction is being executed have been processed (step S139: No), the VM instruction determination unit 1223 extracts the next location where a branch VM instruction is being executed (step S140), returns to step S135, and processes the extracted branch VM instruction.

If all locations where the branch VM instruction is executed have been processed (step S139: Yes), the VM instruction determination unit 1223 determines whether all VM execution traces have been processed (step S141).

If not all VM execution traces have been processed (step S141: No), the VM instruction determination unit 1223 retrieves the next VM execution trace (step S142), returns to step S133, and performs processing using the retrieved VM execution trace. If all VM execution traces have been processed (step S141: Yes), the VM instruction determination unit 1223 ends the conditional branch VM instruction determination process.

[Processing procedure for calling VM command determination process]
FIG. 26 is a flowchart illustrating the procedure of the called VM instruction determination process illustrated in FIG.

The VM instruction determination unit 1223 extracts a list of opcodes of branch VM instructions from the architecture information DB 132 (step S151). The VM instruction determination unit 1223 extracts one VM execution trace from the VM execution trace DB 133 (step S152). The VM instruction determination unit 1223 extracts one location where a branch VM instruction is being executed from the VM execution trace (step S153).

The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the branch VM instruction retrieved in step S153 (step S154). Based on the results of the scan in step S154, the VM instruction determination unit 1223 determines whether there is a branch VM instruction that branches immediately after the branch VM instruction retrieved in step S153 (step S155).

If there is a branch VM instruction that branches immediately after the branch VM instruction retrieved in step S153 (step S155: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction retrieved in step S153 is a call VM instruction (step S156). The VM instruction determination unit 1223 stores the opcode of the call VM instruction in the architecture information DB 132 (step S157).

If there is no branch VM instruction that branches immediately after the branch VM instruction extracted in step S153 (step S155: No), or after the processing of step S157 is completed, the VM instruction determination unit 1223 determines whether or not all locations where the branch VM instruction is being executed have been processed (step S158).

If not all locations where a branch VM instruction is being executed have been processed (step S158: No), the VM instruction determination unit 1223 extracts the next location where a branch VM instruction is being executed (step S159), returns to step S154, and processes the extracted branch VM instruction.

If all locations where the branch VM instruction is being executed have been processed (step S158: Yes), the VM instruction determination unit 1223 determines whether all VM execution traces have been processed (step S160).

If not all VM execution traces have been processed (step S160: No), the VM instruction determination unit 1223 retrieves the next VM execution trace (step S161), returns to step S153, and performs processing using the retrieved VM execution trace. If all VM execution traces have been processed (step S160: Yes), the VM instruction determination unit 1223 ends the called VM instruction determination process.

[Processing procedure for return VM command determination process]
FIG. 27 is a flowchart illustrating the procedure of the return VM instruction determination process illustrated in FIG.

The VM instruction determination unit 1223 extracts a list of opcodes of branch VM instructions from the architecture information DB 132 (step S171). The VM instruction determination unit 1223 extracts one VM execution trace from the VM execution trace DB 133 (step S172). The VM instruction determination unit 1223 extracts one location where a called VM instruction is being executed from the VM execution trace (step S173).

The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the call VM instruction extracted in step S173 (step S174).

The VM instruction determination unit 1223 determines whether there is a branch VM instruction that branches immediately after the call VM instruction retrieved in step S173 (step S175).

If there is a branch VM instruction that branches immediately after the call VM instruction retrieved in step S173 (step S175: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction that branches immediately after the call VM instruction retrieved in step S173 is a return VM instruction (step S176). The VM instruction determination unit 1223 stores the opcode of the return VM instruction in the architecture information DB 132 (step S177).

If there is no branch VM instruction that branches immediately after the call VM instruction retrieved in step S173 (step S175: No), or after the processing of step S177 is completed, the VM instruction determination unit 1223 determines whether or not all locations where branch VM instructions are being executed have been processed (step S178).

If not all locations where a branch VM instruction is being executed have been processed (step S178: No), the VM instruction determination unit 1223 extracts the next location where a branch VM instruction is being executed (step S179), returns to step S174, and processes the extracted branch VM instruction.

If all locations where the branch VM instruction is being executed have been processed (step S178: Yes), the VM instruction determination unit 1223 determines whether all VM execution traces have been processed (step S180).

If not all VM execution traces have been processed (step S180: No), the VM command determination unit 1223 retrieves the next VM execution trace (step S181), returns to step S173, and performs processing using the retrieved VM execution trace. If all VM execution traces have been processed (step S180: Yes), the VM command determination unit 1223 ends the return VM command determination process.

[Bytecode extraction process procedure]
Next, a flow of the bytecode extraction process shown in Fig. 14 will be described below. Fig. 28 is a flowchart showing the processing procedure of the bytecode extraction process shown in Fig. 14.

The vulnerability discovery unit 123 accepts a seed script as input (step S191). The vulnerability discovery unit 123 accepts a code cache as input (step S192).

The fuzzing execution unit 1232 executes the seed script while monitoring the code cache (step S193). The vulnerability discovery unit 123 extracts the bytecode from the code cache (step S194) and stores the bytecode in the dictionary (step S195).

[Mutation processing procedure]
Next, a flow of the mutation process shown in Fig. 14 will be described below. Fig. 29 is a flowchart showing the processing procedure of the mutation process shown in Fig. 14.

The mutation unit 1231 receives as input the dictionary of bytecodes obtained in the bytecode extraction process (step S201). The mutation unit 1231 receives as input a list of VM instructions (step S202).

The mutation unit 1231 retrieves one bytecode from the bytecode dictionary (step S203), and mutates the retrieved bytecode using a predetermined method, such as adding, deleting, or changing a VM instruction (step S204). The mutation unit 1231 then adds the mutated bytecode to the bytecode dictionary (step S205).

If the mutation unit 1231 has not mutated all of the bytecodes to be mutated (step S206: No), the process returns to step S203. If the mutation unit 1231 has mutated all of the bytecodes to be mutated (step S206: Yes), the mutation unit 1231 returns the updated bytecode dictionary (step S207).

[Execution process procedure]
Next, a description will be given of the flow of the execution process shown in Fig. 14. Fig. 30 is a flowchart showing the processing procedure of the execution process shown in Fig. 14.

The fuzzing execution unit 1232 accepts a seed script as input (step S211). The fuzzing execution unit 1232 accepts a VPC and a code cache as input (step S212).

The fuzzing execution unit 1232 executes the seed script while monitoring the VPC and the code cache (step S213). The fuzzing execution unit 1232 stops the execution the moment the bytecode is executed (step S214). Then, the fuzzing execution unit 1232 retrieves the bytecode from the bytecode dictionary (step S215).

The fuzzing execution unit 1232 places the retrieved bytecode at the destination pointed to by the VPC in the code cache (step S216). The fuzzing execution unit 1232 then resumes execution (step S217).

[Effects of the embodiment]
In this way, the vulnerability discovery device 10 according to the embodiment analyzes the VM of the script engine, collects VM instructions, and determines the contents of the collected VM instructions to obtain information on the instruction set architecture, which is the system of instructions for the VM. The vulnerability discovery device 10 fuzzes the VM using mutated code based on the obtained architecture information. Therefore, the vulnerability discovery device 10 can realize fuzzing using bytecode as an input value even for script engines whose VM internal specifications are unknown.

Specifically, the vulnerability discovery device 10 executes the test script while monitoring the binary of the script engine, and obtains branch traces and memory access traces as execution traces. The vulnerability discovery device 10 analyzes the VM based on the execution trace, and obtains architecture information of the VM instruction boundary, VPC, dispatcher, conditional branch flags, and code cache. Furthermore, the vulnerability discovery device 10 executes the test script while monitoring the VPC and dispatcher, and obtains a VM execution trace. By analyzing the VM execution trace, the vulnerability discovery device 10 collects VM instructions, determines the contents of the VM instructions, and obtains information on the instruction set architecture.

In this way, even for a script engine whose VM's internal specifications are unknown, the vulnerability detection device 10 can obtain architecture information including information indicating where in the VM the bytecode generated by the script engine is stored, and information on the instruction set architecture of the bytecode that the VM can interpret.

Then, the vulnerability discovery device 10 detects the code cache based on the execution trace, the VPC, and the VM execution trace. The vulnerability discovery device 10 executes the seed script while monitoring the code cache to extract bytecode from the code cache, mutates the extracted bytecode, and re-embeds it into the code cache for execution. Therefore, based on the acquired architecture information, the vulnerability discovery device 10 is able to extract the current bytecode from the VM of the script engine, mutate it within the correct range as a bytecode instruction, and re-embed it into the VM.

In this way, the vulnerability discovery device 10 detects various architectural information by analyzing the execution trace and VM execution trace obtained, even for script engines whose VM internal specifications are unknown, making it possible to realize fuzzing using bytecode as input without requiring manual reverse engineering.

Furthermore, the vulnerability discovery device 10 can automatically perform fuzzing using bytecode as input for a variety of script engines as long as a test script is prepared, so fuzzing using bytecode can be performed without the need for individual design or execution.

This allows the vulnerability detection device 10 to perform fuzzing using bytecode as input values and discover potential vulnerabilities in a wide variety of script engine implementations.

In this way, the vulnerability discovery device 10 according to this embodiment can analyze a script engine whose VM's internal specifications are unknown, and obtain information about the storage destination of the bytecode and the instruction set architecture, thereby enabling fuzzing of script engines of a wide variety of scripting languages using the bytecode as an input value.

The vulnerability discovery device 10 is useful for discovering vulnerabilities in a wide variety of script engines, and is suitable for discovering vulnerabilities hidden in behavior that is difficult to extract when a script is used as the input value, by fuzzing using bytecode as the input value.

Therefore, by using the vulnerability discovery device 10 to perform fuzzing on various script engines using bytecode as input, it is possible to discover potential vulnerabilities and take measures such as fixing them.

[System configuration of the embodiment]
Each component of vulnerability discovery device 10 shown in Fig. 3 is a functional concept, and does not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of the functions of vulnerability discovery device 10 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

Furthermore, each process performed by the vulnerability discovery device 10 may be realized, in whole or in part, by a CPU and a program analyzed and executed by the CPU. Furthermore, each process performed by the vulnerability discovery device 10 may be realized as hardware using wired logic.

Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually. Alternatively, all or part of the processes described as being performed manually can be performed automatically using known methods. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters described above and illustrated in the drawings can be changed as appropriate unless otherwise specified.

[program]
31 is a diagram showing an example of a computer in which a program is executed to realize the vulnerability detecting device 10. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The 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.

The memory 1010 includes a ROM 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. 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 a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define each process of the vulnerability detection device 10 are implemented as program modules 1093 in which code executable by the computer 1000 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 of the vulnerability detection device 10 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

Furthermore, the setting data used in the processing of the above-mentioned embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary and executes it.

The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the 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 (such as a LAN (Local Area Network), WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

The above describes an embodiment of the invention made by the inventor, but the present invention is not limited to the descriptions and drawings that form part of the disclosure of the present invention according to this embodiment. In other words, all other embodiments, examples, and operational techniques made by those skilled in the art based on this embodiment are included in the scope of the present invention.

REFERENCE SIGNS LIST 10 Vulnerability detection device 11 Input unit 12 Control unit 13 Memory unit 14 Output unit 121 Virtual machine analysis unit 122 Instruction set architecture analysis unit 123 Vulnerability detection unit 131 Execution trace database (DB)
132 Architecture Information DB
133 VM execution trace DB
1211 Execution trace acquisition unit 1212 VM instruction boundary detection unit 1213 Virtual program counter detection unit 1214 Dispatcher detection unit 1215 Conditional branch flag detection unit 1216 Code cache detection unit 1221 VM execution trace acquisition unit 1222 VM instruction collection unit 1223 VM instruction determination unit 1231 Mutation unit 1232 Fuzzing execution unit

Claims (7)

1. a first analysis unit that analyzes a virtual machine of a script engine;
   a second analysis unit that analyzes an instruction set architecture, which is an instruction system of the virtual machine, collects virtual machine instructions, and determines instruction contents of the collected virtual machine instructions;
   an execution unit that fuzzes a virtual machine using mutated code based on architecture information acquired by the first analysis unit and the second analysis unit;
   A vulnerability detection device comprising:
2. The first analysis unit
   a first acquisition unit that acquires a plurality of execution traces by changing execution conditions;
   a first detector for clustering the execution trace to detect boundaries of each virtual machine instruction;
   a second detection unit that analyzes the execution traces using a differential execution analysis focusing on the number of memory reads and the boundaries of each virtual machine instruction detected by the first detection unit, and detects a virtual program counter that is a variable indicating the next instruction of the virtual machine to be executed;
   a third detection unit that analyzes the binary of the script engine based on the boundaries of each virtual machine instruction detected by the first detection unit and detects a dispatcher;
   a fourth detection unit that analyzes the plurality of execution traces using differential execution analysis focusing on the number of memory reads and detects a conditional branch flag that is an area that holds a flag indicating whether or not a branch is to be taken at the time of a conditional branch in an execution state;
   2. The vulnerability discovering device according to claim 1, further comprising:
3. The second analysis unit includes:
   a second acquisition unit that acquires a virtual machine execution trace, which is an execution trace executed in the virtual machine;
   a first collection unit that executes a test script while monitoring the virtual program counter and the dispatcher to obtain the virtual machine execution trace, and collects virtual machine instructions from the virtual machine execution trace;
   a first determination unit that determines instruction content of the virtual machine instruction collected by the first collection unit;
   3. The vulnerability discovering device according to claim 2, further comprising:
4. The first analysis unit
   a fifth detection unit that detects a code cache, which is a cache in which the virtual machine instructions to be executed are stored, from the virtual machine execution trace based on the execution trace, the virtual program counter, and the virtual machine execution trace;
   The vulnerability detection device according to claim 3, characterized in that the execution unit executes a seed script while monitoring the code cache, extracts a bytecode from the code cache, mutates the extracted bytecode, and embeds it back into the code cache for execution.
5. The first determination unit is
   determining a branch virtual machine instruction based on a variation in a change amount of a virtual program counter for each virtual machine opcode of the virtual machine execution trace;
   determining, among the branch virtual machine instructions, a branch virtual machine instruction that accesses the conditional branch flag as a conditional branch virtual machine instruction;
   scanning any of the branch virtual machine instructions in the virtual machine execution trace, and if there is a branch instruction that branches immediately after the any of the branch virtual machine instructions, determining that the any of the branch virtual machine instructions is a call virtual machine instruction;
   5. The vulnerability detection device according to claim 4, further comprising: extracting the call virtual machine instruction from the virtual machine execution trace; and, if there is a branch virtual machine instruction that branches immediately after the extracted call virtual machine instruction, determining that the branch virtual machine instruction that branches immediately after the extracted call virtual machine instruction is a return virtual machine instruction.
6. A vulnerability discovery method executed by a vulnerability discovery device, comprising:
   a first analysis step of analyzing a virtual machine of a script engine;
   a second analysis step of analyzing an instruction set architecture, which is an instruction system of the virtual machine, to collect virtual machine instructions and determine the instruction contents of the collected virtual machine instructions;
   an execution step of fuzzing a virtual machine using mutated code based on architecture information acquired in the first analysis step and the second analysis step;
   A vulnerability discovery method comprising:
7. a first analysis step of analyzing a virtual machine of a script engine;
   a second analysis step of analyzing an instruction set architecture, which is an instruction system of the virtual machine, to collect virtual machine instructions and determine instruction contents of the collected virtual machine instructions;
   an execution step of fuzzing a virtual machine using mutated code based on architecture information acquired in the first analysis step and the second analysis step;
   A vulnerability detection program that is executed on a computer.

Images