Xref: utzoo news.groups:6208 news.sysadmin:1482
Path: utzoo!attcan!uunet!husc6!think!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ncar!tank!mimsy!aplcen!bright
From: bright@aplcen.apl.jhu.edu (Jonathan Bright)
Newsgroups: news.groups,news.sysadmin
Subject: who, me?
Keywords: security, virus, summer job
Message-ID: <247@aplcen.apl.jhu.edu>
Date: 15 Nov 88 02:33:29 GMT
Reply-To: bright@aplcen.UUCP (Jonathan Bright)
Organization: Johns Hopkins University/CPP, Laurel, MD
Lines: 63

I've just thought up of a little scenario for what the virus
could have done if Robert Morris had decided that he really wanted
to cause people problems.  I am certainly very glad that he didn't do
this, but I'm trying to make the point that somebody he could of.

1) The virus spreads rapidly without being noticed to a lot of machines.

2) Instead of just keeping a copy of itself on the host and trying to
reproduce, it would install it's own version of dump and restore on the host. 
For the next n months, whenever a file was dumped it would be encoded with
some password,  and the password would be hidden in some file on the host
machine.  Whenever somebody wanted to restore a file, the bogus restore would
find the password for the file, and decode the file.

3) Then after some predetermined signal, all the viruses would remove the
decoding passwords from the system and trash the file system.

Sure, the guy would probably be roasted for doing this (assuming they
caught him, which he could easily prevent by writing this program 
using an account that wasn't his on a a machine that he had no connections
to).  But there are thousands of hackers out there, and I would find it
hard to believe that there isn't 1 who has some sort of reason to do this.

--------
Just some mental notes on some simple things that could be done to help
security. (for berkeley)
1) remove .rhosts files.
2) put the encoded passwords where nobody can read them, and then
introduce a system call "verifypasswd(user,passwd)" which would log
usages and would take a while to run.  Sure, a lot of stuff would have
to be rewritten, but it would be worth it.
3) protect "/dev/mem" and "/dev/kmem" files on all machines.  This is
done by making mem and kmem readable by group mem, and then have "top"
and "w" and other such programs set group id mem.
4) On berkeley unix, because of the ioctl(fd,TIOCSTI) having terminals
writable is a big bug (see man 4 tty for details).  Mesg should
set world execute bit instead of world write bit to signal that the
person wants to receive messages, and then run as suid root (or some
variation of this).  (God, posting this just killed me...)
5) No important directories (/etc, /bin etc...) should be be writable
by group staff or any other group.  
6) If you have several computers that have to communicate with the
outside world, make one of them run the deamons in /etc/services to recieve
files from other machines, but don't have the others honor any such
requests.  
7) Vendors of unix systems should take some responsibility and make
the programs they distribute more secure.  This means hiring somebody
at 30k and having them work full time finding and fixing security
bugs.

I know of other more specific security problems with unix, but
hey, I can't give away all of what I know... (and figured out by
myself, especially). :-)

Jon Bright

My real mail address is "bright@crabcake.cs.jhu.edu"

P.S. I know unix fairly well, and I'd be interested working with unix
over the summer (preferably in the baltimore area). :-)

P.P.S. This is one of the first times I've ever posted to the net,
so please excuse me if I did something wrong...