The Ship
It’s 1997, and computers are making many things easier and more efficient. Enter: The Yorktown, a ‘smart’ Navy ship outfitted with new tech. This ship has been in metaphorically uncharted waters before: in 1988, when the Soviets decided nobody got to use ‘right of innocent passage’ in their chunk of the Black Sea, the Yorktown was there to push back a little and ensure that innocent passage was still an option. A Soviet cruiser attempted to push it back into international waters via hull-bumping, but because the Yorktown was extraordinarily well-outfitted and came with buddies, it didn’t go any further. The Soviets begrudgingly updated relevant handbooks to include right of innocent passage in their waters, something that had been available in the English version of the UN sea laws book but not the Russian one, and promised not to bully innocent boats out of their water again.
The Yorktown was impressive within the military, and yet it didn’t make much mainstream news beyond that Soviet incident. That’s not to say it didn’t deserve it – the Yorktown is very well-decorated across the board, in everything from safety to combat readiness. It was also already partially computerized already due to its young age. It was an excellent place to start, a great testing ground for the newly possible ‘smart’ ship technology. Things could only get better once it had it’s new, shiny computers onboard fired up and ready to rumble. The Navy was entering a new era, one of peace, yes – but also one of significant technological catch-up to the consumer and business sides of tech.
The Incident
However, programming has always had its flaws, even when it was many times simpler than what we have today. A small bug or flaw could cripple a business until it was sorted out, and the Navy was about to learn this the hard way: a programming flaw consumed literally all of the RAM everywhere on the boat. Someone put a zero into a database field that was used in a division equation, and the computer locked up while trying to divide by zero. This wasn’t a particularly consequential computer, but it didn’t stop there! As said before, it ate all of the RAM. All of the computers shut down. All of them. Including seemingly unrelated ones in propulsion, because instead of just locking up the one computer, the error ate all of the RAM and spread in what’s known as a buffer overflow.
Luckily, it wasn’t in a lot of danger – boats float by themselves, and it was in friendly waters just off the coast of Virginia during the incident. Two days later, it was back to business and battle maneuvers. However, whether or not it had to be towed in is a point of contention: reporters who talked to important folks on the boat say that’s what they were told, but the important folks later came out and said that it got into port under its own power. There’s motivation in keeping the exact details quiet – buffer overflows were easy to make happen, should a malicious actor get into the LAN – so the exact truth is somewhat obscured.
It recovered eventually, and safeties were put into place so that system administrators could bypass the faulty input and replace it without totally wrecking the entire network in the process.
The Flaw: Divide By Zero Plus Buffer Overflow
It’s a common joke: divide by zero, destroy the universe. Convert something into nothing, break laws of physics and conservation of mass. Dividing by zero is illegal for most computers nowadays – they’re programmed not to think about it and dismiss it right away with an error message instead. If they don’t, the computer ends up locking up as it tries to figure out how to do the impossible. Yorktown’s database manager program wasn’t programmed to return an error. Even that might not have been a huge issue if it hadn’t overflowed, which was the real problem, and that might not have been an issue if the LAN wasn’t trying to resource-share where it shouldn’t have been.
The way a buffer overflow works in Windows is that an error starts overwriting surrounding lines in the database, compounding the error and consuming even more RAM to calculate, so once it got going, it was going. Other computers in the network designed to connect to this one began experiencing the buffer overflow as well, and soon the entire network had been eaten by the divide by zero error as other computers became fodder for a faulty calculation.
How would you prevent this from happening in the future?
Buffer overflows are still a widely known exploit. In an attack, a malicious actor would send code that breaks the formatting of the destination database, either to lock up the computer or replace nearby innocent code with malicious code and squeeze in further. Windows (and the version of Windows the military was using on the boat) actually doesn’t have a built-in prevention feature, either, so it really was possible to cripple ‘smart’ vessels with simple typos that would be harmless on other operating systems.
The simple answer is to just not use Windows NT. If something makes it into a database, Windows NT would not check to make sure it fit in the provided array (which is essentially a size and formatting gate for databases). A more complicated answer is reprogramming around the software to ensure it returns an error, or refuses to process bad inputs altogether, something they wouldn’t have had to do had they used a different OS. Software failures were allegedly already a known issue in Windows NT, but the only other options were UNIX or custom-building something. The Navy picked Windows because it was slightly more user-friendly, but as a result, patchwork code filled in the gaps between the stuff already there and the stuff being freshly installed to make the Yorktown a ‘smart’ ship. Some things were overlooked.
After this incident, the Navy pushed for more UNIX and less NT. UNIX, while imperfect, didn’t literally try to eat the entire network over a typo when it encountered a database error. Engineers within the Navy said they pushed back against Windows only for Windows to win anyway in a political victory; this is one of the incidents that forced the Navy to listen to engineers further down the line.
Was it worth it?
Short answer? Yes, actually. The Yorktown saved an estimated 2.9 million dollars and reduced its crew by ten percent, just by computerizing. Human error has also stranded boats; at least the computer doesn’t have a sense of lying for self-preservation. Besides, the old boats without computers doing everything were effectively wasting labor, which – in the unprecedented peace just before 9/11 – was unacceptable. Those sailors could be doing something else more productive than hand-calculating trajectory and speed.
Those first Smart boats were rough, yes, but the experience gained from that buffer overflow in safe waters was invaluable.
Sources:
https://web.archive.org/web/20060208090921/http://www.gcn.com/17_17/news/33727-1.html
https://en.wikipedia.org/wiki/1988_Black_Sea_bumping_incident
https://gcn.com/articles/1998/07/13/software-glitches-leave-navy-smart-ship-dead-in-the-water.aspx
https://slate.com/technology/2018/06/why-the-military-cant-quit-windows-xp.html
https://www.wired.com/1998/07/sunk-by-windows-nt/
