Security inspection device, security inspection method, and program

Abstract

A security inspection device (100, 100A, 200, 300) comprises: a switching unit (111) that switches between enabling and disabling of a vulnerability mitigation function (specific function; SSP and ASLR) issued by an OS (120) to a target program (140); a search unit (112) that, in a state in which the mitigation function for vulnerabilities of the target program (140) is enabled, employs fuzzing to search for input information with which an output differs each time the target program (140) is executed, despite the input information being the same; and a confirmation unit (113) that, when the input information found by the search unit (112) is input to the target program (140) in a state in which the mitigation function is disabled, confirms whether or not randomness remains such that the output differs each time the target program (140) is executed.

Description

Security Inspection Device, Security Inspection Method, and Program

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

[0002] When a bug, which is a defect in a program, becomes apparent during program execution, the program may cause unintended operations and terminate abnormally. Also, a malicious user may exploit this bug to cause the program to execute arbitrary operations. Conventionally, such bugs in programs are automatically detected by a test process, and the discovered bugs are corrected before the program is released.

[0003] In order to inspect unknown vulnerabilities in software, a security test called fuzzing or fuzz testing is used. The test method called fuzzing originally inputs data having values that should not be input to the software (for example, random input data or a test protocol obtained by intentionally modifying a normal protocol), and monitors the behavior of the software at that time to check for defects that may lead to vulnerabilities.

[0004] The background art includes Background 1 related to fuzzing technology and Background 2 related to mitigation measures against vulnerabilities. Although both are technologies for preventing attacks, it should be noted that their positions are different. Fuzzing technology is a technology for discovering vulnerabilities in advance. In contrast, mitigation technology is a technology for making it difficult for an attack to succeed in case a vulnerability is exploited. The background art will be described in order below.

[0005] <Fuzzing Technology (Background 1)> - Evolution of Fuzzing Technology In the operation of "naive fuzzing", completely random input is given to the program to be tested, and behaviors that can be clearly regarded as outside the specifications (for example, crashes) are detected. Although the operation is very simple, it is known that vulnerabilities can be found by fuzzing even in a program that has been sufficiently tested.

[0006] "Naive fuzzing" has evolved as follows. Figure 15 shows the probability of random input data being selected in "naive fuzzing." In "naive fuzzing" as shown in Figure 15, all random input data are treated equally and are not updated. Therefore, the probability of random input data being selected is constant.

[0007] Figure 16 shows the probability of random input data being selected in "Advanced Fuzzing." In "Advanced Fuzzing," the probability distribution of random input data is biased and updated through feedback. In the left graph of Figure 16, the vertical axis shows the probability of selection, and the horizontal axis shows the input data. The probability of selection for each input data is randomly distributed. In the example of "Advanced Fuzzing" shown here, random input data is generated to reflect knowledge about the target program and change the probability distribution of the random input data.

[0008] In the graph on the right in Figure 16, the vertical axis represents the probability of selection, and the horizontal axis represents the input data. In the example of "advanced fuzzing" shown here, in addition to the graph on the left in Figure 16B, the probability distribution is updated to reflect past inputs and the operation of the target program. For example, as shown by the dashed arrow aa, the probability of random input data being selected is reduced around explored areas. This makes the search more efficient.

[0009] • What fuzzing detects: Fuzzing primarily detects "vulnerabilities that cause crashes." However, there is a need for fuzzing technology to be able to detect vulnerabilities other than crashes. One such technology for detecting vulnerabilities that do not cause crashes is the technology described in Non-Patent Literature 1. The technology in Non-Patent Literature 1 attempts to detect vulnerabilities that do not cause crashes by detecting unauthorized memory access, double frees, etc., and artificially causing crashes.

[0010] However, the technology described in Non-Patent Document 1 is just one example, and how to detect "non-crashing type malfunctions" remains recognized as one of the important research challenges in fuzzing (see Non-Patent Document 2).

[0011] <Mitigation Measures for Vulnerabilities (Background 2)> As mentioned above, mitigation measures for vulnerabilities are techniques that make attacks difficult to succeed in case vulnerabilities remain in the program. The following three techniques are known: Stack Smashing Protection (SSP), No-eXecutable bit (NX bit), and Address Space Layout Randomization (ASLR). Stack Smashing Protection (SSP) and Address Space Layout Randomization (ASLR) are mitigation measures that use random numbers. The generated random numbers are confidential information, and the leakage of this information constitutes a new type of vulnerability that does not result in a crash. Below, SSP (Stack Smashing Protection), NX bit (No-eXecutable bit), and ASLR (Address Space Layout Randomization) will be explained.

[0012] Stack Smashing Protection (SSP) is a mitigation measure against stack buffer overflows. When SSP is enabled, a random number called a canary is placed between the stack frame and the local variable area of ​​the stack. Before returning to the return address from the subroutine, it is checked to make sure that the canary has not been corrupted. If the canary is unintentionally overwritten, it is determined that a stack overflow has been detected, and the program is terminated to ensure safety.

[0013] Figure 17 is a diagram illustrating SSP. The left side of Figure 17 shows the memory address space used by the program. The address space has a code area 11 and a stack area 12. The stack area 12 is stacked in the following order: a local variable area 21 containing buffers, a canary 22, a stack frame 23, and a return address 24. The canary 22 is a random number or a predefined custom string. The canary 22 is stacked between the stack frame 23 and the local variable area 21. In SSP, it is checked that the canary 22 has not been destroyed before a subroutine call returns to the address indicated by the return address 24.

[0014] The right side of Figure 17 shows the case where canary 22 has been destroyed and is now in area bb. In SSP, after a subroutine call, the CPU searches for the location where canary 22 appears before returning to the address indicated by return address 24. The CPU then detects an attack when it confirms that canary 22 is not found in the stack area.

[0015] 《No-eXecutable bit: NX bit》 The NX bit is a mechanism that allows setting an executable / impossible flag for a memory region.

