Turing Award Lecture

pile" is called to compile the next line of source. Figure

3.2 shows a simple modification to the compiler that

will deliberately miscompile source whenever a partic-

ular 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 I planted in the compiler would

match code in the UNIX "login" command. The re-

placement 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 is represented in Figure 3.3. This sim-

ply 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 Stage I self-reproducing pro-

gram that inserts both Trojan horses into the compiler.

This requires a learning phase as in the Stage II exam-

ple. First we compile the modified source with the nor-

mal 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 bi-

nary will reinsert the bugs whenever it is compiled. Of

course, the login command will remain bugged with no

trace in source anywhere.

compile(s)

char ,s;

I

FIGURE 3.1.

compile(s)

char ,s;

I

if(match(s, "pattern")) {

compUe("bug");

return;

J

FIGURE 3.2.

compile(s)

char

,s;

if(match(s, "pattern1 ")) {

compile

('bug1 ");

return;

I

if(match(s, =pattern 2")) I

compile

('bug 2");

return;

J

FIGURE 3.3.

MORAL

The moral is obvious. You can't trust code that you did

not totally create yourself. (Especially code from com-

panies that employ people like me.) No amount of

source-level verification or scrutiny will protect you

from using untrusted code. In demonstrating the possi-

bility of this kind of attack, I picked on the C compiler.

I could have picked on any program-handling program

such as an assembler, a loader, or even hardware mi-

crocode. As the level of program gets lower, these bugs

will be harder and harder to detect. A well-installed

microcode bug will be almost impossible to detect.

After trying to convince you that I cannot be trusted,

I wish to moralize. I would like to criticize the press in

its handling of the "hackers," the 414 gang, the Dalton

gang, etc. The acts performed by these kids are vandal-

ism at best and probably trespass and theft at worst. It

is only the inadequacy of the criminal code that saves

the hackers from very serious prosecution. The compa-

nies that are vulnerable to this activity, (and most large

companies are very vulnerable) are pressing hard to

update the criminal code. Unauthorized access to com-

puter systems is already a serious crime in a few states

and is currently being addressed in many more state

legislatures as well as Congress.

There is an explosive situation brewing. On the one

hand, the press, television, and movies make heros of

vandals by calling them whiz kids. On the other hand,

the acts performed by these kids will soon be punisha-

ble by years in prison.

I have watched kids testifying before Congress. It is

clear that they are completely unaware of the serious-

ness of theft acts. There is obviously a cultural gap. The

act of breaking into a computer system has to have

the

same social stigma as breaking into a neighbor's house.

It should not matter that the neighbor's door is un-

locked. The press must learn that misguided use of a

computer is no more amazing than drunk driving of an

automobile.

Acknowledgment.

I first read of the possibility of such

a Trojan horse in an Air Force critique [4] of the secu-

rity of an early implementation of Multics. I cannot find

a more specific reference to this document. I would

appreciate it if anyone who can supply this reference

would let me know.

REFERENCES

1, Bobrow, D.G., Burchfiel, J.D., Murphy, D.L., and Tomlinson, R.S.

TENEX, a paged time-sharing system for the PDP-10. Commun. ACM

15, 3 {Mar. 1972}, 135-143.

2. Kernighan, B.W., and Ritchie, D.M. The C Programming Language.

Prentice-Hall, Englewood Cliffs, N.J., 1978.

3. Ritchie, D.M., and Thompson, K. The UNIX time-sharing

system.

Commun. ACM 17, 0uly 1974), 365-375.

4. Unknown Air Force Document.

Author's Present Address: Ken Thompson, AT&T Bell Laboratories,

Room 2C-519, 600 Mountain Ave., Murray Hill, NJ 07974.

Permission to copy without fee all or part of this material is

granted

provided that the copies are not made or distributed for direct commer-

cial advantage, the ACM copyright notice and the title of the publication

and its date appear, and notice is given that copying

is by permission of

the

Association for Computing Machinery. To copy otherwise, or to

republish, requires a fee and/or specific permission.