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:
-
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.
-
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.
-
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.
-
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.
As an engineer, I have two responses to this. The first is that this is an incredibly cool bit of worldbuilding; you’ve done your work to actually show how such a critical vulnerability might arise and how it works.
The second, of course, is awestruck horror that they would let such a critical system exist without checking or validating inputs. It sounds like if a malformed but non-malicious message was sent, then the pilot would get a rejected dispatch message… but what would happen if a new dispatch needed to be issued mid-flight (e.g., due to weather or airspace disruption)? Would a different system handle that?
Either way, really cool addition.
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.
Thank you!
That would go through no problem, and since the hovercraft keeps track of what entry ID it’s currently executing, you can give it extra steps by rearranging/adding entries after the current one (ATC would also be able to poll the hovercraft for its current entry ID)
In the worst case scenario, ATC can call up the pilot, ask them to disconnect the autopilot, stop the hovercraft in midair, and tell the hovercraft to wait for a brand new dispatch message. Once it has received such a message, the pilot can manually select which entry ID it should start at, and then reconnect the autopilot.
I have also written a post from a cat working for the Feline Ministry of Transportation, think of it as something that would be commented on their equivalent of /c/programming under a link to this report. Thought you might enjoy!
FMT/FTDMS dev here, thought I’d shed some light on what happened on our side.
This was found during a Ministry of Security audit as part of their Safe Infrastructure initiative. All of this was legacy code that hadn’t been touched in ages, the oldest of which dates back to before the Felines had even signed the ISPA and stopped eating prey. Yes, FDTMS as a protocol only became an official thing after the Feline Revolution (and by extension us signing the ISPA), but before that was a dozen different ad hoc ATC standards used by different parts of Feline Territory, and some of the source code from those (namely parts of Flight Dispatch Protocol, the old standard used in Moonpeak where all the government ministries are headquarted) were reused for FDTMS because it seemed easier and faster than writing everything from scratch.
All four points in the official root cause analysis can be boiled down to “cats are lazy” and/or “cats are bad at communicating with each other.”
Parsing the message before checking message signature: The message parsing and cryptography teams didn’t adequately consult with each other and failed to make sure their components were executed in the correct sequence. Both teams worked on their own thing and assumed that as long as both were done between receiving the message and prompting the pilot to accept the final dispatch table, there would be no problems. What happened was that the message processing and signature checking happened simultaneously on different threads. In theory, the cryptography thread could stop the message processing as soon as it detects an issue, but in practice, the message processing was way faster so by the time the cryptography thread finished and returned a result, the message had already been parsed and has overflowed the buffer. This was changed to a synchronous system where the cryptography thread executes first, and it is now the one responsible for triggering subsequent data processing threads if and only if it doesn’t detect any issues.
Failing silently on an invalid dispatch and reverting to the previous one: This was actually intentional because cats in the flight deck/ATC centre didn’t want to have to click two extra buttons whenever a dispatch message got corrupted during transmission. So the system was designed to be as automatic and “paws off” as possible. In theory, the pilot is supposed to check that the reversion to the previous valid dispatch is the correct action when they get a dispatch rejected message, and also report the error to ATC, but in practice that pretty much never happens. This was part of the code that was reused from FDP, and this whole thing was a really stupid idea and we only realized that after we found this issue.
The parser being more tolerant than the the actual FTDMS protocol: The standard originally treated TerritoryChange and RegionChange as completely different entries, but it got changed to a single entry fairly late in development because we realized that crossing a territorial border always implies crossing a regional border since the other territory would have its own regions. So buildDispatchTable had already been implemented and had to be updated. The cats who updated it figured that they only had to implement support for including the region information in TerritoryChange and didn’t need to completely remove support for two separate entries (because that would have been more work). But they also forgot to test that the changes made to TerritoryChange didn’t affect the ability to safely accept two separate entries (because the standard was being changed to disallow that anyway) and this is actually where the buffer overflow originated.
All of FDTMS-Client being run in privileged context with no Secure Mode protections that could have detected the buffer overflow/prevented privileged memory from being overwritten: WhiskerOS Secure Mode is really strict and honestly a pain in the tail to deal with, especially in terms of getting privileged and non-privileged code to talk to each other. So in classic cat fashion, we said “screw it” and made the entire codebase privileged so we wouldn’t have to deal with that. Actually, now that we’ve had to transition to a more restrictive privilege model, we’re getting a lot of issues with interprocess communication as expected. I actually got reassigned to a team specifically for dealing with complying with Secure Mode’s restrictions.
I also want to say that things are getting better, and from my experience, the Feline Government actually has way superior work culture than most other software development places in Feline Territory. But a lot of that old fashioned, counterproductive, least-effort Feline culture is still present especially in legacy code or massive codebases where many teams have to collaborate.
…ah, race conditions. My old enemy.
What’s impressive (or scary, depending on your point of view) is how much of this rings entirely true to my real-life experiences. “The correct method is a pain in the rear/would require rework, so we’re going to take the fast and dirty method” is something I’ve watched have catastrophic consequences down the line. That, and peeling back the lid on the “new standard” and finding a hodgepodge of old standards, legacy code, and poor decision making is painfully real.
The question I have now is, if they actually tried to rip the bandaid off and replace the whole thing, would it be a political problem?
Thank you so much! I tried my darndest to incorporate my own experiences in software development into this! Though I definitely have way less experience than you.
I’ll let dev kitty respond to this!
Context: the Unified Territories is an alliance of many small to medium sized animal species, ranging from mice and songbirds to dogs and foxes; who all subscribe to an ideology called Unitism (hence unified territories), which is basically like “vegan socialism” where former predators and prey live in peace. The Felines are Unitist as well.
Fortunately there’s not really much political issues that would get in the way of that. The Feline Ministry of Transportation has full authority over the transportation infrastructure in Feline Territory, especially the implementation stuff like which ATC system to use.
Though, changes to the flight control standards (as opposed to the internal implementation of those standards) might require consultation with the Avian Government over in the Unified Territories because we want to ensure that naturally flying animals are kept safe when flying near hovercrafts. Even if the flight is entirely within Feline Territory, a lot of birds live here and they are still represented by their own taxonomic government, because all the Unitist taxonomic govs talk to each other and uphold Freedom of Migration between their territories. Generally, we would send our changes to them and they’ll let us know if they have any concerns.
However there probably won’t be a rewrite of FDTMS specifically, because we’re starting talks with the Unified Territory to develop a combined ATC standard so pur hovercrafts can more operate in each other’s airspace, and improve things like scheduling of cross-border flights, easier passenger connections between UTMT and FMT flights, allow an FMT aircraft to fill a UTMT scheduled flight and vice versa, and just generally try to make a system that combines the advantages of FDTMS and their UniFlyControl system. These are reeealy early stage talks so none of the technical details have been set yet, but it does seem like it will go through eventually.
I would hope it would be written in a completely memory safe language.