Why Your Next Embedded Target Needs a Safety-Critical Security Audit

TLDR: Aviation systems are shifting from isolated, federated architectures to highly connected networks, creating new attack surfaces for intentional unauthorized electronic interactions (IUEI). This research demonstrates how attackers can exploit these interdependencies to bypass safety-critical logic, leading to uncommanded mode changes or denial-of-service. Security researchers must move beyond traditional web-based threat modeling and start auditing the interplay between safety design assurance levels (DAL) and security assurance levels (SAL) to identify non-linear failure paths.

Modern avionics are no longer the black boxes they were twenty years ago. As manufacturers push for higher data throughput and real-time connectivity, the underlying architecture of aircraft systems has evolved from isolated, single-purpose components to complex, interconnected networks. This shift introduces a critical problem: the traditional safety mechanisms designed to handle random hardware failures are increasingly vulnerable to intentional, malicious manipulation. When you are looking at an embedded target, you are no longer just looking for a buffer overflow or a hardcoded credential. You are looking for a way to inject data that forces a system into an unsafe state by exploiting the trust relationship between redundant, safety-critical modules.

The Mechanics of Intentional Unauthorized Electronic Interaction

The core of this research centers on the concept of IUEI, or Intentional Unauthorized Electronic Interaction. In the context of DO-356A, which defines the cybersecurity development objectives for aircraft systems, IUEI is the primary threat vector. Unlike a bird strike or a cosmic ray causing a bit flip, an IUEI is a deliberate, targeted attack.

The danger lies in how these systems handle data. Consider a standard linear chain of three systems: System A, System B, and System C, which eventually feeds a user display. System B performs a simple operation, such as adding a constant to an input. If an attacker can modify the memory or code of System B, they can change that operation. If the system is not designed to verify the integrity of its internal state, this erroneous data propagates through the chain. By the time it reaches the user display, the pilot is presented with misleading information, potentially triggering a catastrophic failure.

Mapping SAL to DAL for Better Threat Modeling

Most security researchers are familiar with OWASP categories, but in the aerospace sector, the focus is on DAL (Design Assurance Levels). DALs are assigned based on the severity of a failure, ranging from Minor to Catastrophic. The research highlights that security teams must map these to SALs (Security Assurance Levels).

The critical takeaway for a pentester is that these levels are not just compliance checkboxes. They define the design objectives for the system. If you identify a system with a DAL B rating, you know that the system is safety-critical and that any manipulation of its data flow is a high-impact finding. The most effective way to test these systems is to look for non-linear entry points. If you can inject a mode command into System C that back-propagates to System A, you have effectively bypassed the safety checks that were only implemented for the forward-flowing data.

Exploiting Interconnectedness

During an engagement, you should focus on the points where safety and security overlap. A common, yet often overlooked, vulnerability is the lack of cross-checking between redundant systems. If you can flood the interface of System C with junk data, you might trigger a denial-of-service condition. If the system is not designed to handle this, it may crash or, worse, default to an unsafe state.

To mitigate this, developers are increasingly using memory hashing. By hashing the memory space of a system, they can detect unauthorized modifications. However, as a researcher, your goal is to find the gaps in this implementation. For example, if System B hashes its memory but System B-prime (the secondary, redundant system) does not, you have a clear path to exploit the discrepancy.

// Conceptual example of memory integrity check
if (calculate_hash(memory_region) != expected_hash) {
    trigger_safety_shutdown();
}

This is where the real work happens. You are looking for the "how" of the system. How does it handle a mode change? How does it verify the validity of an input? If you can find a way to send a command that is technically valid but contextually incorrect, you can force the system to perform an action that it was never intended to do.

Defensive Strategies for Embedded Systems

Defenders must move toward a unified development model. It is no longer sufficient to treat safety and security as separate silos. Every safety requirement should be evaluated for its security implications, and every security mitigation must be tested against the system's safety-critical failure modes. If you are working with a blue team, push them to implement cross-checking between redundant systems and to ensure that all critical data paths are protected by integrity checks, such as cryptographic signatures or robust memory hashing.

The industry is still learning how to secure these highly connected architectures. As a researcher, you have the opportunity to shape this process by identifying the non-linear failure paths that traditional safety analysis misses. Stop looking for the easy win and start looking at the architecture. The next time you are auditing an embedded system, ask yourself: what happens if I change the state of this system, and how does that change propagate to the rest of the network? The answer to that question is where the most critical vulnerabilities are hiding.