naim@eecs.nwu.edu (Naim Abdullah) (11/08/88)
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
wbe@bbn.com (Winston B Edmond) (11/09/88)
In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes: >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). Even easier -- use the 10% free space area to hold the virus's files, then adjust the used-block count. The penalty is somewhat worse disk performance, and the possibility of detection when the disk is fsck'd, but how many people worry about reports that the free block count has been adjusted when there are no reports of broken files? I agree, though, that the next stage of development for virus and worm programs is to augment offensive techniques (replication methods) with improved defensive techniques: evading detection by attacking the tool programs like ps, and limiting execution of the offensive code so that runtime and disk usage look normal and negligible. -WBE
sms@ETN-WLV.EATON.COM (Steven M. Schultz) (11/11/88)
> From: nic.MR.NET!tank!nucsrl!naim@ub.d.umn.edu (Naim Abdullah) > Organization: Northwestern U, Evanston IL, USA > Subject: And You Thought You Were Paranoid... > Message-Id: <7080011@eecs.nwu.edu> Naim Abdullah writes... > 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. > This is not quite correct, 'sendmail' had changed uid to "daemon" (1 on the system here) NOT "root" when executing the worm. The worm had NO super user privileges - that would be a serious flaw to have 'sendmail' running as "root" at that stage in the delivery process. If the system directories and binaries aren't writeable by a 'daemon' uid process there shouldn't be a lot that could be damaged. Steven Schultz CONTEL Federal Systems IMSD 31717 La Tienda Westlake Village CA 91359-5027 Internet: sms@etn-wlv.eaton.com
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/11/88)
In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim
Abdullah) writes:
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
privileges, 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.
[ He goes on to explain the infinite recursion assuming the
cracker is smart and you realize it. And ... gets modified
so some other program won't fink, recurisively. ]
Yes, after Ken told me about the C compiler and then the NSA
tiger team broke su and had a setuid root shell squirreled away,
I thought a lot about that.
1). You need a read-only copy of the original distribution.
[Begging the question of can you trust the vendor. ]
2). Or, in advance build a disk with trusted utilities and a
unix to use.
3). Have a package audit program [such as the one I have written
at ATT] that verifies checksums. Compute check sums in a special
way. We have a psum that check sums only the text and data part
of a a.out (no headers or symbols).
4). Use a better check sum program. I have an unspoofable check
summer. It encrypts the file with cypher block chaining and
keeps the last [enciphered block] 64 bit result as the check sum.
In normal use it has a built in encryption key. But one can also
provide a private key. Hence the set of possible checksum is
unknowable in advance [ one could compute check sums for all
possible keys I suppose, but life is short]. Thus one can't
diddle a file and fix it to have the correct size and the correct
public checksum and the correct private checksum.
--
=Dennis L. Mumaugh
Lisle, IL ...!{att,lll-crg}!cuuxb!dlm OR cuuxb!dlm@arpa.att.comchilders@avsd.UUCP (Richard Childers) (11/12/88)
In article <7080011@eecs.nwu.edu> naim@eecs.nwu.edu (Naim Abdullah) writes: >In PRINCIPLE "ls -l" is not enough. The worm had root privs, 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. I thought about this a long time ago, back when I first realized that given a source license, one could be the source of a lot of trouble. I was just starting as a system administrator, and so I didn't do anything fancy - I made a script that used checksums generated from binaries off the tape and stored a backup of the script on another tape. A variation on this theme reports drift from network mean on the part of any critical file on any critical machine ( 'critical' meaning 'important enough for me to install this silly-assed paranoid script on' ) and keeps backup copies at a secret location. If someone wants to play those games, they're going to have to work harder than I am already. >In such a situation, you would have no inkling that there was anything >wrong. Assume the worst from the first, then you won't be surprised. >This kind of paranioa isn't worth it ... It's saved me hours of work on a monthly basis for years. > Naim Abdullah -- richard
tencati%jplgp.span@VLSI.JPL.NASA.GOV (11/15/88)
A "Benevolent Worm"? Cheers, Ron Tencati /JPL