Port 512: Rexec & Comsat — Trusting Networks

Port 512 is a split personality in the well-known port range. Over TCP, it carries rexec (remote execution). Over UDP, it carries comsat (also called biff), a mail notification service. Both protocols were created in the early 1980s. Both are obsolete. Both send everything in plaintext. Both represent a world that no longer exists.

What Runs on Port 512

TCP: Rexec (Remote Execution)

Rexec allows you to execute shell commands on a remote Unix machine. You send a username, a password, and the command you want to run. The server replies with a status byte (0 for success, 1 for failure) followed by the command output.¹

The protocol is simple. Connect to port 512. Send your credentials. Send your command. Get the result back. Everything happens in plaintext.

UDP: Comsat/Biff (Mail Notification)

Comsat is the daemon. Biff is the client utility that enables it. When new mail arrives on a Unix system, the mail transfer agent (like Sendmail) sends a UDP packet to port 512 on localhost. Comsat receives the notification, finds the user's terminal, and displays a snippet of the message header directly on their screen.²

It's instant mail notification from 1983. No encryption. No authentication. Just a UDP packet saying "you've got mail" before that phrase became a movie title.

The History: Berkeley's R-Commands

The rexec protocol was developed in 1982 by the Computer Systems Research Group at the University of California, Berkeley. It was part of the Berkeley r-commands suite, which first appeared in 4.2BSD in August 1983.³

The suite included:

• rcp (remote copy)
• rexec (remote execution)
• rlogin (remote login)
• rsh (remote shell)
• rwho (remote who)

These commands became the standard way to access remote Unix systems throughout the 1980s and early 1990s. They were integrated into commercial Unix variants like SunOS (starting with version 4.0 in 1986) and HP-UX.³

Unlike rsh, which used .rhosts files for authentication, rexec required actual login credentials. It read the username and password from the network socket. In plaintext. Every character visible to anyone with a packet sniffer.⁴

The protocol was formally documented in RFC 1340 (Assigned Numbers, July 1992), which describes port 512 as "exec - remote process execution; authentication performed using passwords and UNIX login names."⁵

Why This Is Insane

The main security issue with rexec is obvious: it does not encrypt data. Usernames and passwords flow across the network as readable text.¹

This wasn't considered a problem in 1983. The Internet was small. Universities and research institutions connected their machines. The assumption was that the people on the network were colleagues, not adversaries.

That assumption didn't survive contact with reality.

By the 1990s, network sniffing was trivial. Anyone on the same network segment could capture passwords. Root credentials. Administrative access. All flowing through port 512 like water through a pipe, visible to anyone who bothered to look.

Rexec (and the entire r-commands suite) became synonymous with security negligence. Yet they remained in use for years because they were convenient, standardized, and already deployed everywhere.

The Replacement: SSH

In 1995, Tatu Ylönen at Helsinki University of Technology created SSH (Secure Shell) after witnessing password sniffing attacks on his university's network. SSH encrypted everything: passwords, commands, output, the entire session.³

SSH's adoption entirely supplanted rexec, rsh, and rlogin. By the early 2000s, the r-commands were disabled by default on most Unix systems. By the 2010s, they were considered legacy code, maintained only for historical compatibility.

Port 512 became a ghost. Still assigned. Rarely used. A reminder of what we used to tolerate.

Comsat's Quieter Obsolescence

While rexec died from security problems, comsat/biff simply became irrelevant. The rise of IMAP, POP3, graphical mail clients, and push notifications made terminal-based mail alerts unnecessary.²

Modern mail clients don't need a daemon listening on port 512 to tell them when new messages arrive. They maintain persistent connections to mail servers. They show notifications through operating system APIs. Comsat solved a problem that no longer exists.

Security Implications

If you find port 512 open on a modern system, something is very wrong.

For rexec (TCP):

• The service should not be running. Period.
• If exposed to the Internet, it's an open invitation for credential theft and remote code execution.
• Attackers can brute-force passwords because there's no rate limiting in the original protocol.⁶

For comsat (UDP):

• Less dangerous, but still unnecessary.
• The lack of authentication means anyone can send fake mail notifications.
• Modern systems have no reason to run this service.

How to Check What's Listening

On Unix-like systems:

# Check if anything is listening on port 512
sudo lsof -i :512
sudo netstat -tuln | grep :512

# Check for rexec daemon
ps aux | grep rexecd

# Check if rexec is enabled in inetd/xinetd
grep -r rexec /etc/inetd* /etc/xinetd*

On most modern systems, these commands should return nothing.

Related Ports

Port 512 exists in a neighborhood of obsolete remote access protocols:

• Port 513: rlogin (remote login) - another r-command with plaintext authentication
• Port 514: rsh (remote shell) - uses .rhosts for authentication, no password required
• Port 23: Telnet - the other famous plaintext remote access protocol

All of these ports have been replaced by SSH on port 22.

Why Port 512 Matters

Port 512 represents a turning point in Internet history. For over a decade (1983-1995), remote Unix access meant sending passwords in plaintext. This wasn't considered unusual or dangerous. It was just how things worked.

The transition from rexec to SSH marks the moment when the Internet stopped being a trusted research network and became a hostile public infrastructure. Security stopped being optional.

Every time you see the lock icon in your browser, every time you SSH into a server, every time encryption happens automatically without you thinking about it—that's the world we built to replace port 512.

We learned the hard way that trust doesn't scale.