JP6349244B2 - In-vehicle network testing equipment - Google Patents

Description

  The present invention relates to an apparatus for verifying security vulnerabilities that are exposed through data flowing in an in-vehicle network in an in-vehicle electronic apparatus.

  At the DEFCON 21 International Conference on Information Security held in August 2013 (the world's largest security conference held in Las Vegas, Nevada, USA), the information flowing through the CAN (Controller Area Network), an in-vehicle network, was analyzed. The video of the demonstration experiment that attacks by impersonating the communication was released. Since then, discussions regarding the security of in-vehicle networks and in-vehicle electronic devices connected thereto have attracted attention.

  The premise was that the in-vehicle network standard was a public international standard and that it would be used in a closed environment inside the car. Therefore, it has been assumed that the whole is handled by a bona fide designer. However, it is revealed that a malicious third party may connect from the outside and affect the control of the vehicle, and that no one has ever thought about it (even if it has been thought, economic rationality is unknown and postponed) Since then, the discussion on this threat has been very exciting.

  In particular, automated driving that each company is trying to tackle as a future technology is a mechanism in which the judgment of vehicle control software is given priority over the will of the driver in certain situations, and this can be used for malicious third parties for terrorist purposes. Control can cause serious human and property crises.

  As countermeasures against this threat, it is presumed that technologies such as encryption and digital signature used in the current Internet technology field will also come down to the in-vehicle network field. However, even if these countermeasures are implemented properly, the problem is a vulnerability caused by processing exceptions of control software such as buffer overflow (especially driver software groups handling in-vehicle networks and application software using those data). It is sex. For buffer overflow, there is no unified methodology or fundamental solution, and there is no other way but to find and solve the problem of the corresponding software individually and crushedly.

  Buffer overflow can be caused by causing the in-vehicle ECU (Electronic Control Unit) to suspend processing by the data sent through the in-vehicle network, or in the worst case, transferring the control to the network transmission data as a control code (machine language). It is possible to take over the in-vehicle ECU. In any case, it is good for the vehicle-mounted ECU to be reset during running (a big driving shock occurs depending on the vehicle running state), and in the worst case, it is hit by a control hijack by a malicious third party. This is a great threat not only to vehicle drivers but also to the transportation society.

  As described above, in order to prevent buffer overflow, it is important to make sure that control software is securely built and verified, and there is no technical magic bullet. Another characteristic is that new vulnerabilities can be easily created when software is modified or used.

  Here, the expression “secure” means “technically secure”.

  The proof that Windows XP (registered trademark), the operating system of the personal computer, has not withered in terms of security vulnerabilities even after the end of its life (life cycle) after 12 years. is there.

  In recent years, it has become difficult to perform a comprehensive test of a program by a white box test due to an increase in control software. Therefore, it has become a realistic countermeasure to perform a vulnerability test by applying a technique such as fuzzing (see Non-Patent Document 1).

  The prior art is a technical field of content viewers on the Internet, and is not necessarily applied to in-vehicle devices. For example, as shown in Patent Document 1, a network input is widely variable, a module in which exception processing occurs is specified, and a content viewer A technology of a detection apparatus and a bug detection method for detecting vulnerabilities of the above is known.

Japanese Patent No. 5386015

"Fuzz Testing of Application Reliability", Barton Miller <URL: http://pages.cs.wisc.edu/~bart/fuzz/>

  However, in the said patent document 1, this cannot be applied to the vulnerability test | inspection of a vehicle-mounted network as it is. This is because the protocol differs between the general Internet and the in-vehicle network, and the use and meaning of data flowing through the network are also different.

  In addition, even in a test using fuzzing exemplified in Non-Patent Document 1, comprehensive and efficient verification cannot be performed unless the in-vehicle control software understands the mechanism in which vulnerability is held and attaches test cases to rules.

  The vulnerabilities that should be noted with in-vehicle control software are network-related drivers and application buffer over errors.

  In general, there are mainly two types of buffer over errors, a stack overflow error and a heap overflow error. However, when limited to the technical field related to the in-vehicle control device, the stack overflow error that should be particularly problematic among buffer over errors is not a heap overflow error.

In-vehicle control software does not use a heap. Dynamic memory management such as heap makes it difficult to grasp the worst execution time and generates non-reproducible delay, so it is unsuitable for control software for in-vehicle use and is not normally used. (The heap is suitable for soft real-time control, not for hard real-time control like automobiles.)
In the in-vehicle control device, the occurrence of a stack overflow error is unavoidable due to the language mechanism because the control software is described in C language or C ++ language, and a device and a method capable of efficiently verifying this are required.

  In the in-vehicle network, CAN FD (CAN with Flexible Data Rate) and Ethernet (registered trademark) and the data amount (payload) per communication frame are expected to become larger year by year due to advanced control.

  At that time, it is assumed that communication software that conforms to a low-capacity (small payload) communication protocol is used as a base, and this is used to modify and improve the new protocol. If it is not properly expanded, or at least abnormal processing that is aware of data storage overflow is not created, stack overflow will easily occur, resulting in a vulnerability.

  Therefore, an object of the present invention is to provide an in-vehicle network testing apparatus that automatically finds vulnerabilities resulting from the built-in mechanism unique to the in-vehicle control software.

  In order to solve the above problems, for example, the configuration described in the claims is adopted.

  The present invention includes a plurality of means for solving the above-described problems. For example, the vehicle-mounted network for verifying the operation of the vehicle-mounted electronic device that obtains control information from the vehicle-mounted network and reflects it in the operation. An abnormality detector that detects at least one of a reset interrupt, an address error, or an illegal instruction interrupt of a CPU (Central Processing Unit) of the in-vehicle electronic device, and a transmission message supplied to the in-vehicle network dynamically. The test data generator includes a dictionary that stores message identifiers that can be received by the in-vehicle electronic device, and data that is generated by dynamically changing the payload amount per unit message. Generator and the test data generator The combination data of the message identifier and the payload generated from the above is supplied to the in-vehicle electronic device via the in-vehicle network, and at least one of the reset interrupt, address error, or illegal instruction interrupt of the in-vehicle electronic device by the abnormality detector It is characterized by monitoring the occurrence of.

  ADVANTAGE OF THE INVENTION According to this invention, the test apparatus and test method which can extract the vulnerability of a vehicle by exhaustively verifying the stack overflow error which generate | occur | produces via the data which flow into a vehicle-mounted network at an early stage can be provided.

  Problems, configurations, and effects other than those described above will be clarified by the following description of embodiments.

1 is an overall configuration diagram of an in-vehicle network test apparatus according to an embodiment. FIG. 3 is a memory layout diagram showing a mechanism of a stack overflow error targeted for detection by the present invention. It is explanatory drawing which showed the factor by which the stack overflow error made into a detection target by this invention is made into control software. It is the time chart which showed the time-sequential operation | movement of the vehicle-mounted network test apparatus which concerns on this embodiment. It is a flowchart which shows the internal operation | movement procedure of the vehicle-mounted network test apparatus which concerns on this embodiment.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

<Outline of this embodiment>
In the test apparatus of the present embodiment, a test dictionary is held using a message identifier that can be received by the on-vehicle ECU to be tested as a database.

  Similarly, the payload generator generates a data frame larger than an assumed payload amount (a payload amount given by design and built in software) corresponding to each message identifier, and synthesizes it with the message identifier to form an in-vehicle network. Can be sent to.

  On the other hand, a debug port or a similar signal terminal is prepared around the CPU of the in-vehicle ECU to be tested, and is connected to catch the occurrence of CPU reset or exception processing and transmit it to the test apparatus of the present invention.

  In the test apparatus according to the present embodiment, the combination of the message identifier and the payload is automatically and comprehensively transmitted to the in-vehicle network, and the behavior of the in-vehicle ECU to be tested, particularly whether exception processing has been executed or whether a reset has occurred. Can be checked automatically.

  Since it is a vulnerability detection test that assumes the above-described mechanism for creating a stack overflow error, it is important to test the amount of payload by sweeping from the amount assumed by communication (design value) to the upper limit of the protocol. It becomes.

  It is also important for the payload data itself to set a value that is likely to cause exception processing in the CPU of the in-vehicle control device ECU. For example, a value corresponding to an exception vector converted to an address can be cited as a value candidate.

<Configuration in the embodiment>
FIG. 1 illustrates one embodiment of the present invention.

  The in-vehicle ECU 110 receives information from the in-vehicle network 120 and reflects it in the control. The in-vehicle ECU 110 is an object to be tested in the present invention.

  The test apparatus 100 of the present invention is connected to the in-vehicle network 120 through a connection 109 and monitors the operation of the in-vehicle ECU 110 through a connection 116.

  The test apparatus 100 is mainly composed of a test data generator 107 and an abnormality detector 101, and the entire operation is controlled by the sequencer 103 to execute the test operation.

  The test data generator 107 includes a received message identifier dictionary 105, a payload data generator 106, seed data 108, and a message synthesizer 102 that synthesizes them to generate a transmission frame.

  A test transmission message sent from the test apparatus 100 to the in-vehicle network 120 is captured by the network device 113 inside the in-vehicle ECU 110 and transferred to a RAM (Random Access Memory) 112 by the action of the CPU 111. Will enter a phase where the vulnerabilities described below will occur.

  The RAM 112 and the CPU 111 are connected by an internal bus 114, and the return address of the function (and the stack frame in which it is stored) is also stored in the RAM 112, but this is destroyed by data received from the network and causes a vulnerability. Is the factor.

  When the CPU 111 encounters a vulnerability, a reset occurs or exception processing is performed, so that the situation is externally output from the debug port 115, and the abnormality detector 101 of the test machine 100 is captured through the connection 116 and sent to the sequencer 103. Report.

  The sequencer 103 performs display so that an external operator can recognize that the vulnerability has been detected. However, the display device (or man-machine interface) may be included in the testing machine 100 as shown by 104 in FIG. 1, or for example, only an abnormality detection signal is output to the outside for display and recording. May be performed by a separate device (not shown) separated from the testing machine 100.

  The situation where the reset occurs in the CPU 111 described above includes a case where control directly jumps to the reset vector and a case where a reset signal is input from the external watchdog timer due to software runaway. Also, the situation where exception processing occurs in the CPU 111 is not possible as a result of an address error that attempts to refer to an address space that is not normally permitted, or as a result of transitioning to an abnormal address and executing that bit string as an instruction (indecipherable) It may occur due to an illegal instruction interrupt caused by fetching an instruction.

  In either case, the anomaly detector 101 can detect this situation via the debug port 115.

  Each of the above-described configurations, functions, processing units, and the like can be realized as hardware by designing all or a part thereof, for example, with an integrated circuit, and the processor executes a program that realizes each function. It can also be realized as software. Information such as programs and tables for realizing each function can be stored in a storage device such as a memory or a hard disk, a storage medium such as an IC card, a USB memory, an SD card, a CD-ROM, or a DVD.

<Vulnerability principle and built-in factors>
FIG. 2 explains why the stack overflow error can be vulnerable.

  Using the buffer overflow, the control software can be operated unexpectedly. There are two types of buffer overflows: stack overflow and heap overflow. As described above, the problem of in-vehicle control software is the former stack overflow.

  To explain the principle, the control software secures a memory area called a buffer 203 in order to store not only network data but also data received from the outside. The standard of software processing is to prepare a buffer with a fixed size determined in advance and write the received data there.

  In general, the length of data received is variable. Therefore, the control software should check the length of the data so that the received data does not exceed the size of the buffer. However, some applications omit checking the length of the data.

  For example, a buffer for storing one frame of communication data, and a buffer for the maximum number of bytes (upper limit of payload) when the maximum number of bytes of one frame (upper limit of payload) is determined as the standard of the communication protocol Once the application is secured, the application may not need to perform a comparison check between the received data length and the entire buffer length.

  When data exceeding the size of the buffer is sent to such control software, for example, from the in-vehicle network, the data overflows from the buffer as a matter of course. Overflowing data overwrites data in other memory areas used by the program. As a result, the program does not work properly or hangs up.

  Thus, by utilizing the malfunction of the control software, it is possible to stop or interrupt the normal operation of the control software. This is called a denial of service (DoS) attack.

  In addition to stopping and interrupting operations due to DoS attacks, attacks that use buffer overflow to execute intended actions have also appeared.

In the case of C language or C ++ language, a program is usually made such that one program requests processing to another small program (function subroutine). This function subroutine secures a stack area 200 for temporary use on a memory of RAM (corresponding to 112 in FIG. 1). In the stack area 200, the above-described buffer 203 and return address 204 are written in addition to saved data such as local variables to be actually used by the subroutine and register contents of the calling program. The return address 204 is an address of a memory used for returning to the original program when processing by the subroutine is completed. (Refer to the return address 204 of “normal state 201” in FIG. 2)
In this state, if the data 205 sent as described above is larger than the buffer 203, the data overflows and it is possible to overwrite the stack area 200 in which the return address 204 is described. Therefore, another value 208 is written as a return address in the overflowed portion 206 of the sent data as shown in “state 202 after illegal data is sent” in FIG. 2, and the written return address is designated. An illegal instruction code 207 for executing a command desired by the attacker is described in the memory area.

  As a result, an arbitrary command (invalid instruction code 207) can be executed with the same authority as the calling source program is operating at the timing when the function subroutine returns. If the program is running with a strong authority like supervisor mode, such an attack will have fatal consequences immediately and control will be taken over by the attacker over the network.

  FIG. 3 is a diagram illustrating the factors that cause such vulnerabilities.

  In FIG. 3, the contents of the stack area 200 are described in detail in comparison with FIG. 2, and the values of the save registers such as the base register are stored in order toward the top of the return address 204 (the one with the smaller address). Then, an automatic variable (local variable) used by the called function gets on it. It is assumed that the local variables used by the called function and the processing buffers (302 and 304) discussed here are stored in the automatic variables (local variables).

  In normal secure coding, as in the transfer method (a), the size of data stored in the processing buffer [n] 302 and the reception register 301 of the network device 113 is compared, and a transfer 303 with a check is performed. As long as the processing buffer [n] 302 does not overflow, the transfer from the reception register 301 to the processing buffer [n] 302 is performed.

  However, as in the transfer method (b), in many cases, the unchecked transfer 305 is performed while securing the processing buffer [protocol_max] 304 corresponding to the maximum number of bytes per frame (upper limit value of the payload) of the communication protocol.

  The problem here is when a program that performs such unchecked transfer is used as communication software of another protocol having a different maximum number of bytes (upper limit value of payload).

  If the number of processing buffers [protocol_max] 304 is not adjusted at the diversion destination, the stack overflow 306 is easily caused when the maximum number of bytes (upload upper limit value) of the diversion destination protocol is larger than the diversion source.

  At present, since the maximum number of bytes (upper limit value of payload) is increased in the new communication standard such as CAN → CAN FD → Ethernet, such vulnerabilities may be internalized in various in-vehicle ECUs corresponding to the network. Concerned.

<Operation in the embodiment>
FIG. 4 is a time chart showing the operation of the test apparatus 100.

  The horizontal axis of FIG. 4 is a test case 402 collected as a group for each identifier (ID) of the received message, and all the received identifier tests are comprehensively provided to the in-vehicle ECU 110 and the response is examined.

  The reason why all the received identifiers are exhaustively tried is that the processing function is different depending on the received identifier and the situation where the vulnerability occurs is also different.

  The vertical axis in FIG. 4 is the number of payloads 401 per frame, and test cases are set continuously by increasing the payload by 1 byte from the expected payload (design value). Needless to say, the maximum value of the payload is the protocol upper limit value 407 defined by the protocol.

  When the behavior is observed for each individual reception ID, a test case is formed by increasing the payload by one byte at the reception IDn−1 · 403 from the expected payload value Pn−1 · 404.

  The expected payload value is determined by being associated with an individual reception ID by design, and network messages are exchanged with a fixed payload amount in a normal network operation. This basic value is stored in the received message identifier dictionary 105 in association with the received ID value.

  In the test group of reception IDn−1 · 403, the payload was swept from the payload expected value 404 to the protocol upper limit value 407, and as a result, abnormal operation was not caused in the in-vehicle ECU 110.

  In the subsequent reception IDn · 405, when the payload was sequentially increased from the expected payload value Pn · 406 and tested, the in-vehicle ECU 110 was reset (408), and the payload value at that time was Pvulune. 409.

  That is, the return address 204 is rewritten with this payload value as indicated by 306 in FIG.

  If the vulnerability as described above is found, the test apparatus 100 displays the fact on the display device 104 shown in FIG. 1, stops the operation, and asks for the operator's instruction.

  FIG. 5 is a flowchart showing the operation of the test apparatus 100. The operation will be described sequentially according to the flow of FIG.

In step S <b> 501, a message ID that can be received by the in-vehicle ECU 110 to be tested is searched from the identifier dictionary 105. In step S502, the payload expected value (corresponding to Pn-1 · 404 and Pn · 406 in FIG. 4) associated with the message ID is retrieved and stored in the variable P. (Indicated as an arrow P 121 in FIG. 1)
In step S503, the variable P is incremented, and in the determination step S504, a comparison with the protocol upper limit value is executed. If it exceeds the protocol upper limit, the process proceeds to step S505. If not, the transmission frame is synthesized and transmitted to the in-vehicle network 120 in step S506.

  If it exceeds the protocol upper limit value, the process proceeds to step S505, where it is confirmed whether the test pattern has been exhaustively tried over all receivable message IDs. If the coverage of receivable message IDs is not completed, the process returns to S501, and the series of tests is performed again by changing the received message ID.

  In step S506 subsequent to the determination step S504, the received message ID searched in S501, message length information calculated based on the protocol amount set in S503 (DLC: Data Length Code in the CAN protocol), and The body of the transmission frame is formed by combining the bit string of the payload body.

  As mentioned in the phenomenon 306 in FIG. 3, it is more convenient for the payload body to be composed of repeated values that are easily observed from the outside when the return address 204 is replaced.

  That is, when the CPU of the in-vehicle ECU 110 interprets as an address value, it generates a reset interrupt that matches the reset vector, causes an address error by deviating from the address boundary, or an illegal or undefined instruction It is preferable to generate a payload of a transmission message by predictively generating data that causes an operation that can be detected by the abnormality detector 101 by instructing the storage location to generate an illegal instruction interrupt.

Therefore, although this value differs depending on the CPU architecture mounted on the in-vehicle ECU 110 to be inspected, it is important that the value is determined for the above purpose. (In FIG. 1, which is an overall configuration diagram of the test apparatus, it is shown as payload seed data 108.)
In the subsequent step S507, the behavior of the in-vehicle ECU 110 is examined as a response to the transmission of the test transmission frame to the network in S506. If an abnormal state such as reset or exception processing has not occurred in the in-vehicle ECU 110, the process returns to S503, and if it has occurred, a message indicating that a vulnerability has been found is displayed in step S508 and the operation is terminated.

  When returning to S503, the above-described series of operations is repeated by increasing the payload amount by one.

  In the flowchart of FIG. 5, from the viewpoint of simplifying the chart, each receivable message ID is expressed by an algorithm in which a test is started from a payload amount of (payload assumed value + 1), but as shown in FIG. The test may be started from the payload amount of the payload expected value itself, and this difference is not an essential problem that affects the gist of the present invention.

  As described above, according to the embodiment of the present invention, it is possible to comprehensively and automatically detect vulnerabilities of the in-vehicle ECU caused by data flowing in the in-vehicle network with manpower.

  Further, the test apparatus according to the present invention can be applied to a test of an in-vehicle network based on a wide range of communication protocols such as CAN, CAN FD, and Ethernet.

DESCRIPTION OF SYMBOLS 100: Test apparatus 101: Abnormality detector 102: Message synthesizer 103: Sequencer 104: Display apparatus 105: Dictionary of received message identifier 106: Payload data generator 107: Test data generator 108: Payload seed data 109: [ Test equipment → In-vehicle network] Connection 110: In-vehicle ECU
111: CPU
112: RAM
113: Network device 114: Internal bus 115: Debug port 116: [In-vehicle ECU → Test equipment] connection 120: In-vehicle network

Claims (11)

With respect to an in-vehicle electronic device that acquires control information from an in-vehicle network and reflects it in an operation, the in-vehicle network test device for verifying this operation,
It is composed of an abnormality detector that detects at least one of a reset interrupt, an address error, or an illegal instruction interrupt of the CPU of the in-vehicle electronic device, and a test data generator that dynamically changes a transmission message supplied to the in-vehicle network,
The test data generator is composed of a dictionary that stores message identifiers that can be received by the in-vehicle electronic device, and a data generator that dynamically generates a payload amount per unit message,
The combination data of the message identifier and payload generated from the test data generator is supplied to the in-vehicle electronic device via the in-vehicle network, and the anomaly detector resets the in-vehicle electronic device, address error, or illegal Monitor at least one occurrence of an instruction interrupt,
The dictionary look contains a second message identifier, which is to be processed on a different second processing function to the first message identifier, and the first processing function to be processed by the first processing function,
A test apparatus for an in-vehicle network , wherein the payload is incremented by 1 byte from an assumed payload value corresponding to the message identifier, and the test is performed up to the maximum number of bytes of the protocol of the in-vehicle network. The vehicle-mounted network test apparatus according to claim 1,
A data generator constituting the test data generator generates a payload larger than the payload amount designed for the message identifier and supplies the payload to the in-vehicle network for testing. Test equipment. The vehicle-mounted network test apparatus according to claim 1 ,
The test data generator is composed of a dictionary storing message identifiers that can be received by the in-vehicle electronic device and a data generator that dynamically generates a payload amount per unit message,
A test apparatus for an in-vehicle network characterized in that a combination of the message identifier and payload data is exhaustively supplied to the in-vehicle network for testing. The vehicle-mounted network test apparatus according to claim 1,
When the data generator constituting the test data generator interprets the on-vehicle electronic device as an address value, it generates a reset interrupt in accordance with the reset vector, or generates an address error out of the address boundary. Generates at least one factor that causes an unusual operation that can be detected by the anomaly detector by generating an illegal instruction interrupt by instructing the storage location of an illegal or undefined instruction. And an in-vehicle network testing device characterized in that the payload content of the transmission message is used. The vehicle-mounted network test apparatus according to claim 1,
The in-vehicle network test apparatus , wherein the in-vehicle network includes CAN . The vehicle-mounted network test apparatus according to claim 1,
The in-vehicle network testing apparatus according to claim 1 , wherein the in-vehicle network includes CAN FD . The vehicle-mounted network test apparatus according to claim 1,
The in-vehicle network testing apparatus characterized in that the in-vehicle network includes Ethernet . The vehicle-mounted network test apparatus according to claim 1,
Step 1: Search the dictionary for message identifiers that can be received by the in-vehicle electronic device,
Step 2: Search for a payload expected value associated with the receivable message identifier,
Step 3: Increment the assumed value,
Step 4: Compare the assumed value with the protocol upper limit value, determine whether the assumed value exceeds the protocol upper limit value,
Step 5: If the assumed value does not exceed the protocol upper limit value, the combination data is generated and supplied to the in-vehicle electronic device , the in-vehicle network testing device. The vehicle-mounted network test apparatus according to claim 1,
The anomaly detector detects the reset interrupt;
The in-vehicle network testing apparatus, wherein the reset interrupt is monitored by the abnormality detector . The vehicle-mounted network test apparatus according to claim 1,
The anomaly detector detects the address error;
The in-vehicle network testing apparatus, wherein the address error is monitored by the abnormality detector . The vehicle-mounted network test apparatus according to claim 1,
The abnormality detector detects the illegal instruction interrupt;
An in-vehicle network testing apparatus, wherein the abnormality detector monitors occurrence of the illegal instruction interrupt .