[0016] Figure 18 is a diagram illustrating the NX bit. The left side of Figure 18 shows the memory address space used by the program. The address space has a code area 11 and a stack area 12. The NX bit of the code area 11 is set to 0, indicating that it is executable. The NX bit of the stack area 12 is set to 1, indicating that it is not executable. In this case, the CPU does not execute the stack area. The stack area 12 has a local variable area 21 containing buffers, a stack frame 23, and a return address 24.

[0017] The right side of Figure 18 shows an example where a malicious byte sequence 31 is injected into the stack area 12. The malicious byte sequence 31 has an address 32 which is an overwritten version of the return address 24, and an attack code 33 indicated by address 32. As shown on the left side of Figure 18, the NX bit of the stack area 12 is set to 1, making it unexecutable. In that case, as shown on the right side of Figure 18, even if the malicious byte sequence 31 is injected into the stack area 12 and the return address 24 is overwritten to address 32, the injected attack code 33 cannot be executed. That is, as shown by the arrow cc in the right side of Figure 18, even if an attempt is made to execute the attack code 33 at the time of return, the execution of the attack code 33 fails because the NX bit of the stack area 12 is set.

[0018] 《Address Space Layout Randomization (ASLR)》 On the attacker's side, a method of creating attack code by combining code within the executable area where existing programs are located (ROP: Return-Oriented Programming) is widespread as a way to circumvent the NX bit. As a mitigation measure against this, ASLR has been proposed, which randomizes the placement of programs for each execution.

[0019] Figure 19 is a diagram illustrating ASLR. The left side of Figure 19 shows the memory address space, which has an executable code area 11 and a non-executable stack area 12. However, in ROP, the attack code attempts to rewrite the return address of the stack area 12 and return to a specific location in the code area 11, as indicated by the arrow dd.

[0020] However, ASLR randomizes the program's placement with each execution, so the load position changes each time the program is run, as shown in the dashed block on the right side of Figure 19. Therefore, it's impossible to know where to return to, and thus the return operation fails. Consequently, ROP attacks fail.

[0021] [Serebryany2012] Address Sanitizer: A Fast Address Sanity Checker, [Searched on September 1, 2024], Internet <URL: 1728449546779_0>[Boehme2021]Fuzzing: Challenges and Reflections, [Searched on September 1, 2024], Internet <URL: https: / / ieeexplore.ieee.org / document / <9166552>return-oriented programming, [Searched on September 1, 2024], Internet <URL: https: / / ja.wikipedia.org / wiki / Return-oriented_programming>

[0022] The above-mentioned SSP, NX bit, and ASLR are enabled by default in major operating systems. That is, regarding the spread of buffer overflow attacks, countermeasures are taken by the NX bit. Then, ROP that bypasses the NX bit spreads. Regarding this, the countermeasure is by ASLR. However, methods to bypass SSP and ASLR are also spreading. As means to bypass SSP and ASLR, for example, it is to somehow夺取 the canary in SSP and the base address in ASLR and utilize the夺取 information.

[0023] The canary in SSP and the base address in ASLR are information that should be concealed, and the leakage of this information can become a vulnerability. If the above information is leaked and incorporated into the attack code, in many cases, it is considered to appear normal in operation without crashing.

[0024] It should be noted that the word "夺取" in the translation of seems to be an incorrect or unclear expression in the original text. It might need to be further clarified or corrected in the source material for a more accurate translation.Figure 20 shows source code 50 of a program that exemplifies information leakage, and the output 51 after execution of source code 50. The OS scheduler, which is not shown, executes the instructions in the thread of source code 50, in which case the printf() function and the scanf() function are called. The output 51 after execution of source code 50 shows the format string "%p%p%p%…p%p%p", which is the result of the instruction execution (call to print("echo >")), with 34 consecutive %p characters followed by the program memory address "0x555555557db0".

[0025] The program area address "0x555555557db0" is information that can be used to infer the base address in ASLR. If this information is leaked and attack code is incorporated, an attack that bypasses ASLR becomes possible. Moreover, it is a type of attack that does not cause a crash. The canary address in SSP and the base address in ASLR are information that should be kept secret, and their leakage can become a vulnerability. In Figure 20, the leaked address "0x555555557db0" can be a starting point for an attacker to perform ROP.

[0026] As mentioned above regarding the targets of fuzzing detection, fuzzing often determines vulnerabilities based on whether or not a crash occurs. On the other hand, it is difficult to detect the leakage of confidential information (for example, random numbers used by SSP and ASLR) in cases where no crash occurs (cases where the operation appears normal). However, malicious attackers' attack methods are becoming more diverse, and there is a demand to resolve even non-crash type bugs in advance, such as before service release. There is a demand to discover vulnerabilities that could lead to the theft of non-crash type random numbers during the verification phase.

[0027] In light of this background, the present invention aims to provide a security inspection device, a security inspection method, and a program that can detect operations that may leak confidential information (random numbers) in a way that does not cause the fuzzing to crash.

[0028] In light of this background, the present invention was made, and its objective is to provide a security inspection device, a security inspection method, and a program that can detect the possibility of leakage of confidential information (random numbers) used in mitigation measures for vulnerabilities in fuzzing, even in a non-crashing type.

[0029] To solve the aforementioned problems, the present invention provides a security inspection device comprising: a switching unit that switches between enabling and disabling a vulnerability mitigation function issued by the OS to a target program; a search unit that, with the vulnerability mitigation function for the target program enabled, searches for input information that, despite being the same input information, produces different outputs each time the target program is executed by fuzzing; and a verification unit that, with the mitigation function disabled, checks whether any randomness remains such that the output differs each time the target program is executed when the input information searched by the search unit is input to the target program.

[0030] According to the present invention, it is possible to detect operations that may lead to random number leakage, which can result in malfunctions that do not cause crashes.

