1984 Ken Thompson's CC Hack¹

Ken Thompson described this virus² as "the cutest program I ever wrote", and since his account of it appeared in 1984, it has become folk law of the information age. Ken modified the source of the C compiler (CC) such that the compiler would detect when it was compiling the UNIX "login" command and hence produce a compromised version of the login command which would accept either a valid password from the system password file, or a particular known password. Effectively giving him a back door to any system whose "login" binary was compiled with his compromised C compiler. This in itself results in a curious situation, despite all attempts to verify the source of the "login" command, it is impossible, once the C compiler has been compromised to build a secure "login" binary.

Not content with this level of subversion, Ken introduced a second modification to the compiler source such that it would detect when it was compiling a new version of itself. It would then incorporate both modifications into the new compiler binary.

/* Here is the EVIL VIRUS CODE that is implanted in every Perl
   Absolutely no peeking. This is not here. */
if (moon == color_blue && day_of_week == 5 && day == 13)
    delete_hard_drive(completely);
[download]

This was covered in Ken Thompson's talk Reflections on Trusting Trust. This first appeared in an issue of CACM. Here's an online copy. It's a fascinating read, a classic that all programmers should know.


--
g r i n d e r

To the best of my knowledge, much of this is an urban legend. Ken mentioned that he had thought of the idea but never actually implemented any of it. It would make very interesting code to read. How does a C compiler reliably reconize that it is compiling a "login" program and then determine where to insert the alternate password code? The second hack seems even more daunting of a challenge.

Right... not only do you need authentication of the author, but you also need 'correctness' - a warm fuzzy that other users have approved of the code, that it has no bugs / viruses attached. (If it was to be implemented, it could be a warm fuzzy factor sort of like xp here on pm for the correctness of the code...)

----
Zak

Perhaps CPAN-6 will include a discussion forum for each module, too.

In theory, one can certainly do that. But is it practical? I really wish it would, because then everyone could be a Perl porter! Perl is installed by tens of thousands of people. I'd be surprised if even 5 checked the source to see whether it has some nasty "easter eggs". For modules, it might be a little easier to check (because it's less code), but still, it's not practical at all. Not only do you need to check the module, but also the makefile and the test program(s).

-- Abigail