The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #296 [revised tftpd writeup] (1 message, 1423 bytes)
NOTICE: recognises the rights of all third-party works.


To: [not phage]
Date: Wed 10:01:41 23/11/1988 EST
Subject: revised tftpd writeup
References: [Thread Prev: 411] [Thread Next: 298] [Message Prev: 411] [Message Next: 297]

	On some BSD systems, the "tftpd" daemon is an old security hole that is
	nonetheless sometimes overlooked.  Exact details of *why* this daemon
	is a risk to system security are beyond the scope of this mailing list.
	However, the means to minimize "tftpd" risks are not.

	- Systems which are *NOT* boot servers for diskless clients.

	    The "tftpd" daemon may be safely disabled on these systems.
	    To do so, modify the file /etc/services by commenting out the
	    "tftp" line, i.e.
		#tftp            69/udp

	    If your system contains the file /etc/inetd.conf, you must also
	    comment out the line
		#tftp    dgram   udp     wait    root 	...

	- Systems which *ARE* boot servers for diskless clients:

	    The "tftpd" daemon can not be disabled on these systems.

	    To minimize security risks, it is suggested that the boot server
	    have the smallest possible /etc/passwd file (I am not certain, but
	    I believe "root" and "nobody" may be the only required user names)
	    with the line
	    at the bottom.  The remaining user names must be stored on another
	    system, and referenced by the boot server via Yellow Pages.  Note
	    that, by implication, "ypserv" may not run from the boot server.

	    If your boot server is the only system on your network with a disk,
	    the above procedure will not work.  An admittedly kludge workaround
	    may be accomplished by
		a) creating a new group (e.g. "omni") in /etc/groups,
		b) placing all users (except "nobody") into that group,
		c) chgrp omni /etc/passwd
		d) chmod 640 /etc/passwd
	    which will keep the /etc/passwd file from being readable by tftpd.

	    Gene Spafford (Purdue) suggested two other alternatives for
	    people who have sources:

		"A third alternative is to hack tftp to read a list of host IP
		 numbers from which it will accept connections.  Otherwise, it
		 won't sustain a connection.  The list can be stored somewhere
		 secure.  This requires source code, of course.

		"A fourth alternative is to hack tftp to do a chroot call, and
		 put the (limited) set of files you allow to be copied in the
		 restricted directory.  This is similar to the technique used
		 with ftp.  It too requires source code.

		"Of all the methods, I think #3 is preferable, since it doesn't
		 require that you update anything except a list of "trusted"
		 tftp clients."

								Tony Nardo

	[Special thanks to Gene Spafford, who clarified some misunderstandings
	 I had regarding "tftp" and "tftpd" as well as providing alternate
	 solutions to the problem.]