Arm IDA and Cross Check: Reversing the Boeing 787's Core Network

## Overview

In this presentation, researcher Ruben Santamarta analyzes the core network architecture of the Boeing 787, focusing on the boundary mechanisms designed to isolate critical flight avionics from passenger and external systems. While aircraft communications historically relied on physical isolation, modern network-centric airframes share interconnects regulated by security boundaries. Santamarta examines the primary intermediary device responsible for this segregation: the Core Network Cabinet (CNC).

The research was initiated after discovering an exposed, public Boeing server in September 2018 containing documentation, a virtual machine used by Boeing engineers to VPN into their network, and production-grade ("black level") firmware for both the Boeing 787 Core Network Cabinet and parts of the Boeing 737. Lacking direct physical access to an aircraft, the research methodology combined binary reverse engineering, technical documentation analysis, multimedia materials, and key US patents.

## Boeing 787 Network Architecture and Segregation

The Boeing 787's internal architecture links multiple distinct network domains: * **Common Data Network (CDN):** The high-integrity avionics network hosting safety-critical functions via the Common Core System (CCS). Built on ARINC 664 (avionics Ethernet), it relies on General Processing Modules (GPMs) running a type-1 bare-metal hypervisor (VxWorks 653) with partitioned applications, alongside Remote Data Concentrators (RDCs) bridging CAN bus and legacy sensor buses. * **Isolated Data Network (IDN):** Connects secure devices not directly critical to flight safety, such as the flight data recorder (black box) and electronic flight bags. * **Open Data Network (ODN):** Connects non-critical, potentially hostile systems, including passenger In-Flight Entertainment (IFE).

The **Core Network Cabinet (CNC)** serves as the gateway between the outside world / non-critical networks and the internal avionics. Inside the CNC, the **Crew Information System (CIS)** manages communication between these three domains using key hardware modules: 1. **Ethernet Gateway Module (EGM):** An embedded Linux device implementing boundary firewalls and packet routing via `iptables`. 2. **CIS/MS File Server Module:** A commercial off-the-shelf (COTS) board powered by a Pentium M CPU running an uncertified version of VxWorks 6.2. It supports user-mode real-time processes (RTPs) and kernel-mode operations, utilizing custom packet filtering (`F_only_U_believe`). 3. **Network Interface Module (NIM):** The end system connecting directly to ARINC 664 and the CDN, configured by proprietary Level A certified binary rules.

## Attack Path and Vulnerability Findings

The primary attack scenario attempts to breach safety boundaries starting from an untrusted domain (ODN) and pivoting step-by-step into the critical avionics network (CDN): * **Attack Flow:** `ODN (e.g., IFE)` $\rightarrow$ `EGM Firewall Rule Abuse` $\rightarrow$ `CIS Network Service Exploitation` $\rightarrow$ `IDN Switch` $\rightarrow$ `NIM Filtering Rules` $\rightarrow$ `CDN Switch / Avionics`.

Reverse engineering the uncertified VxWorks 6.2 environment revealed significant security debt across the CIS firmware (14 real-time processes and 15 shared libraries, including a custom-compiled `libc`): * **Vulnerability Landscape:** Hundreds of calls to insecure standard C functions (`sprintf`, `strcpy`, `strcat`), leading to potential integer overflows, out-of-bounds reads/writes, buffer overflows, and memory corruption. * **EGM Firewall Bypass & Remote Code Execution (RCE):** The EGM configuration (`S24_EGM_config`) explicitly permitted traffic from the IFE router on the ODN (`.40.2`) to the CIS via the `FTS_manager` service on port `16005`. * **TFTP Opcode Exploitation:** The `FTS_manager` service, which handles TFTP-based transfers, reads an incoming packet up to 200 bytes. It indexes an opcode byte directly into an array to locate strings for log generation into a 400-byte buffer. While the 200-byte input payload itself cannot directly overflow the 400-byte buffer, Santamarta demonstrated that an out-of-bounds opcode index allows referencing arbitrary strings located across adjacent `.data` and `.bss` sections, supplying a long enough target string to overflow the stack buffer and achieve remote code execution in user mode.

## Research Takeaways

* **Architectural Boundaries vs. Physical Isolation:** Despite historical industry claims of physical isolation, modern avionics rely heavily on logical segregation implemented across intermediate gateway devices and COTS hardware. * **Avionics vs. COTS Gateway Rigor:** While the core avionics (CDN) adhere to rigorous DO-178C Level A assurance standards and certified RTOS hypervisors (VxWorks 653), the boundary gateway modules (such as the CIS file server) ran uncertified software stacks lacking basic modern exploit mitigations. * **Pivoting Feasibility:** Misconfigured firewall rules combined with memory corruption bugs in non-safety-certified gateway firmware create theoretical pathways for an attacker situated in the passenger domain (ODN) to bridge into core aircraft networks.