VAX, TCP/IP, and Thirty Years of the Same Trust Problem

A Japanese version of this is on Note. I build RoamSwitch, a network security app for Mac and Linux, on my own. Maybe it's this line of work, but every time I write about AI agents automating cyberattacks, I keep thinking back to 1992, the year I entered this industry. What I was looking at then and what I'm looking at now are supposedly different technologies entirely, yet they keep feeling like the same shape to me. Worth actually writing that down properly, checking memory against real technical history rather than just vibes. When VAX/VMS and HP-UX Shared the Same Room In 1992 I worked for a large US computer company's Japan office. The machine in front of me was a VAX running VMS. Across the room, another terminal ran HP-UX. Something as basic as password protection had already walked two completely separate histories by then, and I noticed it constantly. VMS password protection in its first version, 1978, used a 32-bit hash built on an AUTODIN-II CRC (cyclic redundancy check). CRCs were designed to catch transmission errors, not resist deliberate tampering, so this was less a vulnerability than a case of using the wrong tool for the job. The words "penetration" and "prepituitary" happen to collide at the same CRC32 value, 0xBF6A229E. DEC finally moved to a Purdy-polynomial-based algorithm in version 2, 1980. HP-UX used a DES-based hash through crypt(3) , a 12-bit salt run through 25 rounds of DES, clever for the time, but the password itself was only meaningfully used up to 8 characters, weak against dictionary attacks from day one. Steal /etc/passwd and run it through a cracking tool, and you'd have a few passwords within the hour, that was the common understanding back then. Shadow files were a patch, not a fix. HP-UX had another weakness, the "trusted host" mechanism built on rlogin and .rhosts /hosts.equiv . HP-UX 9.0, released that same July 1992, predated its full move to System V (SVR4) and still carried a strong BSD flavor, rlogin was one of those native BSD features. Log in without a password from a trusted host, purely for convenience, and the moment your DNS or network path got hijacked, that convenience became the door in. Deciding trust based on a hostname, a value anyone could spoof, was the core problem. TCP/IP Was Never Designed With Security In Mind Go deeper and the foundation under most of this, TCP/IP itself, was never designed with security in mind either. Vint Cerf and Robert Kahn's 1974 design existed to interconnect networks of fundamentally different character, ARPANET, packet radio, satellite networks. The whole thing was built on the assumption that participants were a mutually trusting research community. Authentication and encryption appear nowhere in the protocol stack. ARPANET's full cutover to this TCP/IP came nine years later, January 1, 1983, a coordinated one-day switchover from the old protocol (NCP) that everyone just calls "flag day." Worth a note here. The VAX I touched in 1992 didn't actually speak this TCP/IP natively. VMS's native networking protocol was DEC's own DECnet, and using TCP/IP meant bolting on a third-party product, companies like The Wollongong Group had been selling those since late 1983. HP-UX, meanwhile, had TCP/IP built in natively since 4.2BSD, 1983. Two different networking philosophies sharing the same room, one proprietary and one TCP/IP, stitched together after the fact so they could talk to each other. That structure kept repeating for decades after. The person who first documented this structural weakness, in a fittingly ironic way, was Robert Morris Sr. A cryptographer at Bell Labs, he published "A Weakness in the 4.2BSD UNIX TCP/IP Software" in 1985, showing that because TCP sequence numbers were predictable, an attacker could impersonate a trusted host without ever receiving a single response packet. He left Bell Labs the following year to become chief scientist at the NSA's National Computer Security Center, helping produce the official evaluation criteria for computer security, the Rainbow Series. Then, the night of November 2, 1988, his son Robert Tappan Morris (a Cornell grad student at the time) released what would become known as the Morris Worm from MIT's network. The worm's own methods were a different lineage from the father's paper. Four vectors, chained together. One, abusing sendmail's DEBUG mode, meant for debugging, which let part of a mail message get executed as a command directly. Two, a buffer overflow in fingerd. A fixed-length buffer, written to unchecked via gets() , exploited to overwrite the stack's return address and run arbitrary shellcode. That's the same "stack smashing" technique Aleph One would formalize eight years later, already in live use here. Three, the same .rhosts /hosts.equiv trust abuse. Four, a simple brute-force password guess using a dictionary of a few hundred words plus username variations. Morris's own design mistake is baked into this worm too. To make reinfection hard to detect, it allowed itself to reinfect an already-infected host with some probability, one in seven. That probability turned out to be set too high, and dozens of infection processes piled up on a single machine, chewing through CPU and memory until the host stopped functioning. Not malice, the attacker's own miscalculation multiplied the damage, a pattern that would repeat in worm outbreaks for years afterward. In the end, roughly 6,000 systems, about a tenth of the internet at the time, were affected. This incident is what drove DARPA to establish CERT/CC (Computer Emergency Response Team Coordination Center) at Carnegie Mellon, effectively founding "computer security incident response" as its own discipline. The trial produced the first felony conviction under the 1986 Computer Fraud and Abuse Act (CFAA). A father points out the theoretical fragility of a trust model, a son goes and breaks essentially that same trust model (different shape, same idea) for real. This is, to me, the single most emblematic story of that era, less a technical vulnerability than the field of computer security itself emerging out of what feels like a family conversation. There was already an official yardstick in the VAX/VMS world too, by the way. TCSEC, the Orange Book, drawn up in 1983 by the NCSC (National Computer Security Center, part of the NSA, the same place Robert Morris Sr. later moved to), intended for the Department of Defense. It graded systems from D (lowest) to A1 (highest), and that grade drove product selection in government procurement. A serious attempt at quantifying trust, but the thing being evaluated was always a single, standalone system, the idea of being attacked over a network by a different system wasn't yet front and center in how the criteria were designed. What the Morris Worm exploited was precisely that gap, each system had been graded seriously on its own, but nobody had graded what happened once they were wired together. PGP and the First Crypto War In 1991, Phil Zimmermann released PGP (Pretty Good Privacy) for free. Letting anyone protect their email with strong encryption sounds obviously fine, but at the time it was potentially a violation of US arms export regulations (ITAR). Zimmermann himself became the subject of a DOJ investigation. That conflict reached its peak in 1993 when the Clinton administration proposed the Clipper Chip. An encryption chip meant for standard inclusion in phones and similar consumer devices, built with "key escrow" so the government held a copy of every chip's key. Law enforcement wanted to decrypt with a warrant. The public wanted the right to use strong encryption freely. The Clipper Chip itself never caught on in the end, helped along by opposition from groups like the Electronic Frontier Foundation, but the underlying question, how much cryptographic strength should ordinary people be allowed, kept resurfacing in new forms for years after. I was only a few years into the industry at the time, and honestly had no real sense of how large a fight this would stay. 1995, Mitnick and SATAN A few years into my career, 1995 turned out to be a big year in two separate ways. One was Kevin Mitnick's arrest in North Carolina on February 15. It traces back to the previous Christmas, 1994, when he broke into the machines of Tsutomu Shimomura (then at the San Diego Supercomputer Center). Tracing the intrusion technique later, I remember reading it over and over just for the sheer audacity of completing authentication without ever receiving a single response packet. Here's the actual sequence. Mitnick first used reconnaissance commands, finger , showmount , rpcinfo , to establish that an rlogin -based trust relationship existed between an X terminal and a server in Shimomura's environment. He then neutralized that server itself, flooding it with SYN packets spoofed from real but unresponsive source addresses. What we'd now just call a SYN flood, filling it with half-open connections until it went silent. With the server muted, he predicted the TCP sequence number it would have issued to a legitimate client by sending it a series of separate SYN packets and watching how it behaved. Then he spoofed the server's IP to the X terminal and completed the three-way handshake without ever receiving a single response packet. The one command sent over that connection, impersonating root, was echo + + >> /.rhosts . That's it. Root from any host on earth now had unconditional login to that X terminal. This is regarded as the first real-world use of the TCP sequence number prediction attack Robert Morris Sr. described as theory in his 1985 paper. Nine years later, the attack technique from that paper got executed as an actual intrusion. Shimomura tracked Mitnick down himself using sophisticated network monitoring techniques, eventually leading to the FBI arrest. It was widely covered at the time as the turning point where the era of lone hackers repeatedly outmaneuvering national agencies gave way to i