Xref: utzoo comp.protocols.tcp-ip:11665 alt.sys.sun:971 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!oliveb!tymix!tardis!jms From: jms@tardis.Tymnet.COM (Joe Smith) Newsgroups: comp.protocols.tcp-ip,alt.sys.sun Subject: Re: tftp (was Re: anonymous ftp, and the dangers thereof) Summary: tftp already does a chroot. Message-ID: <1130@tardis.Tymnet.COM> Date: 11 Jun 90 09:56:30 GMT References: <1990Apr20.192233.4092@utzoo.uucp> <6721@blake.acs.washington.edu> <3023@unisoft.UUCP> Reply-To: jms@tardis.Tymnet.COM (Joe Smith) Organization: BT Tymnet, San Jose, CA Lines: 22 In article rang@cs.wisc.edu (Anton Rang) writes: >In article <3023@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: : At a minimum, you should restrict either which hosts can access tftp :on a given machine, or which files tftp can access. The problem is :that tftp, as distributed, lets anyone access any publicly-readable :file, and lots of important files (like /etc/passwd) are publicly :readable. (In other words, having tftp enabled allows dictionary :attacks to be tried without needing an account on the remote machine.) : This is my understanding of the matter, at least; feel free to :correct any misapprehensions. As distributed from Sun, tftp does NOT allow access to /etc/passwd. It does a chroot to /tftpboot first. This means that if you attempt to read /etc/passwd, the kernel translates it to /tftpboot/etc/passwd, which does not exist. The chroot call also means that ".." cannot be used to get out of set directory. See "man 2 chroot". -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."