[0031] This is a configuration diagram showing a security inspection device according to the first embodiment of the present invention. This is a configuration diagram showing a modified example of the security inspection device according to the first embodiment of the present invention. This diagram illustrates the operation of the <search phase> of security inspection method 1 of the security inspection device according to the first embodiment of the present invention. This diagram illustrates the operation of the <confirmation phase> of security inspection method 1 of the security inspection device according to the first embodiment of the present invention. This diagram shows the control sequence of the <search phase> of the security inspection device according to the first embodiment of the present invention. This diagram shows the control sequence of the <confirmation phase> of the security inspection device according to the first embodiment of the present invention. This is a configuration diagram showing a security inspection device according to the second embodiment of the present invention. This diagram illustrates the security inspection method 2 of the security inspection device according to the second embodiment of the present invention. This diagram shows the control sequence of <Method A> of the security inspection device according to the second embodiment of the present invention. This diagram shows the control sequence of <Method B> of the security inspection device according to the second embodiment of the present invention. This is a configuration diagram showing a security inspection device according to the third embodiment of the present invention. This diagram illustrates the security inspection method 3 of the security inspection device according to the third embodiment of the present invention. This diagram shows the control sequence of the <confirmation phase> of the security inspection device according to the third embodiment of the present invention. This is a hardware configuration diagram showing an example of a computer that realizes the functions of the security inspection device according to the embodiment of the present invention. This diagram shows the probability of random input data being selected in "naive fuzzing". This diagram shows the probability of random input data being selected in "Advanced Fuzzing." This diagram explains SSP. This diagram explains NX bit. This diagram explains ASLR. This diagram shows the source code of a program that exemplifies information leakage, and the output after the source code is executed.

[0032] The following describes a security inspection device, etc., in an embodiment for carrying out the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. (First Embodiment) In the first embodiment, changes in the output of the target program are detected by switching the enable / disable status of SSP and ASLR. [Overall Configuration] Figure 1 is a configuration diagram showing a security inspection device 100 according to the first embodiment of the present invention. As shown in Figure 1, the security inspection device 100 includes a control device 110, an OS (Operating System) 120, a fuzzer 130, a target program 140, and an execution environment 150. The security inspection device 100 is configured by, for example, a server. When the security inspection device 100 is configured by a server, the control device 110 is composed of a CPU (Central Processing Unit) or the like on hardware. In addition to a CPU, it can also be a processor such as a GPU (Graphic Processing Unit), FPGA (Field Programmable Gate Array), or ASIC (Application Specific Integrated Circuit). The security inspection device 100 supplies fuzzing data to the target program 140 to verify the operation behavior of the target program 140.

[0033] <Fuzzer 130> The fuzzer 130 is a tool that generates input for exploration (for example, random input data). The fuzzer 130 automatically generates fuzz and sends a large amount of malicious data to the target program 140 via the control device 110. Fuzz refers to providing the target program 140 with malicious data, as well as unexpected data or random data that would not normally occur during use. This makes it possible to intentionally cause exceptions in the target program. By causing exceptions in the target program and checking for defects, it becomes easier to detect potential bugs and vulnerabilities. The fuzzer 130 shown in Figure 1 is an existing tool connected to the control device 110.

[0034] <Target Program 140> Target Program 140 is the program to be subjected to the fuzz test, and is a so-called normal program. Target Program 140 is executed by a CPU (not shown) of the control device 110 under the execution environment 150.

[0035] <Execution Environment 150> The execution environment 150 is the environment in which the target program 140 is executed. In this embodiment, it is treated as an element that controls whether vulnerability mitigation technology is enabled or disabled.

[0036] <Control device 110> The control device 110 performs fuzzing tests to detect vulnerabilities in equipment and software by inputting a set of test data into the target program 140, which is the target of detection. In particular, the control device 110 detects changes in the output of the target program caused by switching the SSP and ASLR on and off.

[0037] The control device 110 manages the elements of the OS 120, the father 130, and the target program 140. The control device 110 includes a switching unit 111, a search unit 112, a confirmation unit 113, and a determination unit 114.

[0038] The switching unit 111 switches the vulnerability mitigation function issued by the OS 120 to the target program 140 between enabled and disabled. The mitigation function is, for example, SSP (Stack Smashing Protection) or ASLR (Address Space Layout Randomization).

[0039] The search unit 112, with the vulnerability mitigation function for the target program 140 enabled, searches for input information in which the output differs each time the target program 140 is executed due to fuzzing, even though the input information is the same.

[0040] The verification unit 113 checks whether, with the mitigation function disabled, when the input information searched by the search unit 112 is input to the target program 140, any randomness remains such that the output differs each time the target program 140 is executed. The verification unit 113 further checks whether there is a correlation between the output for the same fuzzing data input to the target program 140 and additional information regarding the execution environment in which the target program 140 operates.

[0041] The determination unit 114 determines that if the verification unit 113 confirms randomness in the output of the target program 140, there is a possibility that the random numbers used for security protection have been leaked.

[0042] In this embodiment, the security inspection device 100 detects that random numbers used for security protection have been leaked by detecting changes caused by switching between enabling and disabling SSP and ASLR. Each part performs the following operations. Specifically, the switching unit 111 of the control device 110 switches SSP and ASLR to enable in the <search phase> and switches SSP and ASLR to disable in the <confirmation phase>. In the <search phase>, the search unit 112 of the control device 110 inputs the fuzz generated by the fuzzer 130 to the target program 140 and causes the CPU to execute the target program 140 with the enabled / disabled SSP and ASLR mitigation technique enabled. The CPU executes the target program 140 with SSP and ASLR enabled. The search unit 112 detects input information in which the output differs each time the target program 140 is executed for the same input.

[0043] The verification unit 113 of the control device 110 checks whether, with SSP and ASLR disabled, when the input information searched by the search unit 112 is input to the target program 140, any randomness remains such that the output differs each time the target program 140 is executed.

[0044] Figure 2 is a configuration diagram showing a modified example of the security inspection device 100A in FIG. 1. The same reference numerals are given to the same components as in FIG. 1. The security inspection device 100A has a fuzzer 130 provided in the control device 110A. When the fuzzer 130 uses an original implementation instead of an existing tool, as shown in FIG. 2, the control device 110A itself may have a fuzz data generation function corresponding to the fuzzer 130.

