Desynched channels on IRCnet

In this paper we describe what a desynchronised channel on IRC is. We give procedures on how to create such a channel and how to remove desynchronisation. We explain which types of desynchronisation there are, what properties desynchronised channels have, and which properties can be exploited.

💡 Research Summary

The paper provides a comprehensive examination of channel desynchronisation on IRCnet, a classic distributed Internet Relay Chat network composed of a tree of interconnected servers. Each server independently maintains the state of every channel—its mode list (operators, voiced users, bans, etc.) and its user list. Because the network relies on asynchronous message propagation, timing differences, simultaneous commands, and especially temporary network partitions (net‑splits) can cause divergent views of a channel to arise. The authors define such a divergent state as a “desynchronised channel.”

Two principal categories of desynchronisation are identified. Mode desynchronisation occurs when different servers apply conflicting MODE commands at roughly the same moment, or when a net‑split isolates a subset of servers that each set different modes before the network rejoins. A classic example is a user being granted operator status (+o) on one server while simultaneously being stripped of it (‑o) on another; after the split heals the channel ends up with two inconsistent operator lists. User desynchronisation arises from concurrent JOIN, PART, or KICK commands that reach different servers in different orders, leaving some servers with a user present while others think the user has left. This is most common when a net‑split is in effect and each side performs independent channel modifications.

The authors detail how an adversary can deliberately induce desynchronisation. The first method, simultaneous mode injection, requires precise timing: the attacker sends conflicting MODE commands to two target servers almost simultaneously, exploiting the fact that each server forwards its own command first. The second method, induced net‑split, involves temporarily breaking the link between two server clusters (e.g., via a ping‑flood, routing manipulation, or firewall rule). While the link is down, each partition can perform arbitrary channel changes; when the link is restored the two divergent states merge, producing a desynchronised channel.

Once desynchronisation exists, the channel exhibits several notable properties: (1) dual mode lists—each server may have a different set of operators, voiced users, and bans; (2) hidden operators—a user who is not an operator on one side may be recognized as an operator on the other, allowing privileged actions (topic changes, forced kicks) that are invisible to the rest of the network; (3) asymmetric message routing—messages are propagated locally, so some users may miss messages or receive duplicates; (4) partial channel persistence—the channel can survive on one side even after being destroyed (e.g., last user parts) on the other.

These properties enable a range of exploits. A “stealth operator” can silently remove or silence targeted users without alerting the majority of participants. By setting +i (invite‑only) on one side while leaving it unset on the other, an attacker can bypass authentication mechanisms, allowing unauthenticated users to join via the side that lacks the restriction. Desynchronisation can also be weaponised for denial‑of‑service: users on one side see a functional channel while those on the other see a vanished or empty channel, fragmenting the community.

The paper proposes two systematic remediation techniques. Full re‑synchronisation involves destroying the channel on all servers (forcing a PART) and then recreating it with a coordinated JOIN, thereby imposing a single consistent state. Operator consensus relies on the legitimate operators on each server communicating to reconcile mode lists and prune extraneous users; the use of optional SYNC or SJOIN messages (supported by some IRC extensions) can accelerate this process.

In conclusion, while desynchronisation is an inherent risk of IRCnet’s loosely coupled architecture, it can be intentionally triggered through precise timing attacks or controlled net‑splits, and it yields both tactical advantages for attackers and operational challenges for network administrators. Mitigation requires regular state audits, coordinated operator actions across server boundaries, and, where possible, the adoption of additional synchronization mechanisms to keep channel state uniform across the distributed network.