WiFi to the Danger Zone: A Tale of Missiles and Memory Leaks

Wifi to the Danger Zone

By Adam Cecchetti

Ah, memory leaks. They can cause lots of things to crash: games, browsers, phones, computers, servers. Possibly, even missiles, it seems. And as you might imagine, crashing missiles is not a good thing.

Recently, I noticed this first-hand account about missile firmware engineering.

I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customer’s chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.[1]

In other words, the engineers intentionally added more memory than needed to the missile so that, in theory, known software issues wouldn’t cause the missile to go off course or explode prematurely.

Memory Leaks: What Projectile Firmware and Hotels have in Common

Imagine you have a hotel with 10 rooms. The front desk diligently marks one room occupied upon check in, and vacant upon check out. Thus they always know when a room is free for a guest. Housekeeping watches the vacancies and makes up the room in between guests.

What happens if the front desk doesn’t mark a guest as checked out? Eventually, they run out of rooms and can’t accept new guests.

What happens if housekeeping doesn’t watch the vacancies? A new guest trips over a pile of towels when they enter the unmade room; perhaps they demand a refund, perhaps they sue.

Similarly, these missiles have a fixed amount of memory available for calculating trajectory to target and detonation protocol. Some of that memory usage is allocated to firmware; when the memory is not being used anymore, the safe thing to do is to clean it up and mark it as free. This particular design did not mark the memory as free, and thus the missile eventually ran out of memory and was not able to perform additional operations. The gamble was: when?

If the memory is not also cleaned up when it’s marked free, another issue can occur. Imagine walking into a hotel room full of the previous guest’s belongings. If you or house keeping does not clean up the room first you are going to be tripping over pillows and using the tooth brush and clothes they left behind because there is no room for yours.

Tracking guests and cleaning rooms are part of sound hotel operations; tracking and cleaning memory usage is part of sound missile operations.

As you might imagine, computers -- whether they are stationary or moving at Mach 2.5 -- tend to do very poorly in low-memory or no memory states.


A Timeline of Missile Engineering Tradeoffs

The offline era

Prior to 1990, missiles were pretty offline: there was no off-the-shelf communication path to the missile. One might imagine a hypothetical scenario: a saboteur gets near the missile, plugs a programmer into the missile, alters a bit of the code or hardware, and triggers the memory leak earlier in the missile flight sequence, resulting in missile impotence or imprecision. But really, chances of electronic tampering were pretty low. Nineteen year olds with M-16s tend to be a good deterrent for hypothetical saboteurs, so this attack scenario remained largely Bond-level implausible.

The online era

Now, let’s move closer to contemporary missileering and put our missile “online”. When a system that's remotely accessible can communicate with the missile, it opens new avenues of attack. As a for instance, imagine a ground station communicating with an aircraft, which in turn communicates with a missile via the aircraft’s 1553 bus. It doesn’t mean the potential saboteur can cause a direct issue, but it is now possible to connect without being in physical proximity.

To be fair, this is still a fairly obscure and implausible means of access. Military radios, protocols, busses, systems, specifications, and encryption codes are required to communicate with the aircraft and missile. An actor that is highly motivated because they “know” there are bugs to be exploited may spend the resources to acquire all of the needed information, perhaps because in the exact right circumstances the result might turn the tide of an air combat situation, but it takes a great deal of work.

The direct connect era

When this all REALLY starts to matter is when we add a radio to the missile.

Now a malicious actor doesn’t have to figure out how to talk from the ground to the plane to the missile. Instead, they can communicate directly to the missile as long as it’s within line-of-sight broadcast range of the communicating device.

Now, if there's a way to cause one of the aforementioned memory leaks to occur by sending radio packets, the malicious actor can remotely cause the missile to use up memory faster than the engineer anticipated. Intended side effects include potentially causing the missile to go off course, explode early, or fail in some other way the engineer didn't anticipate-- All from the comfort of homespun battle pajamas. Imagine if that receiving radio is active while the missile is still on the plane – in the fog of war, arming and detonating missiles to explode planes is a startling, but quantifiable, attack vector.

The Arc of Destruction

Despite archaic but relatively effective guidance mechanisms, some of the greatest terror the German Nazi Party caused was through the trajectory and detonation errors of their V-2 rockets. Now, 75 years later, the threat of intentionally ignored memory leaks is enough to inspire pause. It doesn’t take much to leap from the idea that one could artificially accelerate a missile’s memory loss to the idea that a threat actor could do so with mathematical precision and cause horrific but intended consequences. In the last 20 years, firmware engineering has gotten better, but perhaps we should take another look at what we declare a minimum viable missile.



[1] https://groups.google.com/forum/message/raw?msg=comp.lang.ada/E9bNCvDQ12k/1tezW24ZxdAJ

For the sake of this post we’re going to assume this story is true but we haven’t verified it.