[0045] Hereinafter, the security inspection method 1 of the security inspection device 100 configured as described above will be described.

[0046] <Inspection Method 1> FIGS. 3 and 4 are diagrams for explaining the security inspection method 1 of the security inspection device 100. FIG. 3 explains the operation of the <search phase> of the security inspection method 1, and FIG. 4 explains the operation of the <confirmation phase> of the security inspection method 1. The security inspection device may be any of the security inspection device 100 in FIG. 1 and the security inspection device 100A in FIG. 2. Further, the control devices 110, 110A (FIGS. 1, 2) control each element in an integrated manner behind the OS 120, the fuzzer 130, and the target program 140. Therefore, they are not shown in FIGS. 3 and 4.

[0047] <Search Phase> In the <search phase> of FIG. 3, at step S1, the OS 120 enables SSP and ASLR for the target program 140. Specifically, the switching unit 111 of the control device 110 shown in FIG. 1 switches to enable SSP and ASLR. Thereby, the OS 120 sets an executable / non-executable flag in the memory area for the target program 140 and randomizes the program placement for each execution.

[0048] At step S2 in FIG. 3, the fuzzer 130 searches for an input for the target program 140. Specifically, the search unit 112 of the control device 110 shown in FIG. 1 performs an input search for causing the target program 140 to execute by inputting the fuzzing data generated by the fuzzer 130 to the target program 140. For example, the format string of the output 51 after the execution of the source code 50 shown in FIG. 20, "% p% p% p%... p% p% p" (34 consecutive % p) is searched.

[0049] In step S3 of FIG. 3, the target program 140 transmits a random output to the fuzzer 130. Specifically, the confirmation unit 113 of the control device 110 shown in FIGS. 1 and 2 confirms the randomness of the output of the target program 140 in a state where SSP and ASLR are enabled. Here, the output of the target program 140 called by the hello() function may be "0xABCD" or "0x1234". That is, in the <exploration phase>, the target program 140 is executed multiple times in a state where SSP and ASLR are enabled. Then, the exploration unit 112 searches for input information such that the output of the target program 140 is different for each execution of the target program 140 even though the fuzzing input is the same. In the case of FIG. 3, even though the input is the same, the output of the target program 140 changes to "0xABCD" and "0x1234" for each execution.

[0050] <Confirmation Phase> In the <confirmation phase>, it is confirmed whether randomness remains even when SSP and ASLR are disabled for the change in the output of the target program 140 in the <exploration phase>. If randomness remains even when SSP and ASLR are disabled, it is determined that there is a possibility that information is leaked. Hereinafter, it will be described with reference to FIG. 4.

[0051] In the <confirmation phase> of FIG. 4, in step S4, the OS 120 disables SSP and ASLR for the target program 140 (reference sign a). Specifically, the switching unit 111 of the control device 110 shown in FIGS. 1 and 2 switches to disable SSP and ASLR. Thereby, the OS 120 does not set an executable / non-executable flag in the area on the memory for the target program 140, and fixes the program placement for each execution.

[0052] In step S5 of FIG. 4, the fuzzer 130 searches for the same input for the target program 140. Specifically, the exploration unit 112 of the control device 110 shown in FIG. 1 inputs the fuzzing data generated by the fuzzer 130 to the target program 140 and executes this target program 140.

[0053] In step S6 of Figure 4, the target program 140 detects and outputs a random output to the father 130. Specifically, the verification unit 113 of the control device 110 shown in Figures 1 and 2 verifies the randomness of the output of the target program 140 when SSP and ASLR are disabled.

[0054] Here, we assume that the output of the target program 140, called by the hello() function, is always "0x5555". In other words, in the <verification phase>, we check whether randomness remains in the output of the target program 140 even when SSP and ASLR are disabled. If the output of the target program 140 is not random and reproducibility is confirmed even when SSP and ASLR are disabled, then there is a correlation b between the disabling of SSP and ASLR and the reproducibility of the output. At this point, the determination unit 114 determines that there is a possibility that information has been leaked.

[0055] We will consider, as a comparative example, a method for simply detecting random output without switching between enabling and disabling SSP and ASLR. In this comparative example, if the target program 140 itself is a program with randomness (for example, a fortune-telling program, or a thread containing a fortune-telling program), the output will be random. Therefore, the randomness of the changes in the output of the target program 140 alone cannot necessarily determine the possibility of leakage of information (random numbers) that should be kept confidential.

[0056] Therefore, in the first embodiment, changes in randomness are detected by switching between enabling and disabling SSP and ASLR. That is, in the <search phase>, SSP and ASLR are enabled, an input search is performed, and a random output is detected. Furthermore, if randomness remains even after disabling SSP and ASLR in the <verification phase>, it is determined that there is a correlation and that there is a possibility of leakage.

[0057] [Control Sequence] Figures 5 and 6 show the control sequence of the security inspection device. Figure 5 is the control sequence for the <search phase>, and Figure 6 is the control sequence for the <confirmation phase>. The security inspection device may be either the security inspection device 100 in Figure 1 or the security inspection device 100A in Figure 2.

[0058] <Exploration Phase> In the <Exploration Phase> control sequence in Figure 5, the control device 110 notifies the execution environment 150 to enable the mitigation technology (step S100). The execution environment 150 is the environment in which the target program 140 is executed, and in this embodiment, it is treated as the element that controls the enabling and disabling of the vulnerability mitigation technology. In the subsequent sequence, each process is repeatedly executed with the mitigation technology enabled.

[0059] The control device 110 instructs the fuzzer 130 to generate a fuzz input (step S101). The fuzzer 130 sends the generated fuzz input to the control device 110 (step S102), and the control device 110 records the fuzz input.

