WO2024079803A1 - 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム - Google Patents

脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム Download PDF

Info

Publication number
WO2024079803A1
WO2024079803A1 PCT/JP2022/037943 JP2022037943W WO2024079803A1 WO 2024079803 A1 WO2024079803 A1 WO 2024079803A1 JP 2022037943 W JP2022037943 W JP 2022037943W WO 2024079803 A1 WO2024079803 A1 WO 2024079803A1
Authority
WO
WIPO (PCT)
Prior art keywords
unit
execution
virtual machine
instruction
branch
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2022/037943
Other languages
English (en)
French (fr)
Japanese (ja)
Inventor
利宣 碓井
裕平 川古谷
誠 岩村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2022/037943 priority Critical patent/WO2024079803A1/ja
Priority to JP2024550957A priority patent/JP7800717B2/ja
Publication of WO2024079803A1 publication Critical patent/WO2024079803A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a vulnerability detection device, a vulnerability detection method, and a vulnerability detection program.
  • Dynamic testing includes software testing. Software testing is carried out by actually providing input values to the target program, running it, and observing its behavior.
  • code coverage also called code coverage rate. This evaluates the percentage of the code in the target program that has been tested.
  • Some dynamic tests use code coverage as an indicator to evaluate the progress of testing and to plan tests.
  • Fuzzing is a technique that discovers vulnerabilities by repeatedly generating or mutating input values while running the target program and observing the state of the program to search for inputs that cause problems such as crashes.
  • grey box fuzzing Unlike black box fuzzing, grey box fuzzing also observes the internal state of the program, i.e., the execution path, when it is executed. Grey box fuzzing then calculates the code coverage for the execution paths that have already been tested, and prioritizes the use of input values as seeds for generation and mutation so that this value is large.
  • Grey-box fuzzing allows for efficient searching for vulnerabilities in a wider range of programs.
  • Non-Patent Document 1 gray box fuzzing is used to discover vulnerabilities in web applications created with PHP scripts.
  • the method described in Non-Patent Document 1 measures code coverage by constructing an abstract syntax tree for the source code and implementing static instrumentation.
  • Non-Patent Document 2 employs gray box fuzzing to discover vulnerabilities in web applications written in JavaScript.
  • an abstract syntax tree is constructed for the JavaScript source code and static instrumentation is performed to measure code coverage, just like Non-Patent Document 1.
  • Non-Patent Documents 1 and 2 have the problem that it is not possible to comprehensively know all possible branches, so the code coverage for the branches must be estimated from other information.
  • the techniques described in Non-Patent Documents 1 and 2 are static instrumentation, so there is an issue that there are cases where code coverage cannot be measured, such as dynamically evaluated scripts.
  • 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 gray box fuzzing based on accurate code coverage at runtime, without the need for manual individual analysis, design, and implementation, even for script engines that do not have support functions that can be used for code coverage measurement and whose internal specifications are unknown.
  • the vulnerability discovery 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, a calculation unit that constructs a first control flow graph showing an entire path based on the architecture information acquired by the first analysis unit and the second analysis unit, and a vulnerability discovery unit that mutates an input value based on the architecture information acquired by the first analysis unit and the second analysis unit, constructs a second control flow graph showing a path executed as a test by inputting the mutated input value to a script to be analyzed, calculates code coverage, which is the ratio of the path executed as the test to the entire path, and selects an input value based on the calculation result of the code coverage to perform fuzzing on the script to be analyzed executed on the virtual machine.
  • 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 the configuration of a vulnerability detecting device according to an embodiment.
  • FIG. 4 is a diagram showing an example of a test script used to detect 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. 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. 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 illustrating the process of the VM branch trace construction unit.
  • FIG. 14 is a diagram for explaining the control flow graph construction unit.
  • FIG. 15 is a flowchart showing a processing procedure of the vulnerability discovering process according to the embodiment.
  • FIG. 16 is a flowchart showing a processing procedure of the vulnerability discovering process according to the embodiment.
  • FIG. 17 is a flowchart of the execution trace acquisition process shown in FIG.
  • FIG. 18 is a flowchart illustrating a procedure of the VM instruction boundary detection process illustrated in FIG. FIG.
  • FIG. 19 is a flowchart illustrating the processing procedure of the virtual program counter detection processing shown in FIG.
  • FIG. 20 is a diagram for explaining the dispatcher detection process shown in FIG.
  • FIG. 21 is a flowchart showing the procedure of the conditional branch flag detection process shown in FIG.
  • FIG. 22 is a flowchart illustrating the procedure of the code cache detection process shown in FIG.
  • FIG. 23 is a flowchart illustrating the procedure of the VM execution trace acquisition process illustrated in FIG. 15 .
  • FIG. 24 is a flowchart illustrating the procedure of the VM command collection process illustrated in FIG.
  • FIG. 25 is a flowchart illustrating a processing procedure of the VM command determination process shown in FIG.
  • FIG. 26 is a flowchart showing the procedure of the multi-path execution process shown in FIG. FIG.
  • FIG. 27 is a flowchart illustrating the procedure of the VM branch trace construction process illustrated in FIG. 15 .
  • FIG. 28 is a flowchart of the control flow graph construction 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 flowchart illustrating the procedure of the code coverage calculation process shown in FIG.
  • FIG. 32 is a diagram showing an example of a computer that realizes a vulnerability discovering device by executing a program.
  • the vulnerability detection device of the embodiment is a vulnerability detection device that can realize gray box fuzzing based on accurate code coverage at runtime, even for script engines that do not have support functions that can be used for code coverage measurement and whose internal specifications are unknown, without requiring individual manual analysis, design, and implementation.
  • the vulnerability discovery device 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.
  • VPC virtual program counter
  • the vulnerability detection device executes the test script while monitoring the VPC and the dispatcher, and obtains a VM execution trace.
  • the vulnerability detection device collects VM instructions, determines the contents of the VM instructions, and obtains information on the instruction set architecture.
  • the vulnerability detection device constructs a first control flow graph that shows the entire path that was comprehensively executed in the multi-pass execution.
  • the vulnerability detection device then mutates the input values based on the acquired architecture information, and constructs a second control flow graph that shows the path that is executed by inputting the mutated input values into the script to be analyzed.
  • the vulnerability detection device calculates code coverage, selects input values based on the code coverage calculation results, and performs fuzzing on the script to be analyzed that is being executed on the VM. Code coverage is the ratio of paths executed as tests to the total paths.
  • the vulnerability detection device selectively chooses and mutates input values that will increase code coverage more based on the code coverage calculation results.
  • Figure 1 is a diagram for explaining an example of the configuration of a script engine.
  • script engine 1 has a bytecode compiler 2 and a VM 3.
  • bytecode compiler 2 has a syntax analysis unit 4 and a bytecode generation unit 5.
  • 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.
  • 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.
  • FIG 2 is a diagram showing pseudocode for a VM in the script engine.
  • the pseudocode first initializes the VPC (line 1).
  • the while loop is the interpreter loop (line 2).
  • 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).
  • the program corresponding to the VM opcode that was dispatched is executed (lines 6 and 8).
  • a branch VM command is a VM command that causes a branch to occur within a script
  • 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.
  • Fig. 3 is a diagram illustrating an example of the configuration of the vulnerability discovering device according to the embodiment.
  • the vulnerability discovery device 10 has an input unit 11, a control unit 12, a storage unit 13, and an output unit 14.
  • the vulnerability discovery device 10 accepts inputs of a test script, a script engine binary, and a script to be analyzed.
  • 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 scripts to be analyzed, and outputs them to the control unit 12.
  • the test script is a script that is input when dynamically analyzing the script engine to obtain an execution trace and a VM execution trace. Details of the test script are described later.
  • the script engine binary is an executable file that constitutes the script engine.
  • the script engine binary may be composed of multiple executable files.
  • the analysis target script is the script to be analyzed.
  • 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.
  • 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), a calculation unit 123, and a vulnerability discovery unit 124.
  • 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.
  • 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.
  • 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 portions with high similarity between each VM instruction as dispatchers.
  • the dispatcher is realized by referencing the pointer cache and jumping to the pointer of the next VM instruction handler.
  • 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 discovery device 10 detects dispatchers using a predetermined method by searching for code with high similarity that exists at the rear of such VM instruction handlers. To detect the portions 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).
  • 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.
  • 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, to which a VM opcode is virtually assigned as an identifier, and which records a pointer to the executed VM handler and a VPC.
  • a VM execution trace records a pointer to an executed VM instruction handler and a VPC.
  • a VM execution trace is composed of a VPC and a VM opcode for each executed VM instruction.
  • the VPC can be recorded 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 the pointer to the VM instruction and the 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 instructions collected by the VM instruction collection unit 1222.
  • the VM instruction determination unit 1223 detects branch VM instructions 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.
  • 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.
  • 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.
  • 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.
  • the VM instruction determination unit 1223 determines that the pair of instructions 1 and 2 are call and return VM instructions.
  • the calculation unit 123 constructs a first control flow graph that indicates the entire path comprehensively executed by multi-pass execution, based on the architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122.
  • the calculation unit 123 has a multi-pass execution unit 1231 (first execution unit), a VM branch trace construction unit 1232 (first construction unit), and a control flow graph construction unit 1233 (second construction unit).
  • the multi-path execution unit 1231 performs multi-path execution of the script to be analyzed while acquiring a VM execution trace based on the architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122.
  • the multi-path execution unit 1231 monitors the VPC and VM instructions, and executes the script to be analyzed while acquiring a VM execution trace.
  • the multi-path execution unit 1231 forks the execution state for each conditional branch instruction, leaving one as is and rewriting the conditional branch flag for the other, thereby performing multi-path execution by comprehensively executing multiple execution paths.
  • the VM branch trace construction unit 1232 detects branch VM instructions from the VM execution trace 41, which records the opcodes and VPCs of executed VM instructions, and constructs a VM branch trace that associates the VPCs before and after the execution of the detected branch VM instructions.
  • the VM branch trace construction unit 1232 detects the branch VM instruction that was actually executed from the VM execution trace acquired by the multi-path execution unit 1231, and constructs a first VM branch trace that associates the VPC before and after the execution of the detected branch VM instruction.
  • the control flow graph construction unit 1233 uses the VM branch trace to construct a control flow graph in which basic blocks are nodes and branches resulting from execution of branch VM instructions are edges.
  • the control flow graph construction unit 1233 constructs a first control flow graph based on the first VM branch trace.
  • the first control flow graph is constructed based on information that was actually executed in multi-path execution, and is therefore a complete control flow graph in which all paths are shown.
  • the control flow graph construction unit 1233 may also construct the graph by scanning the detected code cache and taking into account branch instructions that were not actually executed.
  • the vulnerability discovery unit 124 constructs a second control flow graph indicating paths executed as tests 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 124 calculates code coverage based on the first control flow graph and the second control flow graph. Code coverage is the ratio of paths executed as tests to all paths. Based on the calculation result of code coverage, the vulnerability discovery unit 124 selectively chooses and mutates input values that will increase code coverage, and performs fuzzing on the analysis target script executed on the VM.
  • the vulnerability detection unit 124 has a mutation unit 1241, a fuzzing execution unit 1242 (second execution unit), a VM branch trace construction unit 1243 (third construction unit), a control flow graph construction unit 1244 (fourth construction unit), and a code coverage calculation unit 1245 (first calculation unit).
  • the mutation unit 1241 accepts a seed input value and mutates the input value.
  • the input value is a value to be input to the script to be analyzed. If the code coverage increases above a predetermined value, the vulnerability discovery unit 124 selects the mutated input value and adds it to a dictionary of input values. The mutation unit 1241 mutates the input value based on the dictionary to which the mutated input value has been added.
  • the fuzzing execution unit 1242 executes the test target based on the architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122.
  • the fuzzing execution unit 1242 inputs the input value mutated by the mutation unit 1241 to the analysis target script and executes the test while acquiring a VM execution trace.
  • the fuzzing execution unit 1242 records the VM instructions executed during this execution and acquires the VM execution trace.
  • the VM branch trace construction unit 1243 detects the branch VM instruction that was actually executed as a test from the VM execution trace acquired by the fuzzing execution unit 1242, and constructs a second VM branch trace that associates the VPC before and after the execution of the detected branch VM instruction.
  • the control flow graph construction unit 1244 constructs a second control flow graph based on the second VM branch trace, in which basic blocks are nodes and branches resulting from execution of branch VM instructions are edges.
  • the code coverage calculation unit 1245 calculates code coverage based on the first control flow graph and the second control flow graph.
  • the code coverage calculation unit 1245 calculates, as code coverage, the ratio of the number of nodes and/or edges of the second control flow graph to the number of nodes and edges of the first control flow graph.
  • 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 and data used during execution of the processing program.
  • 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.
  • DB execution trace database
  • 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.
  • 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).
  • 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).
  • the number of conditional branches and the order pattern of branch success or failure are changed to generate differences.
  • 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.
  • 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.
  • Fig. 7 is a diagram showing an example of a VM execution trace.
  • 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.
  • 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.
  • 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.
  • VM instructions e.g., VM instruction handlers 1 to 3
  • 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).
  • 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).
  • 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 process 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).
  • 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).
  • the VM instruction determination unit 1223 determines a branch VM instruction by analyzing the acquired VM execution trace log.
  • the test script here may be any script that includes a branch VM instruction and that includes a branch control syntax.
  • the test script is prepared by collecting information from the Internet or obtaining information from official documents.
  • 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.
  • a VM instruction is a branch instruction
  • the advance of the VPC changes depending on the branch destination.
  • 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.
  • 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 value. In this way, the VM instruction determination unit 1223 associates the pointer with the VM instruction, and determines that a 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).
  • the threshold value is set to a value that can divide the two groups that result by plotting the obtained variance value on a number line, for example.
  • VM branch trace construction unit 1232 and 1243 are a description of the processing of the VM branch trace construction units 1232 and 1243.
  • Fig. 13 is a diagram for explaining the processing of the VM branch trace construction units.
  • the VM branch trace construction units 1232 and 1243 detect a branch VM instruction from the VM execution trace 41 that records the opcode of the executed VM instruction and the VPC ((1) in FIG. 13).
  • the branch VM instruction can be recognized by referring to the branch VM instruction list 42 detected by the VM instruction determination unit 1223.
  • the VM branch trace construction units 1232, 1243 construct a VM branch trace 43 that associates the VPCs before and after the execution of the detected branch VM instruction ((2) in FIG. 13).
  • the VM branch trace construction units 1232, 1243 detect the branch VM instruction "0x1f" from line R41 of the VM execution trace, and construct the VM branch trace shown in line R61 based on line R41 and line R42, which is the line that follows line R42. That is, the VM branch trace construction units 1232, 1243 associate the branch source VPC "0x555c7e48" of line R41 with the branch source VPC "0x555c82a0" of line R42.
  • the VM branch trace construction units 1232, 1243 detect the branch VM instruction "0x21" from line R51 of the M execution trace, they associate the VPC "0x555c832c" of line R51 with the VPC "0x555c7514" of line R52 based on this line R51 and the next line R52 (line R71).
  • Control flow graph construction part 14 is a diagram illustrating the processing of the control flow graph construction units 1233, 1244.
  • the control flow graph construction units 1233, 1244 use the VM branch trace 43 constructed in the VM branch trace construction process to construct a control flow graph in which basic blocks are nodes and each branch of the VM branch trace 43 is an edge ((1) in FIG. 14).
  • control flow graph construction units 1233 and 1244 designate the branch shown in row R61 of the VM branch trace 43 as edge E61, the basic block from which edge E61 branches as node N61, and the basic block to which edge E61 branches as node N62.
  • the branch shown in row R71 of VM branch trace 43 is edge E71, the subblock from which edge 71 branches is node N71, and the basic block to which edge E71 branches is node N72.
  • edge E71 the branch shown in row R71 of VM branch trace 43
  • the subblock from which edge 71 branches is node N71
  • the basic block to which edge E71 branches is node N72.
  • node N71 has a branch shown in edge E72, and the basic block to which this branch is directed is indicated by node N73.
  • the control flow graph construction units 1233 and 1244 construct a control flow graph that expresses the branching of basic blocks in a graph structure based on the VM branch trace.
  • Fig. 15 and Fig. 16 are flowcharts showing the procedure of vulnerability discovering processing according to the embodiment.
  • the input unit 11 receives a test script and a script engine binary as input (step S1).
  • 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).
  • the input unit 11 accepts input of a script to be analyzed (step S11).
  • the multi-pass execution unit 1231 executes the script to be analyzed in multiple passes while acquiring a VM execution trace, based on the architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122 (step S12).
  • the VM branch trace construction unit 1232 detects a branch VM instruction from the VM execution trace, and executes a VM branch trace construction process to construct a VM branch trace that associates VPCs before and after the execution of the detected branch VM instruction (step S13). In step S13, the VM branch trace construction unit 1232 constructs a first VM branch trace based on the multi-path execution by the multi-path execution unit 1231.
  • the control flow graph construction unit 1233 performs a control flow graph construction process to construct a control flow graph using the VM branch trace (step S14). In step S14, the control flow graph construction unit 1233 constructs a first control flow graph based on the first VM branch trace.
  • the vulnerability discovery unit 124 accepts the input of a seed input value (step S15) and creates a dictionary of input values (step S16).
  • the mutation unit 1241 performs a mutation process to mutate the input value to be input to the analysis target script (step S17).
  • the fuzzing execution unit 1242 inputs the input value mutated by the mutation unit 1241 to the analysis target script and performs an execution process to execute a test while acquiring a VM execution trace (step S18).
  • the vulnerability discovery unit 124 determines whether a problem such as a crash has occurred (step S19). If a problem such as a crash has occurred (step S19: Yes), the vulnerability discovery unit 124 outputs the input value that caused the problem (step S25).
  • step S19: No the VM branch trace construction unit 1243 performs a VM branch trace construction process to construct a second VM branch trace by performing the same process as in step S13 on the VM execution trace acquired by the fuzzing execution unit 1242 (step S20).
  • the control flow graph construction unit 1244 performs a control flow graph construction process to construct a second control flow graph by performing the same process as step S14 on the second VM branch trace (step S21).
  • the code coverage calculation unit 1245 performs a code coverage calculation process to calculate the code coverage based on the first control flow graph and the second control flow graph (step S22).
  • the vulnerability discovery unit 124 determines whether the code coverage calculated in step S22 has increased beyond a predetermined value (step S23).
  • the predetermined value may be set in advance or may be set dynamically according to the processing history of the vulnerability discovery device 10.
  • step S23: Yes If the code coverage has increased above the predetermined value (step S23: Yes), the vulnerability discovery unit 124 selects the mutated input value and adds it to the dictionary of input values (step S24), and returns to step S17. Then, the vulnerability discovery unit 124 causes the mutation unit 1241 to mutate the input value based on the dictionary to which the mutated input value has been added. If the code coverage has not increased above the predetermined value (step S23: No), the vulnerability discovery unit 124 returns to step S17.
  • FIG. 17 is a flowchart showing the processing procedure of the execution trace acquisition process shown in Fig. 15.
  • the execution trace acquisition unit 1211 receives a test script and a script engine binary as input (step S31). Then, the execution trace acquisition unit 1211 hooks the received script engine to acquire a branch trace (step S32). The execution trace acquisition unit 1211 also hooks the received script engine to acquire a memory access trace (step S33).
  • the execution trace acquisition unit 1211 inputs the test script received in this state into the script engine for execution (step S34), and stores the execution trace acquired thereby in the execution trace DB 131 (step S35).
  • the execution trace acquisition unit 1211 determines whether or not all of the input test scripts have been executed (step S36). If all of the input test scripts have been executed (step S36: 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 S36: No), the execution trace acquisition unit 1211 returns to the execution of the test scripts in step S34 and continues the process.
  • Fig. 18 is a flowchart showing the processing procedure of the VM instruction boundary detection process shown in Fig. 15.
  • the VM instruction boundary detection unit 1212 extracts execution traces from the execution trace DB 131 (step S41).
  • the VM instruction boundary detection unit 1212 clusters the execution traces using a predetermined method (step S42). Any method may be used for clustering.
  • the VM instruction boundary detection unit 1212 detects clusters whose execution count is equal to or exceeds a threshold as VM instructions (step S43). The VM instruction boundary detection unit 1212 then determines the start and end points of the continuous instruction sequence that constitutes the VM instruction as boundaries (step S44). The VM instruction boundary detection unit 1212 outputs the VM instruction boundary as a return value (step S45), and ends the VM instruction boundary detection process.
  • FIG. 19 is a flowchart showing the processing procedure of the virtual program counter detection process shown in Fig. 15.
  • the virtual program counter detection unit 1213 extracts one execution trace by the first test script from the execution trace DB 131 (step S51). 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 S52).
  • the virtual program counter detection unit 1213 receives as input the first test script used to obtain the execution trace (step S53), and analyzes the first test script to obtain the number of repetitions and the number of repeated statements (step S54).
  • 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 S55). 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 S56). The virtual program counter detection unit 1213 also receives as input the first test script used to obtain the execution trace (step S57), analyzes the test script, and obtains the number of repetitions and the number of repeated statements (step S58).
  • 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 S59). Furthermore, the virtual program counter detection unit 1213 narrows down the memory read destinations narrowed down in step S59 to those whose read memory values always point to the start point of the VM instruction (step S60).
  • the virtual program counter detection unit 1213 determines whether the memory read destinations have been narrowed down to only one (step S61). If the virtual program counter detection unit 1213 has not narrowed down the memory read destinations to only one (step S61: No), the process returns to step S55, 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 S61: 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 S62), and ends processing.
  • Fig. 20 is a flowchart showing the processing procedure of the dispatcher detection process shown in Fig. 15.
  • the dispatcher detection unit 1214 receives the script engine binary as input (step S71).
  • the dispatcher detection unit 1214 receives the boundaries of VM commands from the VM command boundary detection unit 1212 (step S72).
  • 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 S73).
  • the dispatcher detection unit 1214 calculates the similarity between the codes of each VM instruction using a predetermined method (step S74). Any method may be used to calculate the similarity, as long as it is capable of calculating 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 S74 (step S75). The dispatcher detection unit 1214 then determines whether it is the end part of the VM command (step S76).
  • step S76: No If it is not the end of the VM command (step S76: No), the dispatcher detection unit 1214 returns to step S75 and continues processing. If it is the end of the VM command (step S76: Yes), the dispatcher detection unit 1214 outputs the extracted part as a dispatcher (step S77) and ends processing.
  • Fig. 21 is a flowchart showing the processing procedure of the conditional branch flag detection process shown in Fig. 15.
  • conditional branch flag detection unit 1215 extracts one execution trace by the second test script from the execution trace DB 131 (step S81). 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 S82).
  • the conditional branch flag detection unit 1215 also receives as input the second test script used to obtain the execution trace (step S83), analyzes this second test script, and obtains the number of conditional branches and the True/False order pattern (step S84). 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 S85). 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 order pattern (step S86).
  • the conditional branch flag detection unit 1215 determines whether the memory read destinations have been narrowed down to only one (step S87). If the conditional branch flag detection unit 1215 has not narrowed down the memory read destinations to only one (step S87: No), it returns to step S81, 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 S87: Yes), it stores the narrowed down read destination in the architecture information DB 132 as a virtual program counter (step S88), and ends processing.
  • Fig. 22 is a flowchart showing the processing procedure of the code cache detection process shown in Fig. 15.
  • the code cache detection unit 1216 When the code cache detection unit 1216 receives an execution trace and a VM execution trace as input (step S91), it acquires the memory area pointed to by the VPC from the VM execution trace (step S92). 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 of the caller of the memory allocation function that allocated the memory area obtained in step S92 (step S93).
  • the code cache detection unit 1216 detects, from the VM execution trace, all areas allocated at the code location obtained in step S93 as code caches (step S94).
  • the code cache detection unit 1216 acquires the code location that is writing to the code cache from the execution trace (step S95). 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 S95 as code cache updates (step S96). The code cache detection unit 1216 returns the detected code cache and its updated location (step S97), and ends the code cache detection process.
  • Fig. 23 is a flowchart showing the procedure of the VM execution trace acquisition process shown in Fig. 15.
  • the VM execution trace acquisition unit 1221 receives a test script and a script engine binary as input (step S101). Then, the VM execution trace acquisition unit 1221 applies a hook to the received script engine to record the VPC and VM opcode (step S102).
  • the VM execution trace acquisition unit 1221 inputs the received test script in this state into the script engine for execution (step S103), and stores the VM execution trace acquired thereby in the VM execution trace DB 133 (step S104).
  • the VM execution trace acquisition unit 1221 determines whether or not all of the input test scripts have been executed (step S105). If all of the input test scripts have been executed (step S105: Yes), the VM execution trace acquisition unit 1221 ends the process. If all of the input test scripts have not been executed (step S105: No), the VM execution trace acquisition unit 1221 returns to the execution of the test scripts in step S103 and continues the process.
  • Fig. 24 is a flowchart showing the procedure of the VM command collection process shown in Fig. 15.
  • the VM command collection unit 1222 receives the VPC and dispatcher as input (step S111) and acquires various scripts from the Internet (step S112).
  • the VM command collection unit 1222 executes the scripts while monitoring the VPC and dispatcher, and acquires a VM execution trace (step S113).
  • the VM instruction collection unit 1222 acquires VM instructions from the VM execution trace (step S114) and adds them to a list of VM instructions (step S115). If the VM instruction collection unit 1222 finds a VM instruction that is not in the list (step S116: No), it returns to step S112. If the VM instruction collection unit 1222 finds no VM instructions that are not in the list (step S116: Yes), it returns the list of VM instructions (step S117) and ends the VM instruction collection process.
  • Fig. 25 is a flowchart showing the processing procedure of the VM command determination process shown in Fig. 15.
  • 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 associates 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.
  • 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.
  • Fig. 26 is a flowchart showing the processing procedure of the multi-pass execution process shown in Fig. 15.
  • the multi-path execution unit 1231 receives the script to be analyzed as input (step S131).
  • the multi-path execution unit 1231 receives the VPC, dispatcher, and conditional branch flag as input (step S132).
  • the multi-path execution unit 1231 monitors the VPC and VM instructions, and executes the script to be analyzed while acquiring the VM execution trace (step S133).
  • the multi-path execution unit 1231 forks the execution state for each conditional branch instruction, leaving one as is and rewriting the conditional branch flag for the other, thereby comprehensively executing multiple execution paths (step S134).
  • step S135 If all execution paths have not been exhaustively executed (step S135: No), the multi-path execution unit 1231 returns to step S133. If all execution paths have been exhaustively executed (step S135: Yes), the multi-path execution unit 1231 returns the VM execution trace (step S136) and ends the multi-path execution process.
  • Fig. 27 is a flowchart showing the processing procedure of the VM branch trace construction process shown in Fig. 15.
  • the VM branch trace construction units 1232 and 1243 receive the VM execution trace and the VM branch instruction list as input (step S141).
  • the VM branch trace construction units 1232 and 1243 extract the VM execution trace entries (step S142).
  • the VM branch trace construction units 1232 and 1243 determine whether the VM opcode is present in the VM branch instruction list (step S143).
  • step S143 If the VM opcode exists in the VM branch instruction list (step S143: Yes), the VM branch trace construction units 1232 and 1243 save the VPC as the branch source and the VPC of the next entry as the branch destination in the VM branch trace (step S144).
  • step S143 If the VM opcode does not exist in the VM branch instruction list (step S143: No), or after step S144 is completed, the VM branch trace construction units 1232 and 1243 determine whether all entries in the VM execution trace have been processed (step S145).
  • step S145 If not all entries in the VM execution trace have been processed (step S145: No), the VM branch trace construction units 1232 and 1243 extract the next entry in the VM execution trace (step S146). Then, the VM branch trace construction units 1232 and 1243 return to step S143 and determine whether the VM opcode for the next entry is present in the VM branch instruction list.
  • step S145 if all entries in the VM execution trace have been processed (step S145: Yes), the VM branch trace construction units 1232 and 1243 end the VM branch trace construction process.
  • Fig. 28 is a flowchart showing the processing procedure of the control flow graph construction process shown in Fig. 15.
  • control flow graph construction units 1233 and 1244 When the control flow graph construction units 1233 and 1244 receive a VM branch trace as input (step S151), they extract the VM branch trace entries (step S152).
  • the control flow graph construction units 1233 and 1244 add a basic block starting from the branch destination address as a node to the control flow graph (step S153).
  • the control flow graph construction units 1233 and 1244 add an edge from the branch source address to the branch destination address to the control flow graph (step S154).
  • the control flow graph construction units 1233 and 1244 determine whether all entries of the VM branch trace have been processed (step S155).
  • control flow graph construction units 1233 and 1244 If the control flow graph construction units 1233 and 1244 have not processed all the entries of the VM branch trace (step S155: No), they extract the next entry of the VM execution trace (step S156). Then, the control flow graph construction units 1233 and 1244 return to step S153 and add the basic block starting from the branch destination address of the next entry as a node to the control flow graph.
  • control flow graph construction units 1233 and 1244 output the constructed control flow graph (step S157).
  • Fig. 29 is a flowchart showing the processing procedure of the mutation process shown in Fig. 16.
  • the mutation unit 1241 accepts a dictionary of input values as input (step S161) and extracts one input value from the dictionary (step S162).
  • the mutation unit 1241 mutates the extracted input value using a predetermined method, such as randomly changing the value (step S163).
  • the mutation unit 1241 adds the mutated input value to the dictionary (step S164).
  • step S165 If the mutation unit 1241 has not mutated all of the input values to be mutated (step S165: No), it returns to step S163 and mutates the input values to be mutated. If the mutation unit 1241 has mutated all of the input values to be mutated (step S165: Yes), it returns the dictionary of updated input values (step S166) and ends the mutation process.
  • Fig. 30 is a flowchart showing the processing procedure of the execution process shown in Fig. 16.
  • the fuzzing execution unit 1242 receives the script to be analyzed as input (step S171).
  • the fuzzing execution unit 1242 receives the VPC, dispatcher, and conditional branch flag as input (step S172).
  • the fuzzing execution unit 1242 monitors the VM instructions and VPC being executed (step S173), and executes the script to be analyzed (step S174).
  • the fuzzing execution unit 1242 records the VM instructions executed during execution, and obtains a VM execution trace (step S175).
  • the fuzzing execution unit 1242 returns the VM execution trace (step S176), and ends the execution process.
  • Fig. 31 is a flowchart showing the processing procedure of the code coverage calculation process shown in Fig. 16.
  • the code coverage calculation unit 1245 counts the number of all nodes and edges in the first control flow graph (step S181).
  • the code coverage calculation unit 1245 counts the number of all nodes and edges in the second control flow graph (step S182).
  • the code coverage calculation unit 1245 calculates the ratio of the number of nodes and edges of the second control flow graph to the number of nodes and edges of the first control flow graph (step S183).
  • the code coverage calculation unit 1245 may calculate, as code coverage, both the number of nodes of the second control flow graph to the number of nodes of the first control flow graph and the ratio of the number of edges of the second control flow graph to the number of edges of the first control flow graph, or may calculate either one of them.
  • the code coverage calculation unit 1245 returns the calculated percentage as the code coverage (step S184) and ends the code coverage calculation process.
  • the vulnerability discovery device 10 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 VM instructions. Based on the obtained architecture information, the vulnerability discovery device 10 constructs a first control flow graph showing an entire path. Based on the obtained architecture information, the vulnerability discovery device 10 mutates an input value, and constructs a second control flow graph showing a path executed as a test by inputting the mutated input value to the analysis target script. The vulnerability discovery device 10 calculates code coverage, selects an input value based on the code coverage calculation result, and performs fuzzing on the analysis target script executed on the virtual machine.
  • the vulnerability discovery device 10 can analyze the VM of the script engine and obtain information on the instruction set architecture, which is the system of instructions for the VM, thereby achieving gray box fuzzing based on accurate code coverage at runtime without the need for individual manual analysis, design, and implementation.
  • 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 virtual machine based on the execution trace, and obtains architecture information of the VM instruction boundary, VPC, dispatcher, conditional branch flags, and code cache.
  • 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.
  • the vulnerability detection device 10 can detect 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.
  • the vulnerability discovery device 10 constructs a first control flow graph of the entire path comprehensively through multi-pass execution. Based on the acquired architecture information, the vulnerability discovery device 10 repeats the following steps to fuzz the script: mutating the input value, inputting the mutated input value into the script to be analyzed, executing the test, constructing a second control flow graph showing the path executed as the test, and calculating the code coverage.
  • the vulnerability detection device 10 can detect various architectural information by analyzing the execution trace and VM execution trace obtained, even for script engines whose VM internal specifications are unknown, and can perform gray-box fuzzing on running scripts without requiring manual reverse engineering.
  • the vulnerability detection device 10 selectively chooses and mutates input values that will increase the code coverage based on the results of the code coverage calculation, allowing for more appropriate execution of gray box fuzzing.
  • the vulnerability detection device 10 can automatically perform gray-box fuzzing on scripts for a variety of script engines as long as a test script is prepared, so that the fuzzing can be performed without the need for individual design or implementation.
  • the vulnerability detection device 10 can perform gray-box fuzzing on running scripts, even those written in various scripting languages, and discover potential vulnerabilities.
  • the vulnerability detection device 10 can perform gray-box fuzzing on scripts written in a wide variety of scripting languages by analyzing a script engine whose VM's internal specifications are unknown and acquiring information about the VM's architecture and instruction set architecture.
  • the vulnerability discovery device 10 is useful for discovering vulnerabilities in a wide variety of scripts, and is suitable for efficiently discovering vulnerabilities that lie in scripts by taking into account the code coverage executed by input values through gray box fuzzing.
  • the vulnerability discovery device 10 can be used to discover and fix potential vulnerabilities by performing gray box fuzzing on various scripts.
  • 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.
  • 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.
  • 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.
  • [program] 32 is a diagram showing an example of a computer in which a program is executed to realize the vulnerability discovering 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).
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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 Calculation unit 124 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 Multi-path execution unit 1232, 1243 VM branch trace construction unit 1233, 1244 Control flow graph construction unit 1241 Mutation unit 1242 Fuzzing execution unit 1245 Code coverage calculation unit

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
PCT/JP2022/037943 2022-10-11 2022-10-11 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム Ceased WO2024079803A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2022/037943 WO2024079803A1 (ja) 2022-10-11 2022-10-11 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム
JP2024550957A JP7800717B2 (ja) 2022-10-11 2022-10-11 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/037943 WO2024079803A1 (ja) 2022-10-11 2022-10-11 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム

