Context: This is a science-fantasy world with intelligent non-anthro animals living in harmony. Think Zootopia but with regular animal shaped animals that are also quite a bit more technologically advanced. One of their main forms of transportation is the hovercraft; which is used both for local urban transportation, hopping from point to point within their lush forest cities; as well as long haul and intercity transport. These hovercrafts employ a high degree of automation, and air traffic control is generally done not with radio calls back and fourth between the pilot and controller like in our aviation network, but by having the hovercraft connect directly to a dispatch server to receive instructions, which are then displayed to the pilot. This makes the aviation network more efficient as a central air traffic control node can precisely coordinate hovercraft movements to make the most use out of the infrastructure. However, due to their reliance on the computerized system, a security vulnerability in said system would be disastrous.

The following is an article from the Feline Ministry of Security, detailing a recently patched 0-day vulnerability found in an air traffic control protocol used the Feline hovercraft network. Imagine a bunch of developers who are literal cats scrambling to fix this issue the instant it was discovered before someone hacks their hovercraft network and starts remotely taking control of their hovercrafts to crash into trees that have buildings in them, crash into flocks of birds, and other woodland creature acts of terrorism.

CVE109-10028FL: DispatchToElsewhere, a memory corruption vulnerability in FDTMS resulting in remote code execution on Feline Ministry of Transportation hovercrafts

This article pertains to the public disclosure of a now patched security vulnerability in the aircraft-side implementation of Flight Dispatch and Traffic Management System (FDTMS) developed by the Feline Ministry of Transportation (FMT). This vulnerability affected all hovercrafts operated by the Feline Ministry of Transportation, and resulted in arbitrary code execution in the primary flight computers of FMT hovercrafts.

The Flight Dispatch and Traffic Management System is an air traffic control protocol that allows advanced coordination of hovercraft operations within Feline Territory. The codebase for the system is extensive, but for this article, we will only focus on the problem component: the buildDispatchTable function which is responsible for parsing a digital flight plan into a table of procedures that the onboard computer will follow during the flight.

When a flight plan is transmitted to the hovercraft, buildDispatchTable is invoked. As its name suggests, it parses the flight plan data to construct an Dispatch Table in the onboard computer’s memory, which contains navigation information that is to be followed during the flight. A typical dispatch table is shown below for a flight between Moonpeak Airport (MPK) in Feline Territory to Central Valley Airport (CVY) in the Unified Territories. The fact that this fight crosses a territorial boundary is relevant to the vulnerability.

EntryID EntryType Name SetAttributes Location EstimatedTime
0 DispatchStart FMT1002 flightID=FMT1002; radioID=FMT1002; origin=MPK; originLandingPadID=2; dest=CVY; startingTerritory=FelineTerritory; startingRegion=MoonDistrict; atcServerURL=fdtms://transportation.feline.gov/atc/MoonDistrict; serviceType=Commuter (-130.993234, -47.997826) 12:00:00
1 FlightStart MPKL2 departureCorridorID=39; speed=100 (-130.993234, -47.997826) 12:00:00
2 WayPoint/DepartureCorridorExitPoint MPK927 heading=305.1; speed=300; alt=1000 (-131.017368, -47.997826) 12:02:00
3 RegionChange AlderDistrict atcServerURL=fdtms://transportation.feline.gov/atc/AlderDistrict (-130.994368, -47.997826) 12:19:13
4 WayPoint ALD103 heading=305.1; speed=1000; alt=1700 (-129.083812, -47.997826) 12:21:02
5 TerritoryChange UnifiedTerritories/FeatherDistrict atcServerURL=fdtms://transportation.ut.gov/atc/alternateProtocols/Feline/FDTMS/region/FeatherDistrict (-131.001929, -48.725192) 12:45:51
6 WayPoint FET972 heading=307.9; speed=1000; alt=1700 (124.138493, -47.997826) 13:00:05
7 RegionChange CommonDistrict atcServerURL=fdtms://transportation.ut.gov/atc/alternateProtocols/Feline/FDTMS/region/CommonDistrict (-122.904928, -46.203840) 13:37:19
8 Waypoint/ApproachCorridorEntryPoint CVY671 approachTo=CVY; requestApproachCorridorID=81; requestLandingPadID=9; defaultAction=HoverInPlace/Wait; triggerNextEntry=OnAtcAuthorization (-122.301937, -44.927394) 13:41:32
9 ApproachStart CVYL9 approachCorridor=81; targetLandingPad=9 (-122.904928, -46.203840) 13:45:00
10 ApproachEnd CVYL9 (-122.804221, -46.103840) 13:50:00
11 FlightEnd FMT1002 (-122.804221, -46.103840) 13:50:00
11 DispatchEnd FMT1002 clear all (-122.804221, -46.103840) 13:50:00

As shown in the table, when the hovercraft crosses an internal boundary within a given territory, a RegionChange entry is used. However, when the hovercraft crosses a territorial region, which also necessitates a region change, the standard prescribes that only the TerritoryChange entry is needed, and the region name included within it. However, it is also possible to omit the region name in the TerritoryChange entry, and separately issue a RegionChange.

The buildDispatchTable function did not take into account the possibility of a region change being separately supplied in the case of a territory change in the way it calculated the table size and therefore how much memory to allocate for the construction of the table. Therefore, a malicious dispatch message could be crafted to overflow the table and inject machine code into memory. An outside actor spoofing radio signals on government frequencies can send a malicious dispatch message to any hovercraft in range, and because the dispatch table is constructed before the cryptographic keys of the dispatch message is checked, remote code execution can be achieved by anyone, as the exploit is accessible before the authenticity of the message is verified. A pilot would only see a “Dispatch rejected due to key error” message, at which point the exploit has already gone through. Additionally, the onboard computer will simply discard the malicious dispatch table and reload the previous valid dispatch table upon failing to verify its authenticity, effectively deleting evidence of the exploit’s entry point.

