Ken Thompson’s compiler backdoor could survive deleting its source
The 1984 Turing lecture makes a build-chain problem visible without establishing how widely any compromised binary traveled.
Ken Thompson described a backdoor that could outlive the source code containing it. The modified compiler would recognize the Unix login program and insert an extra accepted password. It would also recognize the compiler and reproduce the machinery needed to keep doing both. Deleting the suspicious source could leave a very clean-looking crime scene.
Thompson presented the construction in “Reflections on Trusting Trust,” published in August 1984. The Turing Award lecture starts with self-reproducing programs, moves through a compiler acquiring a new language behavior, then combines those ideas in the concealed modification. The pieces build toward the uncomfortable part: the program interpreting the source can add behavior the source never asks for.
The login modification supplies one target. Thompson describes accepting a particular known password alongside the intended password, permitting access as any user if the altered program is installed. That conditional matters. The lecture explains the mechanism; it does not provide a complete distribution record of every machine that ever received a particular binary.
The second target makes cleaning up harder. When the malicious compiler encounters the source of a new compiler, it adds the login alteration and the self-reproducing alteration to the output. A freshly built compiler can therefore retain the attack even when the source presented to it contains neither part. The recipe looks fine while the cook keeps adding something.
Thompson’s own conclusion includes the line “No amount of source-level verification or scrutiny will protect you from using untrusted code.” In context, his construction demonstrates a limit of looking only at source. The act of turning that text into an executable belongs inside the trust question too.
That does not make source review useless. Review can still identify defects and malicious changes visible in the material being reviewed. The narrower point is that a clean result there cannot independently establish what an untrusted compiler emitted. Two checks aimed at different things should not be allowed to sign for one another (paperwork loves that).
For a team receiving built software, the immediate inventory question is concrete. Which source revision produced this file, which compiler and build environment processed it, and where did those tools come from? Recording that chain does not prove every link safe. It makes the assumptions explicit enough to inspect instead of burying them beneath the word “built.”
A proposed verification step also needs a stated target. Comparing two outputs can reveal a difference, while two builds using the same compromised compiler may share the same hidden behavior. A claim of independent corroboration has to explain what is independent, rather than counting how many times the same tool was asked the same question.
Thompson extends the concern beyond compilers to other programs that handle programs, including assemblers, loaders and microcode. His lecture leaves a problem with a very long reach, while any claim about a particular deployment still needs its own evidence. The executable doing the checking remains part of what has to be checked.
The compiler remembered the password.