How to stop future viruses.

[Dennis L. Mumaugh]

In article <16722 at agate.BERKELEY.EDU> greg at math.Berkeley.EDU (Greg) writes:
     Now that we've killed all copies of the Internet  virus  and
     fixed sendmail and fingerd,  it's  time  to  thinking  about
     stopping future viruses.

     Here is some of what needs to be done

1.  Protect the password file.

     On most Unix systems that I've seen, /etc/passwd is publicly
     readable.  There  is  no  reason  for this.  It's amusing to
     have encrypted passwords that anyone can look at,  but  it's
     also  a  security  hole.   Undoubtedly,  the  virus  guessed
     passwords  by  reading  the  password  file   directly   and
     encrypting  on  its  own.  Make  the  virus  work  to  guess
     passwords.

This problem was announced in  1976  and  fixed  in  most  secure
systems  [I did it for NSA].  ATT has shadow (hidden) passwords
in System V Relase 3.2.  Other vendors: go thou and do  likewise.
The  ONLY  problem,  applications  programs  can't  use  password
validation for authentication then.  Of course a Yellow Pages RPC
call could be used: 
	isvalidpasswd(use, passwd);

2.  Strengthen crypt(3).

     The password encryption routine, crypt(3), uses DES, a sound
     encryption  algorithm.  However,  one of the design goals of
     crypt(3) was  to  retard  password  guessing,  and  in  this
     direction  it  has misfeatures.  The routine is deliberately
     unoptimized to be slow.  Still, one DES pass  was  too  fast
     for  comfort, so the routine encrypts a blank field with the
     password as key 25 times.

     This is the wrong approach.  The virus either did  or  could
     have   had   a   private,   optimized   encryption  routine.
     Furthermore,  the  virus  had  substantial  computer   power
     available, typically a whole ring of suns, to attack a given
     password file.  I am told that someone has  written  a  fast
     crypt(3)  that  encrypts  40  passwords per second, which is
     fast enough to encrypt /usr/dict/words in 1 minute on a ring
     of 10 suns.

     The obvious solution is to  optimize  crypt(3)  as  much  as
     possible,  and  then decide how many encryption passes there
     should be.  Since 40  x  25  =  1000,  I  recommend  several
     thousand  passes.  For good measure it could encrypt a block
     larger than a 8-byte blank field.  For  example,  you  could
     chain encrypt a longer string of bytes and put a checksum of
     the string in /etc/password.

Still a bad approach.  A work factor assumes that one has  do  do
this  on  line.  When  Ken  Thompson  did  his password attack he
sucked the password file back to  his  home  system  and  did  it
there.  [Nowdays  one  could  use a CRAY]. When I did my password
attacks I  encrypted  the  dictionary  FIRST.  Then  it  was  one
encrypt  and  a fgrep.  From start to finish (copy of /etc/passwd
until printing of list of lognames and password was 45 minutes!).


3.  Protect home directories.

     Like the password file, home user directories  are  publicly
     readable  by  default on a lot of Unix machines.  This virus
     learned hostnames from checking .rhosts  files.  A  stronger
     virus  could  also  analyze  mbox  files  and  make  keyword
     searches.  User files could let it know which user passwords
     are valuable and which are a waste of time.

     The read status of user directories is the most obvious  and
     inviting  Unix  security  bug  there is.  In addition to its
     utility to viruses, it allows even unskilled users to snoop,
     and  it  demonstrates  to  them  that Unix security is poor.
     It's time to change  the  default  setting  for  the  access
     status of home directories.

Umask was invented for this purpose!  In a paranoid  installation
umask is set to 077.  Super paranoid it is 0777!

4.  Eliminate unnecessary .rhosts files

     This virus only used .rhosts files to learn host  names  and
     user names.  It could have made the likely inference that if
     Amy is in Tom's .rhosts file, Tom is in Amy's  .rhosts  file
     too.  But it didn't do that.

     .rhosts files are very convenient, but they make us place  a
     lot of trust in other computers on the network.  Old .rhosts
     files are dry tinder waiting to catch fire.  We should  have
     default  expirations  of  .rhosts  entries between different
     sites.

See comments previously on the net about the breakin at  Stanford
two years ago.   See also below.


I might add:

5.  Programs to search the file system for "suspicious" events.

I have a package audit to very permissions, ownershps, lenght and
check  sum  of  a  set of files. [Sorry, ATT Proprietary.] I have
designs of others to check for corruped files [more severe  check
sums -- can't be forged] and look for security holes.

There are companies that sell similar security suites.  There are
books that explain and give shell scripts.

Security is requires active  and  continuing  work  by  a  system
administrator.  All  the  security  mechanisms and protections in
the world won't help if the system administrator is unwilling  to
use them.  Nor, if the system administrator makes a mistake.  Or,
if some one delibately unprocts things.
-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm at arpa.att.com