Why You Need Fuzz Testing in Advanced Auto-Driving Systems – New Stack

Cars are becoming more connected and more complex. While fully autonomous vehicles are still a ways off, there’s a good chance your car already has an advanced driver assistance system that controls activities like adaptive cruise control, lane guidance, and active braking.

Developers are changing the way automotive safety and security works with these evolving and connected hardware and software features.

In the world of the connected automobile, keeping safety in mind is as important as designing for physical security.

If anything demonstrates that every business is a software business, it is the evolution of automobile manufacturing. As cars become more automated and have access to over-the-air updates, they naturally become more connected, which means they present a new attack surface for hackers. An attack can take the form of stealing important information from a keyless car system, enabling break-in, running the chip in test or debug mode to gain system privileges, or hacking an infotainment system with a virus via a mobile handset. can take. Whatever the method of attack, if a system is easily breached, it is simply vulnerable.

Advanced driver assistance systems are divided into different chips, called systems on a chip (SoCs). These chips connect sensors to actuators via interfaces and high-performance electronic controller units (ECUs). As the number of sensors are being integrated into automotive systems to enable new capabilities, build safety and quality become integral at all stages of the design life cycle. Automotive design requirements are changing, and going forward, safety and security should be an inseparable consideration for automotive development.

Creating a Safe Path to Vehicle Autonomy

Most vehicles that have advanced driver assistance systems are currently operating at Level 2, partial automation, meaning the vehicle can perform certain tasks, yet a human operator can take control at any time. Such systems rely on sensor systems which may include lidar, radar, ultrasound, infrared and camera systems.

This level of intelligence, occurring locally or distributed within the vehicle itself, requires a significant amount of processing power. This means that fully connecting the vehicle to the cloud is not a favorable option as any delay between sending and receiving information is likely to endanger the safety of passengers, as well as potential interference to vehicles. It is also to be left open.

All of these have major implications for the future of safe automotive design. In line with the ISO 26262 functional safety standard for production vehicles, any underlying hardware and software must have functional protection to reduce the risk of failure – and potential disaster. If that is not enough, an equally high level of protection is necessary for automotive systems to function as designed.

Opaque box testing for auto safety and security

While safety has always been an important consideration in automotive design, as the industry evolves to rely on automated systems, safety must go hand in hand with safety. The combination of the two is becoming an important design benchmark for teams around the world.

Software developers have long relied on “transparent box” tools and services such as static application security testing (SAST) and software structure analysis (SCA) to address security and quality flaws 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 important as these tests are, they are not enough when you are dealing with an attack surface that advanced driver assistance systems exist.

This is why you also need “opaque box” testing. Opaque box testing involves testing a system without 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 the kind of expected and unexpected user actions that malicious actors may use.

Opaque out of the box tools like Dynamic Application Security Testing (DAST) and Fuzz Testing can help your team ensure that the software code you protect 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 failed underlying code assertions. Because fuzzing tests without access to the source code, it provides the best visibility into how an attacker might try to breach your system. A rigorously fuzz-tested network element is hardened against a broad spectrum of security threats.

Use Case: Denial-of-Service Vulnerabilities in the Zephyr Bluetooth LE Stack

A recent Synopsis Cybersecurity Research Center vulnerability report includes eight vulnerabilities discovered in the Bluetooth LE link layer and the L2CAP implementation in Zephyr’s Bluetooth LE controller.

Since Bluetooth controls most current automotive communication and entertainment systems, this suite of vulnerabilities could have major implications for driver safety.

All reported vulnerabilities can be triggered from within range of Bluetooth LE. Triggering the vulnerability does not require authentication or encryption. The only requirement is that the device is in ad hoc mode and is accepting connections.

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 freezes, the behavior of the target device depends on whether assertions are enabled and if an error handler for fatal errors is present. It is common for the device to restart itself in case of a hard fault. Taking advantage of some other vulnerabilities an attacker can use it to restart the device over the air with a single packet. In some circumstances, freezing can lead to remote code execution.
• deadlock: Certain vulnerabilities can cause a situation in which the target device misbehaves in a way that prevents other devices from connecting to it. The target must be restarted to recover to normalcy. Rebooting a vehicle in motion can put drivers and passengers at risk.
• Information leak: This vulnerability makes it possible for an attacker to gain access to potentially confidential information such as encryption keys or information about memory layout. This type of vulnerability can also be exploited when an attacker is trying to bypass mitigation techniques such as address space layout randomization, which is not present in Zephyr.

These vulnerabilities were discovered when Synopsys ran tests on its products. Since Zephyr’s Bluetooth LE controller is used as a part of the Synopsys Defensics Bluetooth LE fuzzing solution, the lowest layers of Zephyr’s Bluetooth LE stack were fuzz-tested using the Defensics Bluetooth LE test suite. So here we have an example of an opaque box fuzz-testing surfacing vulnerability that could not be detected using transparent box testing methods.

summary

The automotive industry is changing on many levels, but perhaps the most notable is the development of smarter, safer cars. The teams responsible for the automotive applications of today and tomorrow will need to think more holistically about both safety and security.

Synopsys can help with the full suite of SAST, SCA, DAST and fuzzing tools to ensure that the software these vehicles rely on is as safe and secure as the physical security features incorporated into automotive design Is. This becomes even more important as designers and developers work to bring fully autonomous vehicles on the road near you.

Feature image via Pixabay.