Fred Cohen’s 1983 virus demo got full system rights in under five minutes at its fastest
The authorized Unix experiments targeted a security-policy weakness. Administrators responded by stopping further security experiments.
A security demonstration worked well enough that administrators stopped allowing security demonstrations. Fred Cohen’s account of his 1983 virus experiments has a technical result and an administrative sequel, with the latter doing very little to make the former less uncomfortable.
Cohen’s write-up dates the idea to November 3, 1983 and the seminar demonstration to November 10. The experiment used a VAX 11/750 running Unix. He reports five attacks, each gaining all system rights in less than an hour, with the fastest below five minutes. Those are his reported results in that setting, with no claim here about the first malicious or self-replicating program in computing history.
The initial host was vd, a utility for displaying Unix file structures graphically. Code at the beginning ran before the program’s ordinary work. Someone choosing a useful new utility could therefore run the added behavior as part of the same action. The feature being advertised did not have to disappear for the unwanted code to execute.
Cohen emphasizes “fundamental flaws in security policies” as the target. The experiments deliberately avoided implementation bugs. That is a useful distinction when deciding what kind of response would address a result: patching a particular programming mistake and changing who can pass executable behavior to whom answer different problems.
His report describes administrator consent and controls intended to keep the experiment contained. It was a demonstration with reporting rather than damage, followed by cleanup. Those boundaries belong in the account because a measured security trial and an uncontrolled release create very different evidence, as well as very different afternoons for the people running the machine.
The short takeover times were the surprise, according to Cohen. He also reports that people who knew about the attack were infected. Awareness gave the users a reason to be cautious, but the useful program and the execution path were still available. A warning attached to a workflow cannot establish that the workflow itself has changed.
The administrators’ subsequent ban on further experiments included work intended to improve visibility. Cohen presents that reaction critically. The account gives us his description of the decision; it does not supply every concern the administrators weighed. Even with that limit, the tension is clear: learning that a system permits an attack can make the test feel more immediately threatening than the condition it revealed.
For an operator reading the episode now, the practical payload is the trust path. A program somebody wants to use runs with authority that can matter elsewhere. Reviewing how that authority travels is a concrete follow-up to a demonstration. Merely telling people the demo was alarming would leave the mechanism waiting for its next opportunity.
The account leaves a question about the experiments the ban prevented. More instrumentation might have made the sharing paths easier to understand, but those proposed measurements cannot be treated as results. Cohen had shown the system’s problem; permission to investigate it further had become the next problem.
The demo lost its permission slip.