Publications (1)

Publication Number Publication Date
WO2024079803A1 true WO2024079803A1 (ja) 2024-04-18

Family

ID=90668954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/037943 Ceased WO2024079803A1 (ja) 2022-10-11 2022-10-11 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム

Country Status (2)

Country Link
JP (1) JP7800717B2 (https=)
WO (1) WO2024079803A1 (https=)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022180702A1 (ja) * 2021-02-24 2022-09-01 日本電信電話株式会社 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022180702A1 (ja) * 2021-02-24 2022-09-01 日本電信電話株式会社 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HIRAMATSU, HAYATO; ISHIGURO, KENTA; KONO, KENJI: "A Fuzzing Method Specialized in the In-Kernel Interpreter", IPSJ COMPUTER SECURITY SYMPOSIUM (CSS 2021); OCTOBER 26-29, 2021, INFORMATION PROCESSING SOCIETY OF JAPAN, vol. 2021, 19 October 2021 (2021-10-19) - 29 October 2021 (2021-10-29), pages 395 - 402, XP009554373 *
USUI TOSHINOBU, FURUKAWA WAKI, ​​OTSUKI HAYATO, KAWAFURUYA YUHEI, IWAMURA SEI, MIYOSHI JUN, MATSUURA KANTA MATSUURA: "Automatically appending multi-path execution functionality to vanilla script engines", PROCEEDINGS OF COMPUTER SECURITY SYMPOSIUM 2019; OCTOBER 21-24, 2019, IPSJ, JAPAN, 14 October 2019 (2019-10-14) - 24 October 2019 (2019-10-24), Japan , pages 961 - 968, XP009539387 *
USUI, TOSHINORI; IKUSE, TOMONORI; KAWAKOYA, YUHEI; IWAMURA, MAKOTO; MATSUURA, KANTA: "Automatically Appending Execution Stall/Stop Prevention to Vanilla Script Engines", IPSJ COMPUTER SECURITY SYMPOSIUM (CSS 2021); OCTOBER 26-29, 2021, INFORMATION PROCESSING SOCIETY OF JAPAN (IPSJ), vol. 2021, 1 January 2021 (2021-01-01) - 29 October 2021 (2021-10-29), pages 794 - 801, XP009554372 *