[0060] The control device 110 instructs the execution of the target program 140 (step S103) and provides a fuzz input to the target program 140 (step S104). The CPU executes the target program 140 in environment c with relaxation technology (step S105). The CPU executing the target program 140 sends the execution result as output to the control device 110 (step S106), and the control device 110 records the output. The output of the first trial is obtained through the sequence of steps S103 to S106 described above.

[0061] The same sequence as in the first trial described above is repeated until the nth trial (where n is any positive integer). That is, the control device 110 instructs the CPU to execute the nth trial of the target program 140 (step S107) and provides a fuzz input to the target program 140 (step S108). Here, the fuzz input in step S104 and the fuzz input in step S108 are the same. This is to search for an input that, despite being the same input, produces a different output each time the program is executed due to fuzzing. The CPU executes the nth trial of the target program 14 in environment c with relaxation technology enabled (step S109). The CPU executing the target program 140 sends the result of the nth trial as an output to the control device 110 (step S110), and the control device 110 records the output of the nth trial.

[0062] The control device 110 compares the outputs obtained from multiple executions to determine whether the output is random or not (step S111), terminates the <search phase>, and moves to the <confirmation phase> in Figure 6.

[0063] <Confirmation Phase> In the control sequence of the <Confirmation Phase> in Figure 6, the control device 110 instructs the execution environment 150 to disable the mitigation technology (step S112). In the subsequent sequence, each process is repeatedly executed with the mitigation technology disabled.

[0064] The control device 110 instructs the execution of the target program 140 (step S113) and provides a fuzz input to the target program 140 (step S114). The CPU executes the target program 140 in an environment d without relaxation technology (step S115). The CPU executing the target program 140 sends the execution result as output to the control device 110 (step S116), and the control device 110 records the output. The output of the first trial is obtained through the sequence of steps S112 to S116 described above.

[0065] The control device 110 instructs the target program 140 to execute the nth trial (step S117) and provides a fuzz input to the target program 140 (step S118). Here, the fuzz input in step S114 and the fuzz input in step S118 are the same. The CPU executes the target program 140 for the nth trial in an environment d without relaxation technology (step S119). The CPU executing the target program 140 sends the execution result of the nth trial as an output to the control device 110 (step S120), and the control device 110 records the output of the nth trial.

[0066] The control device 110 compares the outputs obtained from multiple executions to determine whether the outputs are random or not (step S121), and then terminates the <confirmation phase>.

[0067] (Second Embodiment) The second embodiment detects changes in randomness by removing random elements other than SSP and ASLR. Figure 7 is a configuration diagram showing a security inspection device 200 according to the second embodiment of the present invention. The same reference numerals are used for the same components as in Figure 1. As shown in Figure 7, the security inspection device 200 includes a control device 210, an OS 120, a father 130, a target program 140, and an execution environment 250. The security inspection device 200 is configured with a server, similar to the security inspection device 100 in Figure 1. Alternatively, the security inspection device 200 may be configured so that the control device 210 is equipped with a fuzz data generation function corresponding to the father 130, similar to the security inspection device 100A in Figure 2.

[0068] The control device 210 comprises a switching unit 111, a disabling unit 211, a search unit 112, and a verification unit 113. The disabling unit 211 disables elements that may cause randomness in the output of the target program 140. The disabling unit 211 disables all elements other than SSP and ASLR as factors that may cause randomness in the output. For example, the disabling unit 211 hooks the time function to fix the return value, and for persistent data, it resets the contents of the file and database each time it is executed. The verification unit 113 checks whether, when a predetermined function is enabled and the disabling unit 211 has disabled elements, the input information searched by the search unit 112 is input to the target program 140, there remains randomness such that the output differs each time the target program 140 is executed.

[0069] The execution environment 250, like the execution environment 150 in Figures 1 and 2, is the entity that implements vulnerability mitigation technology. Specifically, the execution environment 250 provides functions to the target program 140 in the form of functions or subroutines, which are generally implemented by the execution environment or OS 120, such as obtaining the time and accessing files. In the execution environment 250, the main role of the execution environment has changed from "controlling the enabling / disabling of mitigation technology" as in the execution environment 150 in Figures 1 and 2, to "providing functions such as obtaining the time 251 and accessing files 252" (i.e., functions generally considered to be the role of the OS).

[0070] The following describes the security inspection method for the security inspection device 200 configured as described above.

[0071] <Inspection Method 2> Figure 8 is a diagram illustrating inspection method 2 of the security inspection method for the security inspection device 200. The control device 210 (Figure 7) of the security inspection device 200 is not shown in Figure 8 because it controls each element in the background of the OS 120, father 130, and target program 140.

[0072] As shown in Figure 8, in step S11, the OS 120 enables SSP and ASLR for the target program 140. Specifically, the switching unit 111 of the control device 210 shown in Figure 7 switches SSP and ASLR on and off. In steps S11 and S12, the OS 120 removes random elements other than SSP and ASLR. That is, it disables all elements other than SSP and ASLR that could cause randomness in the output. Specifically, the disabling unit 211 of the control device 210 shown in Figure 7 hooks the time function and fixes its return value as indicated by the stop mark e in order to disable randomness regarding time (step S12). And / or, the disabling unit 211 resets the contents of the file and database after each execution as indicated by the stop mark f in order to disable randomness regarding time-persistent data (step S13).

[0073] In step S14 of Figure 8, the father 130 searches for input to the target program 140. More specifically, the search unit 112 of the control device 210 shown in Figure 7 performs an input search to input the fuzzing data generated by the father 130 to the target program 140 and execute the target program 140.

[0074] In step S15 of Figure 8, the target program 140 detects and outputs a random output to the fuzzer 130. Specifically, the verification unit 113 of the control device 210 shown in Figure 7 verifies the randomness of the output of the target program 140 with SSP and ASLR enabled. Here, the output of the target program 140, called by the hello() function, changes to "0xABCD" and "0x1234" each time it is executed. In other words, even after removing random elements other than SSP and ASLR, the program searches for an input that produces a different output each time it is executed. That is, the target program 140 is executed multiple times and the outputs are compared. In the case of Figure 8, even though the input is the same due to fuzzing, the output of the target program 140 changes to "0xABCD" and "0x1234" each time it is executed.

