Security preprint tests five cFS privilege-abuse paths in NASA simulator

A security preprint posted on August 14 reports that a normally integrated but malicious application could use five legitimate NASA core Flight System mechanisms to affect software and simulated spacecraft hardware outside its assigned role. All five experiments produced the effects predicted by the researchers in NASA’s Operational Simulator for Space Systems, or NOS3. The work documents post-compromise containment weaknesses in a controlled virtual spacecraft; it does not report that an operational mission, spacecraft or NASA network was breached.

Jack Vanlyssel, Gruia-Catalin Roman, Kendra Cook, Sazzadur Rahaman and Afsah Anwar wrote the paper, which the arXiv record describes as submitted for consideration at an IEEE conference. Its threat model begins after malicious code has entered one otherwise normal onboard component, possibly through a compromised dependency, update or insider action. The researchers did not model how that first foothold was obtained. After it began running, their test application used only documented services and access already available to it—no additional software flaw, operating-system modification or privilege escalation.

The five demonstrated paths

The first experiment, called peer lifecycle override, used cFS Executive Services to delete, restart and reload an unrelated mission application. Status data, telemetry and the target’s expected output confirmed the changes. Because the experimental app neither owned nor supervised its target, the result showed that one peer could control another peer’s lifecycle through an exposed system service.

The second path tested sender identity. The malicious app sent a command with an arbitrary message identifier, function code and payload, while the receiver obtained no authenticated identity for the producer. In a second mode, the app emitted a telemetry event using another application’s identifier. The experiment therefore showed a gap between the identity cFS assigns internally to an application and the identity preserved when applications exchange messages or generate events.

The third experiment sent a correctly formatted command through the cFS Software Bus to an unrelated simulated device. The command was accepted and the device changed state. In the evaluated configuration, packet format and routing determined whether the command reached its destination; the bus did not require an authenticated sender identity or a permission tied to the calling application.

The fourth path examined what operators could see. The researchers issued the same simulated-device command once from the intended controller and once from their experimental app. Both commands caused the same visible effect, while the available event, executive, performance, telemetry, Software Bus, command-response and ground-station records did not reliably distinguish their origins. The malicious app could also suppress events, alter them or assign misleading application identifiers.

The fifth experiment used persistent state to resume altered behaviour after a processor reset. The app saved attacker-controlled state, changed its runtime behaviour and triggered the reset. During normal startup it recovered that state and resumed the changed behaviour without another external command. This result tested persistence inside the simulator; it was not a demonstration that an attacker had survived a reset on a spacecraft in service.

Why normal privileges crossed component boundaries

The researchers traced those results to five connected architectural properties: execution, identity, communication, observability and persistence. In the cFS configuration they examined, applications run as peer tasks in one shared address space and use a common interface to reach lifecycle, messaging, event, table and time services. Application identifiers are maintained within the core Flight Executive but are not carried as authenticated identities across all messages and shared-service calls. Logging is incomplete and partly application-controlled, while startup scripts and the Critical Data Store can restore executable or application state after a reset.

The team also checked the default NOS3 configuration’s 18 operational components, covering cameras, sensors, navigation, communications, power, security and onboard data processing. Every component met the preconditions for at least one of the five attack classes, according to the paper. That is not a claim that every component supported every path or that every cFS mission exposes the same surface: some components lacked a device, interface or persistent resource needed for a particular experiment, and mission-specific controls can change the result.

What NOS3 can—and cannot—establish

NOS3 is a software test bed, not an orbiting spacecraft. NASA describes it as an open-source environment that combines flight software, a ground interface, dynamics and environment simulations, and software models of spacecraft hardware. The researchers said it preserved the application privileges, messaging interfaces and trust relationships needed for their tests. They also acknowledged that it does not reproduce every processor, timing, hardware-protection, communications or recovery property of an operational spacecraft.

The distinction matters because cFS is a reusable framework rather than one fixed flight load. NASA says its layered, component-based framework has supported more than 40 missions, while its public guidance notes that the open-source bundle is not itself a flight distribution; missions select applications and add hardware, operating-system and programme-specific controls. The preprint therefore supplies evidence about the evaluated cFS/NOS3 architecture and its default configuration, not a vulnerability census for every spacecraft that has used cFS.

A trust problem the authors found beyond cFS

The paper separately reviewed F Prime, KubOS, the NanoSat MO Framework and CORDET-C2. Across all five frameworks, including cFS, the authors reported missing authenticated attribution, mandatory authorisation and protected auditing at the framework level. They rated isolation as weak in cFS, F Prime and CORDET-C2 and partly improved in KubOS and NanoSat MO, whose process separation still depends on deployment choices. This comparison came from documentation, API references and targeted source inspection; the researchers did not run the five NOS3 experiments against the other frameworks.

Their proposed remedies follow the same five-part model. Flight-software frameworks would preserve authenticated application identity across messages, services, devices and persistent-state changes; enforce policy at those boundaries; isolate components with narrowly scoped capabilities; create tamper-resistant audit records; and recover both software and security-relevant state from an independently trusted baseline. The paper presents these as architectural design directions, not as fixes tested against the five demonstrations.

The supported finding is narrow but concrete: once the researchers placed malicious code inside a normal cFS component in NOS3, that component could extend its influence through legitimate interfaces, and the default environment did not reliably contain or attribute all five actions. The study does not estimate the chance of an initial compromise, establish that the paths are present in every mission build or document an incident in flight. Peer review and independent reproduction were not available in the arXiv record; further testing would need to examine specific mission configurations and operational protection layers rather than assume the simulator result transfers unchanged.