Information processing device, information processing program, and information processing method

Abstract

To provide a solution capable of securing safety of an application program.SOLUTION: A software verification method includes a step of generating an intermediate representation from a source code, a step of verifying whether or not the intermediate representation satisfies a predetermined rule or convention related to vulnerability, and a step of outputting a verification result obtained by the verifying step.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a software verification method and a software development system. [Background technology]

[0002] Recent advances in information and communication technology (ICT) have been remarkable, and devices connected to networks such as the Internet are no longer limited to traditional information processing devices such as personal computers and smartphones, but are now expanding to include a wide variety of things. This technological trend is known as the "Internet of Things" (IoT), and a variety of technologies and services are being proposed and put into practical use. In the future, it is expected that billions of people and tens of billions or even trillions of devices on Earth will be connected simultaneously. To realize such a networked world, it is necessary to provide solutions that enable simpler, safer, and more free connections.

[0003] As devices used in IoT (also known as "edge devices") become more intelligent, various types of application programs can be executed on edge devices. However, due to resource constraints and other factors, it is not easy to improve the security of edge devices to the same level as that of servers and personal computers. For this reason, it is becoming increasingly important to verify the application programs that are incorporated into edge devices.

[0004] For example, Japanese Patent Application Laid-Open Publication No. 2014-174577 (Patent Document 1) discloses an improvement to a static analysis tool that verifies vulnerabilities in web applications at the source code level. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-174577 Summary of the Invention [Problem to be solved by the invention]

[0006] Application programs used in edge devices are often distributed not in the form of source code but as intermediate representations. The adoption of such an intermediate representation has the advantage of keeping the know-how contained in the source code confidential and reducing the amount of data.

[0007] As disclosed in the above-mentioned Patent Document 1, it is common to analyze source code to evaluate vulnerabilities, etc., but it is not easy to evaluate vulnerabilities, etc. in a format other than source code.

[0008] A typical objective of the present disclosure is to provide a solution that is suitable for edge devices and the like and can ensure the security of application programs. [Means for solving the problem]

[0009] A software verification method according to one aspect of the present disclosure includes the steps of generating an intermediate representation from source code, verifying whether the intermediate representation satisfies predetermined rules or regulations regarding vulnerabilities, and outputting the verification results obtained by the verification step.

[0010] The verification result may include information indicating the type of vulnerability detected. The verification result may include information indicating the location in the intermediate representation where the detected vulnerability exists.

[0011] The software verification method may further include generating debug information when generating the intermediate representation from the source code. The verification result may include information indicating a location in the source code where the detected vulnerability exists.

[0012] The software verification method may further include a step of permitting execution of the executable code generated from the intermediate representation on the condition that the intermediate representation satisfies predetermined rules or conventions.

[0013] A software development system according to another aspect of the present disclosure includes a software development device that supports the creation of source code and a verification server accessible from the software development device. The software development device includes means for generating an intermediate representation from the source code. The verification server includes means for verifying whether the intermediate representation satisfies predetermined rules or regulations regarding vulnerabilities, and means for outputting verification results obtained by the verifying means. [Effects of the Invention]

[0014] According to the present disclosure, a solution can be provided that can ensure the safety of application programs. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a diagram for explaining an example of a software verification method in a software development system according to an embodiment of the present invention; [Figure 2] FIG. 1 is a diagram showing an overview of a procedure for generating execution code from source code in a software development system according to the present embodiment. [Figure 3] FIG. 1 is a diagram showing an overview of a procedure for generating execution code from source code in a software development system according to the present embodiment. [Figure 4] FIG. 1 is a schematic diagram illustrating an example of a hardware configuration of a software development apparatus according to an embodiment of the present invention. [Figure 5]It is a schematic diagram showing a hardware configuration example of a verification server according to this embodiment. [Figure 6] It is a sequence chart showing an example of a procedure of a software verification method in a software development system 1 according to this embodiment. [Figure 7] It is a diagram showing an example of code for explaining a verification process of a static buffer overflow. [Figure 8] It is a diagram showing an example of code for explaining a verification process of a buffer overflow at runtime. [Figure 9] It is a diagram showing an example of code when the code shown in FIG. 8 is made to conform to rules or conventions regarding vulnerabilities in a software development system according to this embodiment. [Figure 10] It is a diagram showing an example of code for explaining a verification process of a format string bug. [Figure 11] It is a diagram showing an example of intermediate representation code for explaining a process of extracting an unused function. [Figure 12] It is a diagram showing an example of a verification result provided by a software development system 1 according to this embodiment.

Embodiments for Carrying Out the Invention

[0016] Embodiments according to the present disclosure will be described in detail while referring to the drawings. In the drawings, For the same or corresponding parts, the same reference numerals are given and the description thereof will not be repeated.

[0017] <A. Overview> First, an example of a software verification method in a software development system 1 according to this embodiment will be described. In this embodiment, the intermediate representation 20 itself generated from the source code 10 is verified. By verifying the intermediate representation 20 in this way, general-purpose verification becomes possible without depending on the language of the source code 10 and the target architecture, etc. Further, since the intermediate representation 20 generated by compiling the source code 10 is verified, know-how etc. included in the source code 10 can be concealed.