Also Published As

Publication number Publication date
JPWO2024079803A1 (https=) 2024-04-18
JP7800717B2 (ja) 2026-01-16

Similar Documents

Publication Publication Date Title
JP7517585B2 (ja) 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法
Beaman et al. Fuzzing vulnerability discovery techniques: Survey, challenges and future directions
Shen et al. Automating performance bottleneck detection using search-based application profiling
US8683282B2 (en) Automatic identification of information useful for generation-based functional verification
CN106407809A (zh) 一种Linux平台恶意软件检测方法
CN110765459A (zh) 一种恶意脚本检测方法、装置和存储介质
CN113127342B (zh) 基于电网信息系统特征选择的缺陷预测方法及装置
CN115146282A (zh) 基于ast的源代码异常检测方法及其装置
US10754744B2 (en) Method of estimating program speed-up in highly parallel architectures using static analysis
CN114510722A (zh) 增量代码的静态检测方法及检测系统
Gunda Automatic Software Vulnerabilty Detection Using Code Metrics and Feature Extraction
Wang et al. Conftainter: Static taint analysis for configuration options
Gu et al. Deepprof: Performance analysis for deep learning applications via mining gpu execution patterns
JP7568131B2 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
Imtiaz et al. Predicting vulnerability for requirements
CN112199684A (zh) 基于跨语言代码关联的Java补丁存在性检测方法
JP7838662B2 (ja) 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム
Godboley et al. Ssg-afl: Vulnerability detection for reactive systems using static seed generator based afl
JP7800717B2 (ja) 脆弱性発見装置、脆弱性発見方法及び脆弱性発見プログラム
JP7800718B2 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
JP7568128B2 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
CN114706769B (zh) 基于日志的面向回归测试的黑盒测试用例排序方法
WO2024214263A1 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
Assiri et al. Software Vulnerability Fuzz Testing: A Mutation-Selection Optimization Systematic Review
Neubauer Kamino: Dynamic approach to semantic code clone detection

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22962023

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2024550957

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22962023

Country of ref document: EP

Kind code of ref document: A1