Why You Need Fuzz Testing in Advanced Auto-Driving Systems
Cars are becoming more connected and more complex. While fully autonomous vehicles are still a way off, there’s a good chance that your car already has advanced driver assistance systems that control activities like adaptive cruise control, lane guidance and active braking.
Developers are changing the way they approach automotive safety and security with these evolving and connected hardware and software features.
In a world of connected automobiles, it’s as important to take security into account as it is to design for physical safety.
If anything demonstrates that every business is a software business, it’s the evolution of automobile manufacturing. As cars become more automated and gain access to over-the-air updates, they naturally become more connected, which means they present a new attack surface for hackers. An attack might take the form of stealing key information from a keyless car system to enable a break-in, running a chip in test or debug mode to gain system privileges, or hacking an infotainment system with a virus via a mobile handset. Whatever the attack approach, if a system is easily breached, it is simply unsafe.
Advanced driver assistance systems are partitioned into various chips, called systems on a chip (SoCs). These chips connect sensors to actuators through interfaces and high-performance electronic controller units (ECUs). As the number of sensors being integrated in automotive systems increases to enable new capabilities, building security and quality into all stages of the design’s life cycle becomes integral. The requirements for automotive design are changing, and going forward, security and safety must be inseparable considerations for automotive development.
Forging a Safe Path to Vehicle Autonomy
Most vehicles that have advanced driver assistance systems are currently operating at level 2, partial automation, which means that while the vehicle can perform some tasks, the human operator can still take control at any time. Systems like these rely on sensor systems that may include lidar, radar, ultrasound, infrared and camera systems.
This level of intelligence calls for a remarkable amount of processing power to take place locally or be distributed within the vehicle itself. This means connecting the vehicle solely to the cloud isn’t a favorable option since any amount of delay between sending and receiving the information has the potential to endanger the safety of the passengers in motion, as well as leaving vehicles open to potential interference.
All of this has major implications for the future of secure automotive design. In line with the ISO 26262 functional safety standard for production vehicles, any underlying hardware and software must have functional safety built in to minimize the risk of failure — and potential catastrophe. If that isn’t enough, security of an equally high level is essential for the automotive system to work as designed.
Opaque Box Testing for Auto Safety and Security
While safety has always been a key consideration in automotive design, as the industry evolves to rely on automated systems, safety must go hand in hand with security. Combining the two is becoming a critical design criterion for teams worldwide.
Software developers have long relied on “transparent box” tools and services like static application security testing (SAST) and software composition analysis (SCA) to address security and quality defects on the coding side.
Transparent box testing tools identify bugs and security risks in proprietary source code, third-party binaries and open source dependencies, as well as runtime vulnerabilities in applications, APIs, protocols and containers. As crucial as these tests are, they’re not sufficient when you’re dealing with an attack surface as large as the ones advanced driver assistance systems present.
This is why you also need “opaque box” testing. Opaque box testing involves testing a system without having any prior knowledge of its internal workings. A tester provides an input and observes the output generated by the system under test. This makes it possible to identify how the system responds to expected and unexpected user actions of the sort that malicious actors might use.
Opaque box tools like dynamic application security testing (DAST) and fuzz testing can help your team ensure that the software code you’ve secured from within cannot be breached from the outside.
Fuzzing is a particularly useful software-testing technique because it tests your code by inputting invalid, unexpected or malformed data. The program is then monitored for exceptions such as crashes or failing built-in code assertions. Because fuzzing tests with no access to the source code itself, it provides the best visibility into how an attacker might try to breach your systems. A rigorously fuzz-tested network element is hardened against a wide spectrum of security threats.
Use Case: Denial-of-Service Vulnerabilities in Zephyr Bluetooth LE Stack
A recent Synopsys Cybersecurity Research Center vulnerability report covered eight vulnerabilities discovered in the Bluetooth LE link layer and L2CAP implementation in Zephyr’s Bluetooth LE controller.
Since Bluetooth controls so many of most current automotive communication and entertainment systems, this suite of vulnerabilities could have big implications for driver safety.
All the reported vulnerabilities can be triggered from within the range of Bluetooth LE. Triggering the vulnerability does not require authentication or encryption. The only requirement is that the device is in advertising mode and accepting connections.
The vulnerabilities can be divided into three high-level categories.
- Freeze: This vulnerability makes it possible for an attacker to remotely cause a freeze or assertion failure on a target device by sending malformed input. In the case of a freeze, the behavior of a target device depends on whether assertions are enabled and if the error handler for fatal errors exists. It is common for the device to restart itself in case of hard faults. An attacker might use this to restart the device over the air with single packet when exploiting some other vulnerabilities. In some circumstances, freezing may lead to remote code execution.
- Deadlock: Some of the vulnerabilities can lead to a situation in which the target device misbehaves in a way that prevents other devices from connecting to it. The target must be rebooted to recover to normal state. Rebooting a vehicle in motion could endanger drivers and passengers.
- Information leak: This vulnerability makes it possible for an attacker to gain access to potentially confidential information like encryption keys or information about memory layout. This type of vulnerability might also be used when an attacker is trying to bypass mitigation techniques like address space layout randomization, which is not present in Zephyr.
These vulnerabilities were discovered when Synopsys ran tests on its own products. Since Zephyr’s Bluetooth LE controller is used as a part of the Synopsys Defensics Bluetooth LE fuzzing solution, Zephyr’s Bluetooth LE stack’s lowest layers were fuzz-tested using Defensics Bluetooth LE test suites. So here we have an example of opaque box fuzz-testing surfacing vulnerabilities in itself that could not have been detected using transparent box testing methods.
Summary
The automotive industry is transforming on many levels, but the development of smarter, safer cars is perhaps the most noteworthy. Teams responsible for the automotive applications of today and tomorrow will need to think more holistically to factor in both safety and security.
Synopsys can help with a full suite of SAST, SCA, DAST and fuzzing tools to ensure that the software upon which these vehicles rely is as safe and secure as the physical safety features that have been incorporated into automotive design. This becomes even more crucial as designers and developers work to bring fully autonomous vehicles to a road near you.