[0018] The verification of the intermediate representation 20 includes a process of verifying whether or not the application program contains vulnerabilities, as well as identifying the type of vulnerabilities that exist and the location of the vulnerabilities in the source code 10 .

[0019] Furthermore, on the condition that the intermediate representation 20 does not have any vulnerabilities (i.e., the verification result shows no problems), the generation of the corresponding execution code 30 or the execution of the generated execution code 30 may be permitted.

[0020] In this specification, "intermediate representation" refers to code generated by compiling source code written in any programming language (usually a high-level language) for any target architecture. The intermediate representation 20 may include machine language for any virtual machine. Note that the intermediate representation 20 does not necessarily have to be in binary format, and may be expressed in a format similar to a natural language, such as an assembly language.

[0021] Examples of intermediate representation20 code formats include the LLVM IR format and the LLVM BC format.

[0022] Typically, the intermediate representation 20 is generated independently of the platform and architecture on which the executable code 30 will be executed. A static compiler may be used to generate the intermediate representation 20 from the source code 10. The intermediate representation 20 may be compiled as executable code 30 targeted for a specific platform and architecture. The intermediate representation 20 has a reduced amount of data compared to the original source code, and the processes it describes can also be made more efficient.

[0023] 1 is a diagram illustrating an example of a software verification method in a software development system 1 according to this embodiment. As shown in FIGS. 1(A) and 1(B), in software development system 1, an intermediate representation 20 generated from source code 10 is verified by an arbitrary entity. In the example shown in FIGS. 1(A) and 1(B), an example is shown in which a verification server 200 verifies intermediate representation 20, but the present invention is not limited to this, and verification may be performed by an arbitrary entity.

[0024] Typically, the verification result 400 is fed back to the user who created the source code 10, and if necessary, the source code 10 is modified. As will be described later, the verification result 400 includes information indicating the type of vulnerability detected and information specifying the location of the source code 10, allowing the user to modify the source code 10 appropriately.

[0025] It should be noted that the generation of the execution code 30 or the execution of the execution code 30 may be permitted on the condition that the verification result 400 is free of any problems.

[0026] For example, FIG. 1A shows an example in which the condition for generating the execution code 30 is that the verification result 400 has no problems. In this example, if the verification result 400 has no problems, the verification server The intermediate representation 20 is authenticated by the intermediate representation 20. The execution code 30 is generated from the intermediate representation 20 with the authentication of the intermediate representation 20 as a generation condition. By adopting such a generation condition, the security of the generated execution code 30 can be improved.

[0027] 1B shows an example in which the execution condition for the executable code 30 generated from the intermediate representation 20 is that the verification result 400 is free of any problems. In this example, if the verification result 400 is free of any problems, the verification server 200 issues a certificate 40 that includes authentication for the intermediate representation 20. In parallel, the executable code 30 is generated from the intermediate representation 20. The execution of the generated executable code 30 may be conditional on the existence of the corresponding certificate 40. In this way, the existence of the certificate 40 for the intermediate representation 20 may be included in the execution conditions for the executable code 30. By adopting such an execution condition, it is possible to reduce the possibility that the executable code 30 will be executed in an unsecured state.

[0028] In this way, by verifying the intermediate representation 20 instead of the source code 10, vulnerabilities contained in the application program can be found more efficiently while keeping the know-how and the like contained in the source code 10 confidential. Furthermore, by verifying the intermediate representation 20, it is not necessary to prepare multiple verification logics according to the language of the source code 10, the target architecture, and the like, and efficient verification can be achieved.

[0029] When generating the intermediate representation 20, debug information 50 generated by compiling the source code 10 may be sent to the verification server 200 together with the intermediate representation 20. By referring to the intermediate representation 20, the location in the source code 10 corresponding to the detected vulnerability can be identified in more detail. The process of generating the verification result 400 using the debug information 50 will be described later.

[0030] Next, an example of a procedure for generating execution code 30 using software development system 1 according to the present embodiment will be described.

[0031] 2 and 3 are diagrams showing an outline of a procedure for generating execution code 30 from source code 10 in software development system 1 according to the present embodiment.

[0032] Referring to FIG. 2, software development system 1 includes one or more software development devices 100, and a verification server 200 accessible from software development device 100 via Internet 2 or the like.

[0033] The software development apparatus 100 supports the creation of an application program to be executed by a controller 300 included in an edge device 4. However, the technical scope of the present invention is not limited to the creation of an application program to be executed by an edge device 4, but is applicable to the creation of an application program to be executed by any computing device.

[0034] The software development device 100 is provided with an integrated development environment (IDE), and a user can create any application program on the integrated development environment.

[0035] The controller 300 included in the edge device 4 is an example of a computing device and includes a processor. The edge device 4 may be any device, but typically includes factory equipment, various household devices, social infrastructure equipment, mobile objects such as vehicles, and any portable devices. As will be described later, the controller 300 has a processor and executes the application program from the software development device 100. The program is now executable.