The implications of this vulnerability is severe, as an attacker can gain remote control of the hovercraft and its flight control systems, and can issue malicious commands with fatal results. Moreover, the possibility of a Feline hovercraft being used to commit acts of terrorism in another territory significantly raises the urgency of this issue.

Exploit proof of concept

The Feline Ministry of Security is not aware of any live attacks using this vulnerability. However, we have verified that the following proof of concept could result in remote code execution. By hiding the payload in a malformed ATC server URL, we were able to send machine code to all the Feline hovercrafts we tested, running WhiskerOS versions 1.0 to 3.3 (the latest version) and FDTMS Client 5.1 or lower.

EntryID EntryType Name SetAttributes Location EstimatedTime
0 DispatchStart FMT1002 onError=LoadPreviousDispatch; atcServerURL=fdtms://null (-130.993234, -47.997826) 12:00:00
1 TerritoryChange UnifiedTerritories atcServerURL=fdtms://null (-131.001929, -48.725192) 12:00:00
2 RegionChange FeatherDistrict atcServerURL=fdtms://AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[Malicious Code Goes Here] (-131.001929, -48.725192) 12:00:00

Due to its need to directly interface with the hovercraft’s engines and flight controls protected by WhiskerOS Secure Mode, FDTMS executes in a privileged context, meaning any code execution in the software is able to bypass Secure Mode sandboxing and take direct control of the hardware. There is no way to secure the flight control computer once it has received a malicious dispatch message outside of turning it off and back on, which obviously cannot be done in flight. If the malicious payload includes a way to persist on the local storage device, the flight computer would need to be removed from the aircraft and have the entire system wiped and reinstalled in order to restore secure operation.

Response

All hovercrafts operated by the Feline Ministry of Transportation was grounded until their flight computer software was updated to fix the vulnerability. Hovercrafts already in flight were ordered to land immediately on the nearest available pad. The vulnerability has now been patched for the entire FMT fleet.

Root Cause Analysis:

The following issues were identified as contributors to the existence of this vulnerability:

  1. Attempting to parse received data before checking cryptographic keys. In the future, no operations on received data should be performed before its origin and integrity are verified.

  2. Failing silently on a malformed dispatch message. If a hovercraft receives an invalid dispatch message, it should not automatically revert to the last valid state and report as ready for dispatch. Pilot and/or ATC intervention should be required to clear the error and the hovercraft should be inhibited from dispatch until such an action is taken. This would give aviation staff a chance to detect the attack before the hovercraft takes off.

  3. The dispatch message parser being more tolerant of malformed dispatch tables than necessary. If the standard prescribes that a region change and territory change should be a single entry, the parser should not accept separate entries.

  4. Executing more code in a privileged context than necessary, bypassing WhiskerOS Secure Mode. Only the modules that require system/hardware access should be given such privileges, not the entire FDTMS software suite. For example, the dispatch message parser does not need to be privileged.

  • early_riser@lemmy.radio
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    I like this a lot. My own conworld also involves quadrupedal sophonts (aliens rather than animals), and I’ve thought about writing RFCs for some of their communication protocols.

    YAP (yinrih ansible protocol) is a link layer protocol that manages messaging on an ansible link. Communication via ansible is very low bandwidth, meaning interplanetary networks look like 80s BBS’s or very very early (we’re talking still at CERN) websites. Ansibles use a kind of subspace called the Underlay. In order for two ansibles to communicate, they must contain wafers of tailstone shaved from the same monocrystal. Raw tailstone (or tailstone precursors) are mined and manufactured into monocrystals in a similar process to how silicon ingots are grown. At a certain point in this growth process, the crystal “locks”, and any wafers shaved from that monocrystal will only communicate with other wafers from the same monocrystal.

    The Underlay link is shared between all such wafers, similar to a shared wifi channel, so individual ansibles have to take turns sending frames. You can achieve full duplex communication by growing two seperate monocrystals, shaving two wafers from each, and placing one wafer from each crystal into two ansibles, with one serving as an RX interface and its partner on the other ansible serving as TX, and vice versa. In practice, this is only done on high capacity trunk lines, as more underlay links require more power.

    State actors can perform a supply chain attack by ordering a tailstone fab to grow monocrystals twice as large, break them in half, send half downstream to their customers and give the other half to the government, which can spy on communications made via those ansibles undetected or perform MITM attacks.

    YIP (yinrih internetworking protocol) is a network layer protocol that can serve either in a reliable or best effort configuration. While the address space of the original YIP was exhausted millennia ago and a new, but incompatible, YIP version developed with a much larger address space, there are still single-stack networks using the older protocol at the time of First Contact.

    Because yinrih evolved writing rather than inventing it, their digital age stretches back to the mid-Pleistocene despite only gaining sapience around the same time as humanity, and because yinrih live over 700 Earth years on average, their networks are built to be apocalypse-proof. With such robust networks with enough uptime to be measured in geologic terms, some networks are left to run forgotten for millennia. This gives rise to the discipline of cyberarcheology, which specializes in ferreting out these archeonets and uncovering their secrets. Cyberarcheologists are experts in defunct communication protocols, obsolete storage formats, and long outmoded hardware architectures.