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 #300 [Re: revised tftpd writeup] (1 message, 1026 bytes)
NOTICE: recognises the rights of all third-party works.


From: (Gary Winiger)
To: phage
Date: Fri 14:10:19 25/11/1988 EST
Subject: Re: revised tftpd writeup
References: [Thread Prev: 305] [Thread Next: 297] [Message Prev: 305] [Message Next: 301]

>	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.
[text deleted]
>	    people who have sources:
[text deleted]
>		"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.
>								Tony Nardo

	On SunOS 4.0 the tftpd daemon has a ``-s'' option which will take the
next parameter as a root directory for a chroot(2) call.  The daemon also is
coded to set the uid and gid to -2 (nobody).  Unfortunately the programmer
didn't check the return code from the set{uid,gid} system calls.  The sets
are failing due to missing casts on the -2 parameters.  The system calls
check to make sure that the parameter recieved has a value in the unsigned
short range (-1 is special cased).

	SunOS MLS (a B1 complient version of SunOS) has this bug fixed and
further requires that all access to tftp be done at ``system_low'' (the lowest
possible label of the system).  ``System_low'' is the label associated with
public information, and by definition (even in the RFC), since there is no
possible authentication, tftp is restricted to public information.

P.S.  A bug report has been filed to fix the coding error in a future SunOS