[0036] First, a user who is the creator creates source code using the software development device 100 ((1) Source Code Creation). The created source code is then compiled in the software development device 100 to generate an intermediate representation 20 ((2) Intermediate Representation Creation).

[0037] The intermediate representation 20 is verified before the execution code 30 is generated from the intermediate representation 20. In the example shown in Fig. 2, the generated intermediate representation 20 is sent to the verification server 200 ((3) Request to verify intermediate representation).

[0038] The verification server 200 verifies the intermediate representation 20 from the software development device 100 ((4) Verification of Intermediate Representation). Then, the verification server 200 transmits the verification result 400 obtained by verifying the intermediate representation 20 to the software development device 100. The software development device 100 receives the verification result 400 from the verification server 200 ((5) Receiving Verification Result).

[0039] If there is a problem with the verification result 400 from the verification server 200, the user refers to the verification result 400 and modifies the source code 10 ((6) Modifying Source Code). Then, the processes from (2) to (5) are repeated.

[0040] On the other hand, if there is no problem with the verification result 400 from the verification server 200, the user uses the software development device 100 to generate the executable code 30 from the intermediate representation 20 ((7) Generating Executable Code). The generated executable code 30 is transferred from the software development device 100 to the controller 300 of the edge device 4 ((8) Transferring Executable Code). Then, the controller 300 of the edge device 4 executes the transferred executable code 30 as needed ((9) Executing Executable Code).

[0041] Through a series of processes as shown in FIGS. 2 and 3, it is possible to guarantee the execution of a highly secure application program in the controller 300 of the edge device 4.

[0042] <B. Hardware Configuration Example> Next, a hardware configuration example of the main devices constituting the software development system 1 according to the present embodiment will be described.

[0043] (b1: Software Development Device 100) The software development device 100 is typically realized by a general-purpose computer.

[0044] Fig. 4 is a schematic diagram showing an example of a hardware configuration of software development device 100 according to this embodiment. Referring to Fig. 4, software development device 100 includes, as main components, processor 102, main memory 104, input unit 106, display 108, hard disk 110, and communication interface 122. These components are connected via internal bus 120.

[0045] The processor 102 is configured by, for example, a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). A plurality of processors 102 may be provided. , a processor 102 having multiple cores may be employed.

[0046] The main memory 104 is configured with a volatile storage device such as a DRAM (Dynamic Random Access Memory) or an SRAM (Static Random Access Memory). is a non-volatile memory that stores various programs and data executed by the processor 102. Instead of the hard disk 110, a solid state drive (SSD) or a flash drive A designated program code from the program stored on the hard disk 110 is loaded onto the main memory 104, and the processor 102 sequentially executes computer-readable instructions included in the program code loaded onto the main memory 104, thereby realizing various functions as will be described later.

[0047] Typically, the hard disk 110 stores source code 10 created by the user, a software development program 114 for realizing an integrated development environment, and executable code 30 generated from the source code 10. The software development program 114 generates the executable code 30 from the source code 10 created by the user via an intermediate representation 20, and includes a module that provides a development environment for application programs.

[0048] The input unit 106 accepts input operations from a user who operates the software development device 100. The input unit 106 may be, for example, a keyboard, a mouse, a touch panel arranged on a display device, or operation buttons arranged on the housing of the software development device 100.

[0049] The display 108 displays the processing results of the processor 102. The display 108 may be, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display.

[0050] The communication interface 122 is responsible for exchanging data with the validation server 200. The communication interface 122 may include, for example, an Ethernet port to allow communication over the Internet.

[0051] All or part of the software development device 100 may be implemented using a software development system such as an ASIC (Application Specific Integrated Circuit) incorporating a circuit corresponding to a computer-readable instruction. It may be implemented using hardwired circuitry, or alternatively, it may be implemented using circuitry corresponding to computer-readable instructions on a field-programmable gate array (FPGA). It may also be realized by appropriately combining the processor 102, main memory, ASIC, FPGA, etc.

[0052] Software development device 100 may further include a component for reading a software development program 114 containing computer-readable instructions from non-transitory media that stores the program. The media may be, for example, optical media such as a DVD (Digital Versatile Disc), semiconductor media such as a USB memory, or the like.

[0053] The software development program 114 may not only be installed in the software development device 100 via a medium, but may also be provided from a distribution server on a network.

[0054] (b2: Verification server 200) The verification server 200 is also typically implemented by a general-purpose computer.

[0055] 5 is a schematic diagram showing an example of a hardware configuration of the validation server 200 according to this embodiment. Referring to FIG. 5, the validation server 200 includes, as main components, one or more processors 202, a main memory 204, an input unit 206, a display 208, and , a hard disk 210, and a communication interface 222. These components are connected via an internal bus 220.

[0056] The processor 202 is configured by, for example, a CPU, a GPU, etc. Multiple processors 202 may be arranged, or a processor 202 having multiple cores may be employed.

