helman@isl.Stanford.EDU (Jim Helman) (10/31/89)
----------- After last fall's Internet worm, there was a flurry of people pointing out all sorts of security holes, big and small. Not surprisingly, now, almost a year later, most sysadmins (at least in Universities) have gone back to sleep. One of the small dangers pointed out last year was unrestricted tftp access. tftp uses the Trivial File Transfer Protocol (RFC 783), which is like ftp, but, well, more trivial. In particular, it requires no user authentication. The problem is that tftp allows anyone on your net, which in our case means the entire Internet, to access publicly readable files, including /etc/passwd. Also, there is a lesser risk from writing to publicly writable files. Actually, most machines have no need for tftp at all. Some need it when acting as a bootfile server, but this function only requires access to a few files, certainly not to every publicly readable file on a machine, which is the default. After the worm incident, I was surprised to see that SGI was still distributing IRIX configured for unrestricted tftp. I called it in as a bug report on 3.1D back in June. The support engineer seemed concerned about it, but it didn't change in 3.1G. We just got 3.2, and once again the installation procedure renabled unrestricted tftp. This may seem to be a very minor hole, but a surprising number of sysadmins create new accounts without passwords and users never get around to setting a password. Also, many encrypted passwords can be broken by dictionary searches. Worse still, some sloppy sysadmins leave field or diag accounts without passwords. For example, the first IRIS machine at Stanford to which I tftp'ed had an account with no password, a uid of 0, and /bin/csh as its shell. Very bad. Possible Solutions: If you don't need tftp, the easiest thing to do is to comment out the tftpd line in /usr/etc/inetd.conf. Be sure to repeat this after every software upgrade. But if you do need tftp, read on. In Sun's standard inetd.conf (SunOS 4.0 and later), tftp's access is restricted to the /tftpboot directory using a new -s switch they added to tftpd. I don't think SGI's tftpd has such a switch. Prior to 4.0, Sun distributed a tftpbootd as an alternative to the tftpd daemon. tftpbootd was a shell script which did a "chroot /tftpboot /usr/etc/tftpd," which restricted tftpd activities to a directory tree containing the bootfiles. The same trick will work under IRIX. However, if you try this trick and haven't used chroot before, be careful because you must: 1) Put a copy of /tftpd in <tftproot>/usr/etc/tftpd since chroot needs all executables under tftp's new root directory. You should do the same for /dev/console and /dev/log which might be accessed by tftpd. 2) Put a copy or hard link of the shared library /lib/libc_s in <tftproot>/lib/libc_s. 3) Have chroot execute as root (chroot won't run otherwise, for obvious security reasons). So change the "guest" on the line in inetd.conf to "root" and then change the ownership of <tftproot>/usr/etc/tftpd to "guest" and turn on the setuid bit. If you're not sure what to do, I'd suggest calling the hotline. I'm sure someone at SGI can provide a more complete solution. Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@kaos.stanford.edu) (415) 723-4940 Jim Helman Department of Applied Physics P.O. Box 10494 Stanford University Stanford, CA 94309 (jim@thrush.stanford.edu) (415) 723-4940