Why do you need fuzz testing in advanced automatic driving systems?

Cars are increasingly connected and complex. Although fully autonomous vehicles are still a long way off, chances are your car already has advanced driver assistance systems that control activities such as adaptive cruise control, lane guidance and active braking. .

Developers are changing their approach to automotive safety and security with these scalable and connected hardware and software features.

In a world of connected automobiles, considering security is as important as designing for physical security.

If anything demonstrates that every company is a software company, it’s the evolution of automotive manufacturing. As cars become more automated and access 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 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. Regardless of the attack approach, if a system is easily hacked, it is simply dangerous.

Advanced driver assistance systems are partitioned into different chips, called systems on chip (SoC). These chips connect sensors to actuators through high-performance interfaces and electronic controllers (ECUs). As the number of sensors integrated into automotive systems increases to enable new capabilities, integrating safety and quality into all stages of the design lifecycle becomes an integral part. Automotive design requirements are changing, and in the future, safety and security must be inseparable considerations for automotive development.

Forging a Safe Path to Autonomous Vehicles

Most vehicles with advanced driver assistance systems currently operate at level 2, partial automation, which means that even though the vehicle can perform certain tasks, the human operator can still take control at any time. Systems like these rely on sensor systems that can include lidarradar, ultrasound, infrared and cameras.

This level of intelligence requires a remarkable amount of processing power that must take place locally or be distributed within the vehicle itself. This means that connecting the vehicle only to the cloud is not a favorable option, as any delay between sending and receiving information can endanger the safety of passengers in motion, as well as leaving vehicles exposed to potential interference. .

All of this has major implications for the future of secure automotive design. In accordance with the ISO 26262 A functional safety standard for production vehicles, all underlying hardware and software must have built-in functional safety to minimize the risk of failure – and potential disaster. If that’s not enough, an equally high level of security is essential for the automotive system to work as intended.

Opaque box test for automatic 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 safety. The combination of the two is becoming a key design criteria for teams around the world.

Software developers have long relied on “transparent box” tools and services such as static application security testing (SAST) and composition analysis software (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 crucial as these tests are, they aren’t enough when you’re dealing with an attack surface as large as those found in advanced driver assistance systems.

That’s why you also need an “opaque box” test. Opaque box testing involves testing a system without having any prior knowledge of its inner workings. A tester provides input and observes the output generated by the system under test. This helps identify how the system responds to expected and unexpected user actions, the kind that malicious actors might use.

Opaque box tools like dynamic application security testing (DAST) and fuzz test can help your team ensure that the software code you’ve secured from the inside can’t be hacked from the outside.

Fuzzing is a particularly useful software testing technique because it tests your code by entering invalid, unexpected, or malformed data. The program is then monitored for exceptions such as crashes or failing embed code assertions. Because fuzzing tests without access to the source code itself, it provides the best visibility into how an attacker might attempt to break into your systems. A rigorously tested fuzz network element is hardened against a wide range 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 many of the newest automotive communication and entertainment systems, this suite of vulnerabilities could have big implications for driver safety.

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

Vulnerabilities can be divided into three high-level categories.

• Freeze: The vulnerability allows 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 whether the error handler exists for fatal errors. It is common for the device to reboot itself in the event of a hardware failure. An attacker could use it to reboot the device wirelessly with a single packet when exploiting other vulnerabilities. Under certain circumstances, freezing may result in remote code execution.
• Dead end: Some of the vulnerabilities can lead to a situation where the target device misbehaves in a way that prevents other devices from connecting to it. The target must be restarted to return to the normal state. Restarting a moving vehicle could endanger drivers and passengers.
• Information leak: This vulnerability allows an attacker to gain access to potentially confidential information such as encryption keys or memory layout information. This type of vulnerability can also be used when an attacker attempts to bypass mitigation techniques such as address space layout randomization, which is not present in Zephyr.

These vulnerabilities were discovered when Synopsys performed tests on its own products. Since Zephyr’s Bluetooth LE controller is used as part of the Synopsys Defense Bluetooth LE fuzzing solution, the lowest layers of Zephyr’s Bluetooth LE stack were fuzz tested using the Defensics Bluetooth LE test suites. So here we have an example of opaque box fuzz test surface vulnerabilities that could not have been detected using transparent box test methods.

Summary

The automotive industry is transforming on many levels, but the development of smarter and safer cars is perhaps the most remarkable. Teams responsible for today’s and tomorrow’s automotive applications will need to think more holistically to consider both safety and security.

Synopsys can help you with a 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 that have been built into the automotive design. . This becomes even more crucial as designers and developers strive to bring fully autonomous vehicles to a road near you.

Characteristic picture Going through Pixabay.