[0057] The main memory 204 is configured with a volatile storage device such as a DRAM or an SRAM. The hard disk 210 is a non-volatile storage device that stores various programs and data executed by the processor 202. An SSD, flash memory, or the like may be used instead of the hard disk 210. Of the programs stored on the hard disk 210, designated program code is loaded onto the main memory 204, and the processor 202 sequentially executes computer-readable instructions included in the program code loaded onto the main memory 204, thereby realizing various functions as described below.

[0058] Typically, the hard disk 210 stores a verification engine 212 that receives an external request and executes verification processing of the intermediate representation 20. The verification engine 212 executes processing such as verifying whether or not there are vulnerabilities in the intermediate representation 20, and identifying information indicating the type of vulnerability that exists and the location of the source code 10.

[0059] The hard disk 210 may further store a certificate issuing engine 214 for issuing a certificate in accordance with the contents of the verification result 400 by the verification engine 212. If there is no problem with the verification result 400, the certificate issuing engine 214 issues a certificate 40 associated with the intermediate representation 20.

[0060] The input unit 206 accepts input operations from a user who operates the validation server 200. The display 208 displays the processing results of the processor 202 and the like.

[0061] The communication interface 222 is responsible for exchanging data with the software development device 100. The communication interface 222 may include, for example, an Ethernet port to enable communication over the Internet.

[0062] Note that all or part of the verification server 200 may be implemented using a hardwired circuit such as an ASIC in which a circuit corresponding to computer-readable instructions is incorporated. Alternatively or additionally, it may be implemented using a circuit corresponding to computer-readable instructions on an FPGA. Further, it may be implemented by appropriately combining the processor 202, the main memory, the ASIC, the FPGA, and the like.

[0063] Note that the programs necessary for execution may not only be installed in the verification server 200 via a medium, but may also be provided from a distribution server on a network.

[0064] <C. Procedure Example> Next, a specific procedure example of the software verification method in the software development system 1 according to this embodiment will be described.

[0065] FIG. 6 is a sequence chart showing a procedure example of the software verification method in the software development system 1 according to this embodiment. The processing executed by the software development apparatus 100 shown in FIG. 6 may typically be realized by the processor 102 of the software development apparatus 100 executing the software development program 114. Similarly, the processing executed by the verification server 200 may typically be realized by the processor 202 of the verification server 200 executing the necessary program.

[0066] Referring to FIG. 6, the user operates the software development apparatus 100 to create the source code 10 (step S100). After creating the source code 10, the user operates the software development apparatus 100 to compile the source code 10 and generate the intermediate representation 20 from the source code 10 (step S102).

[0067] Furthermore, the user operates the software development device 100 to request the verification server 200 to verify the generated intermediate representation 20 (step S104), and waits for a response from the verification server 200 (step S106). In addition to the intermediate representation 20, debug information 50 may be transmitted to the verification server 200.

[0068] The verification server 200 responds to the verification request from the software development device 100 and verifies the requested intermediate representation 20 (step S200). The verification server 200 transmits the verification result 400 generated by the verification to the software development device 100 (step S202). That is, the verification server 200 outputs the verification result 400 obtained by the verification.

[0069] If there is a problem with the verification result 400 (NO in step S108), the user operates the software development device 100 to correct the source code 10 (step S100). After correcting the source code 10, the processes below step S102 are executed again.

[0070] On the contrary, if there is no problem with the verification result 400 (YES in step S108), the user operates the software development device 100 to generate an executable code 30 from the target intermediate representation 20 (step S110). Finally, the user operates the software development device 100 to transfer the generated executable code 30 to the target controller 300 (step S112). Then, the process ends.

[0071] <D. Details of Verification Process> Next, the details of the verification process in the software development system 1 according to the present embodiment will be described.

[0072] In this embodiment, verification of the intermediate representation 20 may include processing to determine whether the intermediate representation 20 satisfies predetermined rules or regulations regarding vulnerabilities. The predetermined rules or regulations regarding vulnerabilities include conditions for the application program (intermediate representation 20 and corresponding executable code 30) to be safe. Typical examples of such safety conditions include the following:

[0073] (1) It does not contain memory operations whose safety cannot be confirmed (or dangerous memory operations) (or such memory operations are not compilable). (2) There is no undefined behavior in the code. (3) Error handling syntax is not missing (error handling syntax is included appropriately) (4) No unregulated error handling The memory operations whose safety cannot be confirmed (or dangerous memory operations) described in (1) above include memory access to the system area or secure area, and memory operations such as block erase and block write to the memory area.

[0074] The undefined behavior in (2) above includes procedures and functions whose processing is not defined in the code.

[0075] The error handling syntax in (3) above includes a description that governs the handling when an exception occurs. The above (4) uncontrolled error handling includes excessive error handling when an exception occurs.

