Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!math!greg
From: greg@oreo.berkeley.edu (Greg)
Newsgroups: news.sysadmin
Subject: How to stop future viruses.
Message-ID: <16722@agate.BERKELEY.EDU>
Date: 9 Nov 88 04:36:47 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: greg@math.Berkeley.EDU (Greg)
Organization: UC Berkeley
Lines: 68

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.
I'm sure that this virus is an inspiration and a dare to a lot of bored
hackers out there.  The fact is that the virus missed a lot of opportunities
for infiltration, opportunities that any determined programmer could
recognize.  Despite these imperfections, and despite crashing many of the
systems it spread to, it spread to 6,000 sites in 18 hours.  Without
its fatal bug, it would have gone everywhere within a week or two.

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.

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.

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.

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