Information processing device, information processing method, and program

Abstract

To provide a solution that can ensure the security of an application program.SOLUTION: A software verification method includes the steps of: generating an intermediate representation from a source code;verifying whether or not the intermediate representation satisfies predetermined regulations or predetermined rules related to vulnerability; and outputting a verification result obtained in the step of verification.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 conventional 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 various 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 allow connections to be made simpler, safer, and more freely.

[0003] As devices used in IoT (also called "edge devices") become more intelligent, various types of application programs will be able to run 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 built 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] JP 2014-174577 A 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 certain rules or regulations regarding vulnerabilities, and outputting the verification results obtained by the verifying 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 a step of 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 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 a means for generating an intermediate representation from the source code. The verification server includes a means for verifying whether the intermediate representation satisfies predetermined rules or regulations regarding vulnerabilities, and a means for outputting a verification result obtained by the verifying means. Effect of the Invention

[0014] According to the present disclosure, a solution that can ensure the safety of application programs can be provided. [Brief description 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; [Diagram 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. [Diagram 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 showing an example of a hardware configuration of a software development apparatus according to an embodiment of the present invention. [Diagram 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 the software development system 1 according to this embodiment. [Figure 7] It is a diagram showing an example of code for explaining the verification process of a static buffer overflow. [Figure 8] It is a diagram showing an example of code for explaining the verification process of a runtime buffer overflow. [Figure 9] It is a diagram showing an example of code when the code shown in FIG. 8 is made to conform to the rules or conventions regarding vulnerabilities in the software development system according to this embodiment. [Figure 10] It is a diagram showing an example of code for explaining the verification process of a format string bug. [Figure 11] It is a diagram showing an example of intermediate representation code for explaining the process of extracting unused functions. [Figure 12] It is a diagram showing an example of a verification result provided by the 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 with reference 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 the 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. Also, 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 identifying the type of vulnerabilities present and their location in the source code 10, in addition to verifying whether the application program contains any vulnerabilities.

[0019] Furthermore, on the condition that the intermediate representation 20 has no vulnerabilities (i.e., there are no problems in the verification results), generation of the corresponding execution code 30 or execution of the generated execution code 30 may be permitted.

[0020] In this specification, "intermediate representation" means 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 assembler language.

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

[0022] Typically, the intermediate representation 20 is generated independent of the platform and architecture on which the executable code 30 is 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 process described therein can be made more efficient.

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

[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 described below, the verification result 400 includes information indicating the type of vulnerability detected and information specifying the location of the source code 10, so that the user can 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 generation condition for the execution code 30 is that the verification result 400 has no problem. In this example, if the verification result 400 has no problem, the verification server The server 200 authenticates 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 employing 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 execution code 30 generated from the intermediate representation 20 is that there is no problem with the verification result 400. In this example, if there is no problem with the verification result 400, the verification server 200 issues a certificate 40 including authentication for the intermediate representation 20. In parallel, the execution code 30 is generated from the intermediate representation 20. The execution of the generated execution code 30 may be made 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 execution code 30. By employing such an execution condition, it is possible to reduce the possibility that the execution code 30 will be executed in an unsafe state.

[0028] In this way, by verifying the intermediate representation 20 instead of the source code 10, vulnerabilities contained in an application program can be found more efficiently while keeping know-how, etc., contained in the source code 10 confidential. Also, 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, etc., 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 of 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] 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 assists in 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, and 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, moving objects such as vehicles, any portable device, and the like. 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 software development device 100 ((1) Source Code Creation). Then, the created source code is compiled in software development device 100 to generate intermediate representation 20 ((2) Intermediate Representation Generation).

[0037] Before the execution code 30 is generated from the intermediate representation 20, the intermediate representation 20 is verified. In the example shown in Fig. 2, the generated intermediate representation 20 is transmitted 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 apparatus 100 ((4) Verification of Intermediate Representation). Then, the verification server 200 transmits the verification result 400 obtained by the verification of the intermediate representation 20 to the software development apparatus 100. The software development apparatus 100 receives the verification result 400 from the verification server 200 ((5) Reception of 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 corrects the source code 10 ((6) Correction of 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 apparatus 100 to generate the executable code 30 from the intermediate representation 20 ((7) Generation of Executable Code). The generated executable code 30 is transferred from the software development apparatus 100 to the controller 300 of the edge device 4 ((8) Transfer of Executable Code). Then, the controller 300 of the edge device 4 executes the transferred executable code 30 as necessary ((9) Execution of 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 Apparatus 100) The software development apparatus 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 the present embodiment. With reference to Fig. 4, software development device 100 includes, as main components, a processor 102, a main memory 104, an input unit 106, a display 108, a hard disk 110, and a communication interface 122. These components are connected via an internal bus 120.

[0045] The processor 102 is, for example, a central processing unit (CPU) or a graphics processing unit (GPU). 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 dynamic random access memory (DRAM) or a static random access memory (SRAM). 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 among the programs stored in 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 to realize various functions as described below.

[0047] Typically, the hard disk 110 stores source code 10 created arbitrarily by the user, a software development program 114 for realizing an integrated development environment, and execution code 30 generated from the source code 10. The software development program 114 generates the execution code 30 from the source code 10 created arbitrarily 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 an operation button arranged on the housing of the software development device 100.

[0049] The display 108 displays the results of processing by 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 program such as an ASIC (Application Specific Integrated Circuit) incorporating a circuit that corresponds 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). Moreover, it may be realized by appropriately combining the processor 102, a main memory, an ASIC, an FPGA, and the like.

[0052] The software development device 100 may further include a component for reading the stored software development program 114 including computer-readable instructions from a non-transitory medium that stores the program. The medium may be, for example, an optical medium such as a Digital Versatile Disc (DVD), a semiconductor medium 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 validation 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 the present 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, for example, by a CPU, a GPU, etc. A plurality of processors 202 may be arranged, or a processor 202 having a plurality of cores may be employed.

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

[0058] Typically, the hard disk 210 stores a verification engine 212 that receives an external request and executes a verification process of the intermediate representation 20. The verification engine 212 executes a process of verifying whether or not the intermediate representation 20 contains vulnerabilities, and a process of 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. The certificate issuing engine 214 issues a certificate 40 associated with the intermediate representation 20 if there is no problem with the verification result 400.

[0060] The input unit 206 accepts input operations by a user who operates the validation server 200. The display 208 displays the results of processing by 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 the network.

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

[0065] FIG. 6 is a sequence chart showing an example of the procedure of the software verification method in the software development system 1 according to the present 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] In response to the verification request from the software development device 100, the verification server 200 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 other hand, if there is no problem with the verification result 400 (YES in step S108), the user operates the software development device 100 to generate the 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, the verification of the intermediate representation 20 may include a process of judging whether or not the intermediate representation 20 satisfies predetermined rules or regulations regarding vulnerabilities. The predetermined rules or regulations regarding vulnerabilities include conditions for the application program (the intermediate representation 20 and the corresponding executable code 30) to be safe. Typical examples of such conditions for safety include the following:

[0073] (1) It does not contain any memory operations whose safety cannot be confirmed (or any dangerous memory operations) (or such memory operations are not compilable). (2) There is no undefined behavior in the code. (3) There is no lack of error handling syntax (error handling syntax is included appropriately) (4) It does not contain unregulated error handling. The above (1) memory operations whose safety cannot be confirmed (or dangerous memory operations) include memory access to the system area or secure area, and memory operations such as block erase and block write to a 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 that the application program (the intermediate representation 20 and the corresponding executable code 30) does not have a so-called backdoor. A backdoor refers to a function or connection port that allows a (usually malicious) third party to access the application program in a manner not recognized by the user of the application program. In verifying the intermediate representation 20, it may be determined whether an access path from outside 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). A verification model for implementing 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-mentioned verification content in more detail.

[0079] (a) Static buffer overflow (b) Runtime buffer overflow (c) Integer overflow (d) Format string bug (e) Control statement deficiency (f) Access to uninitialized data (g) Extraction of unused functions (h) Access to Uninitialized Data (i) Writing to a null pointer (j) Reading a null pointer (k) Duplicate release of resources (l) OS Command Injection Note that 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 processes will be described in detail. (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 a 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. Therefore, different results will be output each time the code is executed. For ease of explanation, the source code in Figure 7(A) is accompanied by the comment "^^^ 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] Fig. 7(B) shows an example of an intermediate representation (LLVM IR format, for example) generated by compiling the source code in Fig. 7(A). Note that in the intermediate representation shown in Fig. 7(B), the code of the part marked "Omitted" is omitted.

[0085] The verification engine 212 according to this embodiment detects static buffer overflows by performing two processes: (1) searching for code that accesses a fixed-length array with an index, and (2) detecting code that accesses the array with 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 for obtaining 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 refers to 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 run-time buffer overflow will now be described.

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

[0090] In general, 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 FIG. 8(A), a buffer overflow may occur depending on the value of the index at run time (the value of the variable index). For the sake of convenience, the source code in Figure 8(A) states that "^^^index determines the buffer size. 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 a process for checking in advance the value of an index used to access an array may be evaluated as having a vulnerability.

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

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

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

[0095] In the intermediate representation shown in FIG. 8B, 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 the getelementptr instruction is not a specific number. There is an index access using a variable (the variable index in the source code). You can find what is there.

[0096] Here, the "%5" corresponding to the variable index in the source code is not checked, but is written to the buffer. The use of the index to access the data is what causes a runtime buffer overflow.

[0097] FIG. 9 is a diagram showing an example of code when the code shown in FIG. 8 is adapted to 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. By checking this, error handling is performed (see lines 3 to 6). Source code including such error handling processing may be considered as code that complies with the rules or regulations regarding vulnerabilities in the software development system 1.

[0099] Fig. 9(B) shows an example of an intermediate representation (LLVM IR format, for example) generated by compiling the source code in Fig. 9(A). Note that in the intermediate representation shown in Fig. 9(B), the code of the part 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 is the array accessed with "BoundsCheckOK" (6 ~Line 10).

[0101] When there is code that accesses a buffer by index, 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 index value used in the access in advance.On the other hand, if there is no process that checks the index value used in the access to the buffer in advance, the verification engine 212 detects a runtime buffer overflow as a vulnerability.

[0102] By analyzing such intermediate representation, the verification engine 212 detects run-time 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 a process for verifying a bug in a format string.

[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, leading to the execution of arbitrary code. 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 the present embodiment performs two processes: (1) searching for code that specifies a format string such as a printf function as an argument, and (2) detecting, among the found codes, code that does not specify a fixed-length character string literal as an argument as a vulnerability. 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 in Fig. 10(A). Note that in the intermediate representation shown in Fig. 10(B), %7 is used as an argument to the printf function called in 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: Extraction of unused functions) The process of extracting unused functions will now be described.

[0111] Generally, unused functions increase the attack surface of a program. In addition, unused functions are also suspected of being backdoors. Therefore, the verification engine 212 according to the present 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 for explaining a process for extracting unused functions. As shown in Fig. 11, a call instruction is used for a function call in the intermediate representation in the LLVM IR format. The verification engine 212 extracts unused functions by analyzing the relationship of the call instructions. Then, the verification engine 212 detects the extracted unused functions as vulnerabilities.

[0113] (d5: An example of verification result 400) Next, an example of the verification result 400 provided by the 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, in order to generate a more detailed verification result 400, the debug information 50 generated when compiling the source code 10 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, in 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 manner, a process of 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 the present 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 form.

[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] 12, the verification result 400 includes a management section 410, a verification target information section 420, and a solution section 430. 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 by 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 given as the identification information 414. It is also possible to 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 on the compilation environment used to generate the intermediate representation 20 from the source code 10.

[0123] The analysis content portion 430 includes analysis content for the detected vulnerability. More specifically, the analysis content portion 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 a 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 in 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 -> was 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 a format string bug was 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 one.

[0131] <E. Execution Environment> The executable code 30 generated in the software development system 1 according to this embodiment is preferably stored in the secure area of the processor or microcomputer that constitutes the 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, a situation where undesirable processing is executed in the controller 300 or the like can be avoided.

[0134] <F. Modification 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. Further, when executing the 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 added 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 has been described in which the software development device 100 executes the process of generating source code 10, the process of generating intermediate representation 20, and the process of generating executable code 30. However, these processes may also be executed in a distributed manner among 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 (execution 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 allowing the application distribution server to directly or indirectly verify the execution code 30 to be distributed. In this way, by introducing the mechanism according to this embodiment, it is possible to prevent a situation in which an application program equipped with a backdoor or the like is distributed.

[0139] In this way, a process may be adopted that permits execution of the executable code 30 generated from the intermediate representation 20, provided that the intermediate representation 20 satisfies certain 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 part of the consideration obtained from the device manufacturer to the 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 the insurance company or the insurance fund.

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

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

[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 as illustrative in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the claims, and it is intended that all modifications within the meaning and scope equivalent to the claims are included.

Description 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 Detail message, 438 result information, 440 summary section, 442 summary information.

Claims

1. means for obtaining an intermediate representation generated from the source code; means for verifying whether the intermediate representation satisfies predetermined rules or conventions regarding vulnerabilities; and generating a verification result indicating whether the intermediate representation satisfies the predetermined rule or convention.

2. The information processing apparatus according to claim 1 , further comprising: means for storing the verification result in association with identification information for identifying the verification result.

3. means for acquiring debug information generated when the intermediate representation is generated from the source code; The information processing apparatus according to claim 1 , wherein said verifying means refers to said debug information.

4. 4. The information processing apparatus according to claim 1, further comprising: a means for issuing a certificate including authentication for said intermediate representation if said intermediate representation satisfies said predetermined rules or regulations.

5. The information processing apparatus according to any one of claims 1 to 4, further comprising: a means for providing a verification result associated with the identification information in response to an access including the identification information.

6. The information processing device according to any one of claims 1 to 5, wherein the verifying means executes at least one of a process of verifying whether or not the intermediate representation contains vulnerabilities, or a process of identifying information indicating a type of vulnerability that exists and a location of source code.

7. 7. The information processing device according to claim 6, wherein the verification result includes at least one of information indicating a type of the detected vulnerability, information indicating a location of the intermediate representation where the detected vulnerability exists, or information indicating a location of the source code where the detected vulnerability exists.

8. The information processing device according to claim 1 , wherein the information processing device does not generate an execution code from the intermediate representation.

9. 1. A computer-implemented information processing method, comprising: obtaining an intermediate representation generated from the source code; verifying whether the intermediate representation satisfies predefined rules or conventions regarding vulnerabilities; generating a verification result indicating whether the intermediate representation satisfies the predetermined rule or convention.

10. A program for causing a computer to execute the information processing method according to claim 9.

Images