minor security hole (tftp)

[Jim Helman]

-----------
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 at kaos.stanford.edu) 			(415) 723-4940	

Jim Helman
Department of Applied Physics			P.O. Box 10494
Stanford University				Stanford, CA 94309
(jim at thrush.stanford.edu) 			(415) 723-4940