[0075] In the second embodiment, changes in randomness are detected by removing random elements other than SSP and ASLR. That is, if randomness remains even after removing random elements other than SSP and ASLR, it is determined that there is a correlation and that there is a possibility of information leakage. The above describes <Inspection Method 2>, which searches for inputs with randomness in the output after disabling the relevant parameters.

[0076] The following describes in detail how to achieve "elimination of random elements." <Inspection Method 2> consists of two types: <Method A>, which uses function hooks, and <Method B>, which resets the contents of files and databases by restoring the file contents. <Method A> will be explained below with reference to Figure 9, and <Method B> will be explained with reference to Figure 10.

[0077] Method A: Specific techniques for implementing function hooks include, for example, the following: Extended Berkeley Packet Filter (eBPF): "Cloud Native Glossary" (cncf.io), Breakpoints: "Implementing Linux Hardware Breakpoints" (ninjastars-net.com). Method A uses methods generally known as function hooks. Method A detects function calls that cause random output, such as obtaining the time or accessing files, from the functions provided by the execution environment, and rewrites their behavior. For example, it rewrites the return value of the time so that it is always the same. It also rewrites the contents of the file to be always the same. This eliminates randomness.

[0078] Method B is a method for restoring (rewriting) the contents of a file. In particular, when the randomness of the output lies in the file access (more specifically, the contents of the accessed file), the randomness is eliminated by restoring the contents of the accessed file each time it is executed. Since Method A and Method B are independent methods, it is possible to use either one or both in combination.

[0079] Figure 9 shows the control sequence for Method A of the security inspection device 200. In the control sequence for Method A in Figure 9, the control device 210 enables mitigation technology for the execution environment 250 and sets function hooks (step S200). The execution environment 250 provides functions realized by the execution environment, such as time acquisition and file access, to the target program in the form of functions and subroutines. The subsequent sequence is executed repeatedly with mitigation technology enabled and function hooks set.

[0080] The control device 210 instructs the fuzzer 130 to generate a fuzz input (step S201). The fuzzer 130 sends the generated fuzz input to the control device 210 (step S202), and the control device 210 records the fuzz input.

[0081] The control device 210 instructs the target program 140 to execute (step S203) and provides a fuzz input to the target program 140 (step S204). The CPU enables the relaxation technique and executes the target program 140 in the function-hooked environment g (step S205). The CPU then requests a specific function from the execution environment 250 by calling a function.

[0082] The CPU, with the relaxation technique enabled and in a function-hooked environment, executes the target program 140 and performs processing according to the request (step S206). Here, for example, the CPU executing the target program 140 requests a specific function, such as obtaining the time, from the execution environment 250 (step S207). The execution environment 250 receives this request and notifies the control device 210 that a function hook has been called (step S208).

[0083] The control device 210 notifies the execution environment 250 to ensure that the behavior of the hooked function is always rewritten in the same way (step S209). The execution environment 250 returns the result sent from the control device 210 to the target program 140 (step S210). When the result of the processing in accordance with the request is returned, the CPU executing the target program 140 sends the processing result in accordance with the request as output to the control device 210 (step S211), and the control device 210 records the output. The output of the first trial is obtained in the sequence of steps S203 to S211 described above. The same sequence as the first trial is repeated up to the nth trial. That is, the control device 210 instructs the target program 140 to execute the nth trial (step S212), and gives the target program 140 a fuzz input. The same sequence as the first trial is repeated thereafter.

[0084] Figure 10 of the control sequence for Method B shows the control sequence for Method B of the security inspection device 200. In the control sequence for Method B in Figure 10, the control device 210 enables mitigation technology for the execution environment 250 (step S300). The execution environment 250 causes the control device 210 to record the contents of a specific file that may be overwritten (step S301).

[0085] The control device 210 instructs the fuzzer 130 to generate a fuzz input (step S302). The fuzzer 130 sends the generated fuzz input to the control device 210 (step S303), and the control device 210 records the fuzz input.

[0086] The control device 210 instructs the execution of the target program 140 (step S304) and provides a fuzz input to the target program 140 (step S305). The CPU executes the target program 140 in an environment h with relaxation technology enabled (step S306).

[0087] The CPU executing the target program 140 sends the result of the executed processing as output to the control device 210 (step S307), and the control device 210 records the output. The control device 210 instructs the execution environment 250 to restore the contents of the file (step S308).

[0088] The output of the first trial is obtained through the sequence of steps S304 to S308 described above. The same sequence as the first trial is repeated up to the nth trial. That is, the control device 210 instructs the CPU to execute the target program 140 for the nth trial (step S309) and provides a fuzz input to the target program 140 (step S310). The same sequence as the first trial is then repeated.

[0089] (Third Embodiment) The third embodiment checks whether the canary / base address is included in the output or whether there is no correlation. Figure 11 is a configuration diagram showing a security inspection device 300 according to the third embodiment of the present invention. The same reference numerals are used for the same components as in Figure 1. As shown in Figure 11, the security inspection device 300 includes a control device 320, an OS 120, a father 130, a target program 140, and an execution environment 350. The security inspection device 300 is configured with a server, similar to the security inspection device 100 in Figure 1. The security inspection device 200 may also be configured such that the control device 320 is equipped with a fuzz data generation function corresponding to the father 130, similar to the security inspection device 100A in Figure 2.

[0090] The control device 310 includes a switching unit 111, a relaxation technology information acquisition unit 311, a search unit 112, and a confirmation unit 113. The relaxation technology information acquisition unit 311 acquires relaxation technology information 351, which is additional information related to relaxation technology, from the execution environment 350.