[0076] Furthermore, the predetermined rules or regulations regarding vulnerabilities may include the absence of so-called backdoors in the application program (the intermediate representation 20 and the corresponding executable code 30). A backdoor refers to a function or connection port that allows a (usually malicious) third party to access the application program in a way that is not recognized by the user of the application program. In verifying the intermediate representation 20, it may be determined whether an external access route is included in the intermediate representation 20.

[0077] The above-mentioned verification may be realized by referring to rules that define predetermined rules or conventions regarding vulnerabilities, or by using so-called AI (Artificial Intelligence). The verification model for realizing verification may be successively updated using machine learning such as the above.

[0078] The following is an example of a verification process that embodies the above-described verification content.

[0079] (a) Static buffer overflow (b) Runtime buffer overflow (c) Integer overflow (d) Format string bug (e) Incomplete control statements (f) Access to uninitialized data (g) Extracting unused functions (h) Access to uninitialized data (i) Writing to a null pointer (j) Reading a null pointer (k) Double release of resources (l) OS command injection The verification process is not limited to the above, and any verification process may be implemented. Also, only some of the above verification processes may be implemented instead of all of them.

[0080] Next, some typical verification process details are described. (d1: Static buffer overflow) The process of verifying static buffer overflow will now be described.

[0081] 7A and 7B are diagrams showing code examples for explaining the static buffer overflow verification process. Fig. 7A shows an example of source code written in C language that causes a static buffer overflow.

[0082] In the source code in Figure 7(A), the first 10 elements of array a[] are defined, but the elements thereafter are undefined. As a result, different results will be output each time the code is executed. For the sake of convenience, the source code in Figure 7(A) is accompanied by a comment that reads, "^^^ A buffer overflow will occur."

[0083] For example, using gcc (9.2.0-Wall-Wextra option), which is an example of a compiler, When the source code in FIG. 7(A) is compiled, the compilation is completed without any warnings being output.

[0084] Figure 7(B) shows an example of an intermediate representation (for example, LLVM IR format) generated by compiling the source code in Figure 7(A). Note that in the intermediate representation shown in Figure 7(B), the code displayed in the parts marked "Omitted" is omitted.

[0085] The verification engine 212 according to this embodiment detects static buffer overflows by two processes: (1) searching for code that accesses a fixed-length array using an index, and (2) detecting code that accesses the array using a constant that exceeds the number of elements in the array as a vulnerability.

[0086] In the intermediate representation shown in Figure 7(B), the set of instructions starting with %3 on the fourth line specifies the getelementptr instruction. The getelementptr instruction is an instruction to obtain a pointer to an array element. The [10 x i64] following the inbounds instruction means that the target array contains 10 signed 64-bit integers. The "100" at the end is the 100th element of the target array. Indicates access to the eye element.

[0087] By analyzing such an intermediate representation, it is found that an attempt is made to access the 100th element of an array that contains only 10 elements. Through such analysis, the verification engine 212 detects a static buffer overflow as a vulnerability.

[0088] (d2: Runtime buffer overflow) The process of verifying runtime buffer overflow will be described.

[0089] FIG. 8 is a diagram illustrating an example of code for explaining the verification process for a runtime buffer overflow.

[0090] Generally, the index specified when accessing an array cannot be determined at compile time. For example, in the source code written in C language shown in Figure 8(A), a buffer overflow may occur depending on the value of the index (value of the variable index) at runtime. For the sake of convenience, the source code in Figure 8(A) states that "^^^ the buffer size is determined by the value of index." An overflow will occur."

[0091] The rules or regulations regarding vulnerabilities in software development system 1 according to this embodiment may require that index values ​​be checked in advance. That is, source code or intermediate representations that do not include processing for checking in advance the values ​​of indexes used to access arrays may be evaluated as having vulnerabilities.

[0092] The verification engine 212 according to this embodiment verifies whether or not there is a process for checking in advance the value of the index used to access the array.

[0093] More specifically, the verification engine 212 according to this embodiment detects runtime buffer overflows by two processes: (1) searching for code that accesses a buffer using an index, and (2) detecting, among the searched code, code that has not previously checked the index value as a vulnerability.

[0094] Figure 8(B) shows an example of an intermediate representation (for example, LLVM IR format) generated by compiling the source code in Figure 8(A). Note that in the intermediate representation shown in Figure 8(B), the code displayed in the parts marked "Omitted" is omitted.

[0095] In the intermediate representation shown in Figure 8(B), the set of instructions starting with %6 on the sixth line specifies the getelementptr instruction. The "i64 %5" at the end of the line indicates that it is not a specific number. There is an index access using a variable (the variable index in the source code). You can find that there is.

[0096] Here, without checking "%5" corresponding to the variable index in the source code, The use of the index to access it is the cause of the runtime buffer overflow.

[0097] FIG. 9 is a diagram showing an example of code when the code shown in FIG. 8 is made to comply with rules or regulations regarding vulnerabilities in software development system 1 according to the present embodiment.

[0098] In the source code written in C language shown in Figure 9(A), the value of the variable index is calculated using an if expression. Error handling is performed by checking (see lines 3 to 6). Source code including such error handling processing may be considered to be code that complies with the rules or regulations regarding vulnerabilities in the software development system 1.

