Xref: utzoo comp.protocols.tcp-ip:5285 comp.unix.wizards:12313
Path: utzoo!attcan!uunet!husc6!ukma!tut.cis.ohio-state.edu!osu-cis!att!cuuxb!dlm
From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
Subject: Re: And You Thought You Were Paranoid...
Summary: ls -l isn't sufficient
Keywords: security audit checksum
Message-ID: <2184@cuuxb.ATT.COM>
Date: 10 Nov 88 22:34:59 GMT
References: <7080011@eecs.nwu.edu>
Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Organization: ATT Data Systems Group, Lisle, Ill.
Lines: 54

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.com