[0091] The execution environment 350, like the execution environment 150 in Figures 1 and 2, is the entity that implements vulnerability mitigation technology. The execution environment 350 has mitigation technology information 351, which is additional information regarding mitigation technology, and stores it in a memory unit (not shown). When mitigation technology is effective, the execution environment 350 provides the mitigation technology information 351 to the control device 320. For example, in the case of SSP, the value of the canary included in the stack corresponds to the mitigation technology information 351, and in the case of ASLR, the base address of the location where the program is actually placed corresponds to the mitigation technology information 351.

[0092] The following describes the security inspection method for the security inspection device 300 configured as described above. Figure 12 is a diagram illustrating security inspection method 3 of the security inspection device 300. The control device 320 of the security inspection device 300 is not shown in Figure 12 because it controls each element in the background of the OS 120, father 130, and target program 140.

[0093] As shown in Figure 12, in step S31, the OS 120 enables SSP and ASLR for the target program 140. Specifically, the switching unit 111 of the control device 320 shown in Figure 11 switches SSP and ASLR to enable. In step S32, the OS 120 shares information with the father 130.

[0094] In step S33, the father 130 searches for input to the target program 140. Specifically, the search unit 112 of the control device 320 shown in Figure 11 inputs the fuzzing data generated by the father 130 to the target program 140, causing the CPU to execute the target program 140 and search for input information.

[0095] In step S34, the CPU executes the target program 140 and outputs it to the father 130. Specifically, the verification unit 113 of the control device 310 shown in Figure 11 checks the randomness of the output of the target program 140 in an environment where SSP and ASLR are enabled. Here, the output of the target program 140 called by the hello() function changes to "0xABCD" and "0x1234" each time it is executed. That is, in the third embodiment, the verification unit 113 of the control device 320 shown in Figure 11 determines whether there are any parts in the output for the same input that can be interpreted as numerical values. If there are parts in the output for the same input that can be interpreted as numerical values, the verification unit 113 of the control device 310 shown in Figure 11 checks whether it matches a different canary / base address each time it is executed, or whether there is no correlation when viewed as a numerical value. The verification unit 113 may determine that there is a correlation even if the canary / base address does not exactly match, but only partially matches, for example, if the string contains the last four digits.

[0096] However, the verification unit 113 may also check whether there is a correlation between the output information and the canary / base address. Based on this, the determination unit 114 determines that the random numbers used for security protection have been leaked.

[0097] The verification unit 113 of the control device 320 shown in Figure 11 determines that information has been leaked if the correlation is high. In the case of Figure 11, even though the input is the same due to fuzzing, the output of the target program 140 changes to "0xABCD" and "0x1234" with each execution.

[0098] <Search Phase> The security inspection device 300 of this embodiment has the same control sequence (Figure 5) as the security inspection devices 100 and 100A of the first embodiment in the <Search Phase>, so the explanation is omitted. If an input is found in the <Search Phase> that results in a random output, the following <Confirmation Phase> is executed.

[0099] <Verification Phase> Figure 13 shows the control sequence of the <Verification Phase> of the security inspection device 300. The control device 310 instructs the target program 140 to execute the program (step S301). The control device 310 requests additional information regarding the current execution from the execution environment 350 (step S302). The execution environment 350 sends the additional information to the control device 310, and the control device 310 acquires the additional information (step S303). Specifically, the mitigation technology information acquisition unit 311 of the control device 310 shown in Figure 11 requests additional information regarding the current execution from the execution environment 350, and the execution environment 350 responds to this request by providing mitigation technology information 351 as additional information. The mitigation technology information acquisition unit 311 acquires additional information related to mitigation technology (mitigation technology information 351) from the execution environment 350.

[0100] The control device 310 provides a fuzz input to the target program 140 (step S304). The CPU executes the target program 140 in environment i with relaxation technology (step S305). The CPU executing the target program 140 sends the execution result as output to the control device 310 (step S306), and the control device 310 records the output. The output of the first trial is obtained through the sequence of steps S301 to S306 described above.

[0101] The control device 110 instructs the target program 140 to execute the program for the nth trial (step S307). The control device 310 requests additional information regarding the current execution from the execution environment 350 (step S308). The execution environment 350 sends the additional information to the control device 310, and the control device 310 obtains the additional information (step S309). The control device 310 provides a fuzz input to the target program 140 (step S310). The CPU executing the target program 140 executes the program for the nth trial in environment m with relaxation technology enabled (step S311). The CPU executing the target program 140 sends the execution result of the nth trial as output to the control device 310 (step S312), and the control device 110 records the output of the nth trial.

[0102] The control device 310 determines whether or not there is a correlation between the additional information regarding the relaxation technique and the output (step S313), and then terminates the <confirmation phase>.

[0103] [Hardware Configuration] The security inspection devices 100, 100A, 200, and 300 according to the above embodiment are implemented by a computer 900 having a configuration such as that shown in Figure 14. Figure 14 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the security inspection devices 100, 100A, 200, and 300. The computer 900 has a CPU 901, a ROM 902, a RAM 903, an HDD 904, a communication interface 906, an input / output interface 905, and a media interface 907.

[0104] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls each part of the security inspection device 100 shown in Figure 1. The ROM 902 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0105] The CPU 901 controls input devices 910, such as a mouse or keyboard, and output devices 911, such as a display, via an input / output interface 905. The CPU 901 acquires data from the input devices 910 via the input / output interface 905 and outputs the generated data to the output devices 911. In addition to the CPU 901, a GPU (Graphics Processing Unit) or the like may also be used as a processor.

[0106] The HDD 904 stores programs executed by the CPU 901 and data used by those programs. The communication interface 906 receives data from other devices via the network 920, which is a communication network, and outputs it to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0107] The media interface 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads the program related to the desired processing from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded program. The recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.

[0108] For example, if computer 900 functions as a security inspection device 100 configured as one of the devices according to this embodiment, the CPU 901 of computer 900 realizes the functions of the security inspection device 100 by executing a program loaded on RAM 903. The HDD 904 stores the data in RAM 903. The CPU 901 reads and executes a program related to the desired processing from the recording medium 912. Alternatively, the CPU 901 may read a program related to the desired processing from another device via a communication network 920.

