Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!cmcl2!seismo!brl-tgr!tgr!phil@RICE.ARPA
From: phil@RICE.ARPA (William LeFebvre)
Newsgroups: net.unix-wizards
Subject: Trojan horses -- the definitive answer
Message-ID: <3167@brl-tgr.ARPA>
Date: Wed, 13-Nov-85 13:52:42 EST
Article-I.D.: brl-tgr.3167
Posted: Wed Nov 13 13:52:42 1985
Date-Received: Fri, 15-Nov-85 05:20:21 EST
Sender: news@brl-tgr.ARPA
Lines: 56

All this talk of the famous "trojan horse" of Unix has made me go find
the very article where I first read about this.  The article is
"Reflections on Trusting Trust" by Ken Thompson, _Communications_of_
the_ACM_, Vol. 27, #8 (August 1984), pp 761--763.  It was Thompson's
Turing Award lecture.

I quote:

	Figure 3.2 shows a simple modification to the compiler that
    will deliberately miscompile source whenever a particular pattern is
    matched.  If this were not deliberate, it would be called a compiler
    "bug".  Since it is deliberate, it should be called a "Trojan horse."

	The actual bug that I planted in the compiler would match code in
    the UNIX "login" command.  The replacement code would miscompile the
    login command so that it would accept either the intended encrypted
    password or a particular known password.  Thus if this code were
    installed in binary and the binary were used to compile the login
    command, I could log into that system as any user.
	Such blatant code would not go undetected for long.  Even the
    most casual perusal of the source of the C compiler would raise
    suspicions.
    ...
	The final step ... simply adds a second Trojan Horse to the one that
    already exists.  The second pattern is aimed at the C compiler.  The
    replacement code is a ... self-reproducing program that inserts both
    Trojan horses into the compiler....  First we compile the modified
    source with the normal C compiler to produce a bugged binary.  We
    install this binary as the official C.  We can now remove the bugs from
    the source of the compiler and the new binary will reinsert the bugs
    whenever it is compiled.  Of course, the login command will remain
    bugged with no trace in source anywhere.

	(Copyright 1984, Association for Computing Machinery,
	 copied by permission)

I realize that this could give potential hackers out there some ideas.
But I don't feel bad about sending this into the list, since it comes
from a well published document and can probably be found in any decent
sized library.

I would encourage everyone to find a copy of that article and read it.
It isn't very long and it is very good.  The final section of it is Ken
Thompson moralizing about "hackers", and severely criticizes the press
in their handling of the situations (414 gang, Dalton gang, etc.).
Well worth reading.

I thought that the article contained some statement like "this bugged
version of the C compiler never made it out of Bell", but no such
statement is made.  Suppose it did make it out after all.....

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil@Rice.arpa>
                        or, for the daring: <phil@Rice.edu>