[0099] Figure 9(B) shows an example of an intermediate representation (for example, LLVM IR format) generated by compiling the source code in Figure 9(A). Note that in the intermediate representation shown in Figure 9(B), the code displayed in the parts marked "Omitted" is omitted.

[0100] In the intermediate representation shown in Figure 9(B), the value of "%5" is checked, and only if the check result is OK, the array is accessed with "BoundsCheckOK" (6 ~Line 10).

[0101] When code that accesses a buffer by index exists, the verification engine 212 according to this embodiment evaluates that the code complies with the rules or regulations regarding vulnerabilities and that there is no vulnerability only if there is a process that checks the value of the index used for the access in advance.On the other hand, if there is no process that checks the value of the index used for accessing the buffer in advance, the verification engine 212 detects a runtime buffer overflow as a vulnerability.

[0102] By analyzing such intermediate representation, the validation engine 212 detects runtime buffer overflows as vulnerabilities.

[0103] (d3: format string bug) The process of verifying format string bugs will now be described.

[0104] FIG. 10 is a diagram showing an example of code for explaining the process of verifying a format string bug.

[0105] The source code written in C language shown in Figure 10(A) may be subject to an attack that exploits the format string of the printf function, which could result in arbitrary code execution. This is because an external input string is passed to the argument of the format string of the printf function without checking the format.

[0106] As a rule or convention regarding vulnerabilities in software development system 1 according to this embodiment, if anything other than a string literal is input to a library function that takes a format string as an argument, it may be evaluated that a vulnerability exists.

[0107] More specifically, the verification engine 212 according to this embodiment performs two processes: (1) searching for code that specifies a format string such as a printf function as an argument, and (2) detecting, as a vulnerability, code that does not specify a fixed-length string literal as an argument among the searched codes. This will detect format string bugs.

[0108] Fig. 10(B) shows an example of an intermediate representation (LLVM IR format, as an example) generated by compiling the source code of Fig. 10(A). In the intermediate representation shown in Fig. 10(B), %7 is used as an argument to the printf function called on line 7. The verification engine 212 according to this embodiment analyzes what value is stored in %7 used as the argument, and if it is not a fixed-length string literal, detects a format string bug as a vulnerability.

[0109] By analyzing such intermediate representations, the validation engine 212 detects format string bugs as vulnerabilities.

[0110] (d4: Extracting unused functions) The process of extracting unused functions will now be described.

[0111] Generally, unused functions increase the attack surface of a program. Unused functions are also suspected of being backdoors. Therefore, the verification engine 212 according to this embodiment extracts unused functions by performing a static call graph analysis of the intermediate representation.

[0112] FIG. 11 is a diagram showing an example of code in an intermediate representation to explain the process of extracting unused functions. As shown in FIG. 11, a call instruction is used for function calls in the intermediate representation in LLVM IR format. The verification engine 212 extracts unused functions by analyzing the relationship of the call instructions. The verification engine 212 then detects the extracted unused functions as vulnerabilities.

[0113] (d5: Example of verification result 400) Next, an example of verification result 400 provided by software development device 100 according to the present embodiment will be described.

[0114] The verification result 400 can be generated by the verification engine 212 of the verification server 200 analyzing the intermediate representation 20. However, to generate a more detailed verification result 400, the debug information 50 generated when the source code 10 is compiled to generate the intermediate representation 20 will also be used.

[0115] The debug information 50 includes attribute information of the source code 10 from which the intermediate representation 20 was generated, and information for associating code included in the intermediate representation 20 with the source code 10. For example, with gcc, which is an example of a compiler, the intermediate representation 20 and the debug information 50 can be generated by compiling with the "-g" option added. In this way, a process for generating the debug information 50 may be executed when the intermediate representation 20 is generated from the source code 10.

[0116] Fig. 12 is a diagram showing an example of a verification result 400 provided by the software development system 1 according to this embodiment. Fig. 12 shows an example in which the verification result 400 is provided in the form of a report, but the verification result may be provided in any format.

[0117] The verification result 400 may be provided via the Web (i.e., in HTTP format) or may be provided by email in text format, PDF format, etc. In the following description, it is assumed that the verification result 400 is typically provided via the Web.

[0118] Referring to FIG. 12, the verification result 400 includes a management section 410, a verification target information section 420, and a solution section. It includes an analysis content section 430 and a summary section 440 .

[0119] The management unit 410 displays a password 412 for re-accessing the verification result 400 and identification information 414 for identifying the verification result 400. For example, the verification server 200 stores the verification result 400 in association with the corresponding identification information 414, and in order to re-access the stored verification result 400, it may be necessary to identify the target verification result 400 using the identification information 414 and then input the password 412.

[0120] To access the target verification result 400, a URL including the corresponding identification information 414 may be used. For example, in the example shown in FIG. 12, "F-ELc_cx" is assigned as the identification information 414. A URL such as "https: / / server.or.jp / F-ELc_cx" including this identification information 414 may be used. You can also make it accessible by specifying a URL.

