Fuzzing on Automotive Security

The ECU. That was the service department prognosis on the root cause of thealways-on air bag safety light on my immaculate car. Ten years ago the cost for its replacement with after market part was at par with getting a new iPhone 8. Today, we could get four units for the same price and according to data from several research companies, the ECU market size in 2018 hovers between USD 40 to 63 billion.

ECU (Electronic Control Unit) is central to a vehicle electronic system. The average number of ECUs in today’s medium size car grows to around 40, but could be well over 100 with a highly engineered car as the increased integration of advanced driver assistance systems (ADAS), infotainment, powertrain and chassis electronics are becoming more prevalent. All of these units are interconnected with system buses to perform thousands of vehicle related functions. The move towards more code driven automotive requires complex embedded software and hardware interactions such as sensors driven collision avoidance by brake activation or skid mitigation due to loss of tractions.

Failure, Faults and Fuzzing
As a common means to measure and document the safety level of their systems, ISO 26262 defines requirements for systematic failure and hardware failure verification. The former is related to common design bugs identified with functional verification, while the later involves the use of fault injection to validate certain assumed safety mechanism functionality.

Random hardware failure in automotive domain is a probable event and its impacts could potentially be catastrophic. The process relating to its risk, analysis, remedies and metrics were captured in ISO 26262 functional safety standards among others.

As implied by its name, the triggering origin of such hardware faults could be random and could be external to the subjected system such as an extreme ambient temperature increase due to a mechanical malfunction or an electronic interference. They can however, be modeled based on its inherent characteristics and classified using a formal COI (Cones of Influence). COI helps visualize the potential correlation between the probability of a fault causing a safety critical failure through analyzing six different categories: safe, single-point, residual, detected dual-point, perceived dual-point, latent dual-point.

A common form of fault injection method is called fuzzing(fuzz testing), which involves applying anomalous input stimulus to a system to see how it handles it. It is a form of vulnerability analysis and testing derived from the early day of software stress test, some may refer it as the ultimate of black-box approach to security testing. The main benefit of fuzzing includes a minimal up-front effort in capturing the test patterns and optional understanding of DUT (Device Under Test) specifications.
Fuzzing classification is based on the premise of how much prior knowledge assumed on the DUT. A minimal understanding causes more reliance on randomness and mutation based anomalies (a.k.a dumb fuzzing), while having some understanding on the DUT (such as protocol used) leads to fuzzing with generated based anomalies (smart fuzzing). Figure 2 illustrates how fuzzing process on a DUT entails.

Virtual Prototyping and Security
Combining both fuzzing and virtual prototyping delivers many benefits over conventional hardware centric approaches to security testing. Software driven data acquisition and test profiling during debugging steps provide automation and less costly implementation.

Vista Virtual Prototyping is part of Mentor Vista™ platform that provides an early hardware functional model prior to its availability and can run software on embedded processor models at speeds on-par with the actual hardware. It is tightly integrated withSourcery™ CodeBench Virtual Edition to provide additional debug capabilities related to complex software/hardware interactions and the ability to optimize the software to meet final product performance and power goals. Vista has non-intrusive tracing technology and accommodates the use of flexible interfaces to inject various faults and/or packets based on interface protocols. Bypassing physical connection between fuzzing tools and DUT can be done as well in virtual prototyping platform by directly embedding the interfaces models in software.

FFRI, a Tokyo-based computer security firm with global presence demonstrated the use of automated fuzzing coupled with Mentor Vista Virtual Prototyping and FFRI’s Raven testing suite (as fuzzer) to eliminate security vulnerabilities in vehicle ECU under development. As illustrated in Figure 4, the test environment involves a vulnerable software application susceptible to stack-based buffer overflow and monitoring scheme of packet transactions at the guest network interface port to identify the HTTP packet that triggers buffer overflow in the target application.

To simplify the analysis step, a GNU debugger is linked to the system and used as the analysis tool. This enables performing virtual prototyping based testing remotely and automating fuzzing tests in the Vista VP environment through scripting on the host side –allowing a restart should a freeze is encountered.

As a case example, a segmentation fault occurs as a consequence of a stack-buffer overflow event and halts the application –allowing analysis of all frames in the stack. FRRI was able to root cause the segmentation fault through the debugging step, and believes that such approach can be expanded to cover also more complex systems security testing and analysis.
Using this method, a profile can be generated (as shown in Figure 5) and used to identify weak points, thus improving the overall system security robustness against potential side-channel attacks (such as timing or power analysis-based), which may acquire confidential system information.

With the exploding number of code content in modern cars (embedded as part of increased ECU numbers), it is imperative to devise a method to detect safety defects early in the automotive software development process –since deferring fault injection based testing late in the ECU development cycles is costlier. The neat thing about using virtual prototyping coupled with fuzzing allows multi-scenarios testing early and provides cold reboot flexibility.

For more details on Vista check HEREand for FFRI whitepaper check HERE