Path: utzoo!attcan!uunet!husc6!mailrus!cwjcc!hal!nic.MR.NET!tank!nucsrl!naim
From: naim@eecs.nwu.edu (Naim Abdullah)
Newsgroups: comp.protocols.tcp-ip
Subject: And You Thought You Were Paranoid...
Message-ID: <7080011@eecs.nwu.edu>
Date: 8 Nov 88 11:03:55 GMT
Organization: Northwestern U, Evanston IL, USA
Lines: 57

One of our staff members here, was suspicious that the recent worm
may have planted trojan horses for crucial binaries like vmunix,
fsck etc. He used "ls -l" to compare the sizes on our infected machine
with that of an uninfected machine and satisfied himself that things were
ok (actually he got a nasty shock when "ls -l" showed up different sizes
but then he remembered he had recompiled stuff to toss out yp and use the
BIND stuff and that is why the sizes were different).

I thought about this and then later remembered Ken Thompson's Turing award
lecture. Here is a worst case scenario which we were spared fortunately.

In PRINCIPLE "ls -l" is not enough. The worm had root priveleges, it could have 
installed a modified /bin/ls so that if one of the files being listed
was fsck, vmunix, ls, telnetd etc (the tampered binaries) /bin/ls
would always show predetermined sizes. In that situation, "ls -l" wouldn't
be enough.

It is even worse than that. Actually, the worm could have replaced cmp
and cc with it's own versions so that even if you recompiled any of the
tampered binaries, cc (which had been tampered itself), would substitute
the phony code instead of the true code. Even recompiling cc wouldn't
work because the phony cc would recognize that it is compiling cc.c and
would put in the extra devious code. Ofcourse, copying sources from
other machines wouldn't work either because ftp, rcp etc have all been
substituted with phony versions. Actually, the bad guy could even have
tampered with tar, dump, restore so that if it is retrieving cc.c or
ls.c or any of the tampered binaries, it retrieves instead a hidden file
(the hidden file lives on the disk, but you would still see the tape
spinning). As you would expect, emacs, vi, less could also
be tampered with, so that they show you the original bsd code, when what you
are looking at is really phony code.

In such a situation, you would have no inkling that there was anything
wrong. The only way to get out of such a situation would be to physically
replace disk packs. And you would only do that if you got suspicious. But
why would you get suspicious, since all the commands are giving you a rosy
picture... ? (probably high disk usage would be one clue, but then the bad
guy was probably smart enough to have tampered with du and df so you wouldn't
see the high disk usage; your partitions would just get full and you would
either blame it on the BSD file system hogging that 10% free space :-) or
those huge incremental backups that you keep on disk; or to give you some
free space, the worm could silently truncate files that hadn't been touched
for three months or so).

This kind of paranioa isn't worth it, but I think given enough incentive,
the bad guy could have carried such a thing out. Ofcourse, the worm would 
have to carry most Unix commands with it, on it's travels but with high
bandwidth networks that might have been ok.

		      Naim Abdullah
		      Dept. of EECS,
		      Northwestern University

		      Internet: naim@eecs.nwu.edu
		      Uucp: {oddjob, chinet, att}!nucsrl!naim