[0121] The verification target information section 420 displays information about the intermediate representation 20 that is the target of verification. Specifically, the verification target information section 420 displays a source file name 422, memory layout information 424, and compilation environment information 426.

[0122] The source file name 422 indicates the file name of the source code 10 from which the intermediate representation 20 to be verified was generated. The source file name 422 is displayed when the debug information 50 can be referenced. The memory layout information 424 indicates information related to the layout in memory, such as alignment and endian. The compilation environment information 426 indicates information about the compilation environment used to generate the intermediate representation 20 from the source code 10.

[0123] The analysis content section 430 includes analysis content for the detected vulnerability. More specifically, the analysis content section 430 includes vulnerability information 432, source code information 434, intermediate representation information 435, a detailed message 436, and result information 438.

[0124] The vulnerability information 432 is information indicating the type of vulnerability that has been detected. In the example shown in Fig. 12, the vulnerability information 432 is displayed as "FormatStringBug", and the format character It can be seen that the column bug has been detected as a vulnerability.

[0125] The source code information 434 and intermediate representation information 435 indicate information for identifying the type and location of the detected vulnerability.

[0126] The source code information 434 is information indicating the location of the source code in which the detected vulnerability exists. In the example shown in FIG. 12, the source code information 434 is "main() in sample.c at line: 3" and the source file "sample.c" containing source code 10. This indicates that the code was detected on the third line of the function main() in the source code. Note that debug information 50 is required to display the line number (position) of source code 10.

[0127] The intermediate representation information 435 is information indicating the position of the intermediate representation where the detected vulnerability exists. In the example shown in FIG. 12, a code snippet of the intermediate representation is displayed in the intermediate representation information 435. In the example shown in FIG. 12, it can be seen that the call instruction in the intermediate representation indicated by the right arrow symbol -> is the cause of the detected vulnerability.

[0128] In the detailed message 436, a message indicating details regarding the detected vulnerability is displayed. In the example shown in FIG. 12, as the detailed message 436, "Format String must be String-Literal" is displayed, and from this message, it can be understood that a string literal must be specified for the format string.

[0129] As the result information 438, "1 violation(s) detected in this rule." is displayed, and it can be seen that one vulnerability of the format string bug has been detected in the target intermediate representation.

[0130] In the summary section 440, the total number of vulnerabilities detected for the target intermediate representation is displayed. More specifically, summary information 442 is displayed in the summary section 440. As the summary information 442, "1 violation(s) detected in this rule" is displayed, and it can be understood that as a result of the verification, the total number of detected vulnerabilities was 1.

[0131] <E. Execution Environment> The executable code 30 generated in the software development system 1 according to the present embodiment is preferably stored in the secure area of a processor or microcomputer that constitutes the distribution destination controller 300. That is, it is preferable to take some measures in the execution environment so that no tampering is performed on the executable code 30 generated on the condition of authentication for the intermediate representation 20.

[0132] Also, a common signature (for example, a hash value generated from the authenticated intermediate representation 20) may be embedded in both the certificate 40 for the intermediate representation 20 generated in the software development system 1 according to this embodiment and the executable code 30 generated from the intermediate representation 20, and it may be conditional on the existence of the corresponding certificate 40. In this case, in the environment where the executable code 30 is executed (typically, the firmware of a microcomputer), a process for confirming the match between the signature included in the executable code 30 and the signature included in the corresponding certificate 40 may be implemented.

[0133] Also, in the execution environment, the evaluation (judgment of legitimacy) of whether to execute the executable code 30 may be performed at any timing, but typically, it may be performed at the startup of the controller 300 which is the execution environment (during the startup of the firmware or before the start of application execution immediately after startup). That is, at the startup of the controller 300 where the executable code 30 is executed, the legitimacy of the executable code 30 may be evaluated based on the certificate 40 issued in association with the intermediate representation 20 that generated the executable code 30. By confirming that the executable code 30 of the application program is authenticated at the startup of the controller 300, it is possible to avoid a situation where undesirable processing is executed in the controller 300 or the like.

[0134] <F. Modified Example> Regarding the verification in the software development system 1 according to this embodiment, it may be executed by the verification server 200 or may be executed in the software development apparatus 100. When executed by the verification server 200, it may be implemented in the form of cloud computing. Furthermore, when executing verification in the software development apparatus 100, rules authenticated by an external certification authority may be used.

[0135] When the software development device 100 requests the verification server 200 to verify the intermediate representation 20, the target intermediate representation 20 may be encrypted. This makes it possible to prevent tampering with the intermediate representation 20 exchanged between the software development device 100 and the verification server 200.

[0136] A signature from a certificate authority may be attached to the certificate 40 issued by the validation server 200. This makes it possible to prevent fraudulent acts such as tampering with the certificate 40 issued by the validation server 200.

[0137] In the above explanation, an example of a configuration in which the software development device 100 executes the processes of generating source code 10, generating intermediate representation 20, and generating executable code 30 has been described. However, these processes may also be executed in a distributed manner by multiple computing devices.