[0109] [Effects] As described above, the security inspection devices 100, 100A, 200, and 300 (Figures 1, 2, 3, 4, 7, 8, 11, and 12) include a switching unit 111 (Figures 1 and 2) that switches between enabling and disabling the vulnerability mitigation function (specific function; SSP and ASLR) issued by the OS 120 to the target program 140 (Figures 1 and 2, etc.), a search unit 112 (Figures 1 and 2, etc.) that searches for input information in which the output differs each time the target program 140 is executed by fuzzing, even though the input information is the same, when the vulnerability mitigation function for the target program 140 is enabled, and a verification unit 113 (Figures 1 and 2, etc.) that checks whether there remains randomness such that the output differs each time the target program 140 is executed when the input information searched by the search unit 112 is input to the target program 140 with the mitigation function disabled.

[0110] By doing this, it is possible to understand the input information when the output differs for the same input, and to determine if there is a possibility of so-called abnormal operation, or if the program returns a different output as part of its normal behavior.

[0111] In the security inspection device 100 (Figures 1, 2, 3, and 4), the mitigation function is either SSP (Stack Smashing Protection) or ASLR (Address Space Layout Randomization), and the device includes a determination unit 114 that determines if the verification unit 113 detects randomness in the output of the target program 140, and that there is a possibility that the random numbers used for security protection have been leaked.

[0112] The security inspection device 100, when the search unit 112 has SSP and ASLR enabled and the output is different for multiple identical inputs, has SSP and ASLR disabled and performs the same input multiple times, and the verification unit 113 determines that if the output from the target program 140 is the same, there is a possibility that the random numbers used for security protection have been leaked.

[0113] This makes it possible to detect the possibility that confidential information used in mitigation measures for vulnerabilities in fuzzing has been leaked.

[0114] In the security inspection device 200 (Figures 7 and 8), there is a disabling unit 211 (Figure 7) that disables elements that may cause randomness in the output of the target program 140 (Figure 7). The verification unit 113 (Figure 7) enables a predetermined function and, with the disabling unit 211 disabling elements, when the input information searched by the search unit 112 (Figure 7) is input to the target program 140, it checks whether there remains any randomness that causes the output to differ each time the target program 140 is executed.

[0115] In this way, if the target program 140 itself is a program that has randomness (for example, a fortune-telling program, or a thread containing a fortune-telling program), the output will be random. In the second embodiment, by turning off functions such as SSP and ASLR and checking the output with elements that can cause randomness disabled, if the output becomes the same, it can be detected as a correlation, i.e., a possibility of leakage of confidential information.

[0116] In the security inspection device 100 (Figures 1, 2, 3, and 4), the verification unit 113 further includes a determination unit 114 that checks whether there is a correlation between the output for inputting the same fuzzing data to the target program 140 and additional information regarding the execution environment in which the target program 140 operates, and if the verification unit 113 confirms that there is a correlation between the output and the additional information, it determines that the random numbers used for security protection have been leaked.

[0117] By doing so, it becomes possible to detect the possibility that confidential information used in mitigation measures for vulnerabilities in fuzzing has been leaked.

[0118] In the embodiments described above, SSP and ASLR were used as examples of relaxation functions that use random numbers, but these methods can also be applied to fuzzing techniques that incorporate relaxation functions other than SSP and ASLR.

[0119] Furthermore, among the processes described in each of the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be changed at will unless otherwise specified. Moreover, each component of each illustrated device is a functional concept and does not necessarily have to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0120] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software for the processor to interpret and execute programs that realize each function. Information such as programs, tables, and files that realize each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, an SD (Secure Digital) card, or an optical disc.

[0121] 100, 100A, 200, 300 Security Inspection Device 100, 210, 310 Control Device 111 Switching Unit 112 Search Unit 113 Verification Unit 114 Judgment Unit 120 OS 130 Father 140 Target Program 150 Execution Environment 211 Disable Unit 311 Mitigation Technology Information Acquisition Unit 351 Additional Information (Mitigation Technology Information)

Claims

1. A security inspection device comprising: a switching unit that switches between enabling and disabling a vulnerability mitigation function issued by the OS to a target program; a search unit that, with the vulnerability mitigation function for the target program enabled, searches for input information that, despite being the same input information, produces different outputs each time the target program is executed by fuzzing; and a verification unit that, with the mitigation function disabled, checks whether any randomness remains such that the output differs each time the target program is executed when the input information searched by the search unit is input to the target program.

2. The security inspection device according to claim 1, wherein the mitigation function is SSP (Stack Smashing Protection) or ASLR (Address Space Layout Randomization), and the device includes a determination unit that determines that if the verification unit confirms randomness in the output of the target program, there is a possibility that the random numbers used for security protection have been leaked.

3. The security inspection device according to claim 1, comprising a disabling unit that disables elements that may cause randomness in the output of the target program, wherein the verification unit enables a predetermined function and, with the disabling unit disabling the elements, when the input information searched by the search unit is input to the target program, it is characterized in that it checks whether or not randomness remains such that the output differs each time the target program is executed.

4. The security inspection device according to claim 1, further comprising a determination unit which checks whether there is a correlation between the output for inputting the same fuzzing data to the target program and additional information regarding the execution environment in which the target program operates, and determines that a random number used for security protection has been leaked if the check unit confirms that there is a correlation between the output and the additional information.

5. A security testing method characterized by the following steps: a switching unit switches on the vulnerability mitigation function issued by the OS to the target program; a search unit searches for input information in which the output differs each time the target program is executed by fuzzing, even though the input information is the same; the switching unit switches on the vulnerability mitigation function issued by the OS to the target program; and a confirmation unit confirms whether or not randomness remains such that the output differs each time the target program is executed when the input information searched by the search unit is input to the target program.

6. A program for causing a computer to function as a security inspection device according to any one of claims 1 to 4.

Images