Xref: utzoo news.sysadmin:1260 comp.unix.wizards:12245 Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!rutgers!iuvax!inuxc!att!cuuxb!dlm From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) Newsgroups: news.sysadmin,comp.unix.wizards Subject: Re: How to stop future viruses. Summary: some people have already done the recommendations Message-ID: <2178@cuuxb.ATT.COM> Date: 9 Nov 88 16:49:14 GMT References: <16722@agate.BERKELEY.EDU> Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh) Organization: ATT Data Systems Group, Lisle, Ill. Lines: 117 In article <16722@agate.BERKELEY.EDU> greg@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@arpa.att.com