[0138] The framework for verifying the intermediate representation 20 and issuing the certificate 40 indicating the verification result according to this embodiment can also be applied to a mechanism for selling or distributing applications. For example, when an application developer uploads an application program (executable code 30) to an application distribution server, the developer can request that the corresponding intermediate representation 20 and / or certificate 40 be uploaded as well, thereby enabling the application distribution server to directly or indirectly verify the executable code 30 to be distributed. In this way, by introducing the mechanism according to this embodiment, it is possible to prevent situations such as the distribution of application programs equipped with backdoors, etc.

[0139] In this way, a process may be adopted in which execution of the executable code 30 generated from the intermediate representation 20 is permitted on the condition that the intermediate representation 20 satisfies predetermined rules or regulations regarding vulnerabilities.

[0140] Furthermore, an insurance mechanism for vulnerabilities may be configured using the certificate 40. Specifically, the manufacturer of any device on which the executable code 30 is installed pays a predetermined consideration when using the verification engine 212 (verification server 200). The operator of the verification engine 212 pays a part of the consideration obtained from the device manufacturer to an insurance company or incorporates it into its own insurance fund.

[0141] The executable code 30 executed on any device is executed on the condition of the existence of the certificate 40 provided by the verification engine 212 (verification server 200). In the event that damage occurs due to some incident or security event while being executed on the condition of the existence of the certificate 40, an insurance payment for compensating the damage may be paid from an insurance company or an insurance fund.

[0142] By using the certificate 40 generated by such a verification engine 212 (verification server 200) to manage vulnerabilities and realizing a compensation mechanism in case of an emergency, it is possible to provide an incentive to promote the use of the verification engine 212.

[0143] <G. Advantages> In this embodiment, by verifying the intermediate representation 20 instead of the source code 10, vulnerabilities included in the application program can be more efficiently discovered while concealing know-how and the like included in the source code 10.

[0144] Also, by verifying the intermediate representation 20, general-purpose verification becomes possible without depending on the language of the source code 10 and the target architecture.

[0145] The embodiments disclosed this time should be considered illustrative in all respects and not restrictive. The scope of the present invention is shown by the claims rather than the above description, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Explanation of Reference Numerals

[0146] 1 Software development system, 2 Internet, 4 Edge device, 10 Source code, 20 Intermediate representation, 30 Executable code, 40 Certificate, 50 Debug information, 100 Software development equipment, 102, 202 Processor, 104, 204 Main Memory, 106, 206 Input section, 108, 208 Display, 110, 210 Hard disk, 114 Software development program, 120, 220 Internal bus, 122, 222 Communication interface, 200 Verification server, 212 Verification engine, 214 Certificate issuing engine, 300 Controller, 400 Verification result, 410 Management section, 412 Password, 414 Identification information, 420 Verification target information section, 422 Source file name, 424 Memory layout information, 426 Compilation environment information, 430 Analysis content section, 432 Vulnerability information, 434 Source code information, 435 Intermediate expression information, 436 Detailed message, 438 result information, 440 summary section, 442 summary information.

Claims

1. A means of obtaining an intermediate representation generated from source code, A means for verifying vulnerabilities in the aforementioned intermediate representation, An information processing device comprising means for outputting information indicating the location and type of the vulnerability contained in the source code corresponding to the intermediate representation, based on the results of the verification.

2. The information processing apparatus according to claim 1, wherein the information indicating the type of vulnerability includes bugs contained in the source code.

3. The information processing apparatus according to claim 1 or 2, wherein the information indicating the type of vulnerability includes a notification that abnormal operation may occur depending on the conditions.

4. The information processing apparatus according to any one of claims 1 to 3, wherein the information indicating the type of vulnerability includes a notification indicating unused functions described in the source code.

5. The information processing device according to any one of claims 1 to 4, wherein information indicating the location of the vulnerability and the type of the vulnerability is output to a terminal connected to the information processing device via a network.

6. The location where the vulnerability exists is output in association with the source code, as described in any one of claims 1 to 5, in the information processing device according to any one of claims 1 to 5.

7. The information processing apparatus according to any one of claims 1 to 6, wherein the intermediate representation is obtained from a terminal connected to the information processing apparatus via a network.

8. The information processing apparatus according to any one of claims 1 to 7, wherein the generation or execution of executable code based on the source code is permitted, provided that the aforementioned vulnerability does not exist.

9. On the computer, Steps include obtaining an intermediate representation generated from the source code, The steps include: verifying vulnerabilities in the aforementioned intermediate representation, An information processing program that, based on the results of the verification, performs the step of outputting information indicating the location and type of the vulnerability contained in the source code corresponding to the intermediate representation.

10. A method of information processing performed by a computer, Steps include obtaining an intermediate representation generated from the source code, The steps include: verifying vulnerabilities in the aforementioned intermediate representation, An information processing method comprising the step of outputting information indicating the location and type of the vulnerability contained in the source code corresponding to the intermediate representation, based on the results of the verification.

Images