[89] in Best-of-Security
BoS: tftp bug (bad one) - does this effect inet6 apps ?
daemon@ATHENA.MIT.EDU (Alan Cox)
Sun Mar 23 20:50:43 1997
From: Alan Cox <alan@cymru.net>
Date: Sun, 23 Mar 1997 20:14:23 +0000 (GMT)
Reply-To: best-of-security@suburbia.net
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net
Forwarded message:
> From linux-alert-request@redhat.com Sun Mar 23 19:03:45 1997
> Resent-Date: 23 Mar 1997 18:57:40 -0000
> Resent-Cc: "recipient.list.not.shown":;
> MBOX-Line: From linux-alert-request@redhat.com Sun Mar 23 13:57:37 1997
> Date: Sun, 23 Mar 1997 09:11:34 -0800 (PST)
> From: Alex Belits <abelits@phobos.illtel.denver.co.us>
> Reply-To: Alex Belits <abelits@phobos.illtel.denver.co.us>
> To: linux-security@redhat.com
> Cc: linux-alert@redhat.com
> In-Reply-To: <199703230052.RAA17444@rintintin.Colorado.EDU>
> Message-ID: <Pine.LNX.3.95.970323062449.9204A-100000@phobos.illtel.denver.co.us>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Resent-Message-ID: <"1USBb1.0.xn2.XqNDp"@mail2.redhat.com>
> Resent-From: linux-alert@redhat.com
> X-Mailing-List: <linux-alert@redhat.com> archive/latest/19
> X-Loop: linux-alert@redhat.com
> Precedence: list
> Resent-Sender: linux-alert-request@redhat.com
> Subject: [linux-alert] Re: [linux-security] tftpd bug (was: "Secure" tftpd source for Linux?)
>
>
>
> [Mod: David Holland's message added to the back, linux-alert added to the
> list of addresses -- alex]
>
> On Sat, 22 Mar 1997, Ben Cantrick wrote:
>
> > It's a cute little hack, and it seems to work. But I am convinced that
> > someone must have seen the need and done this before. My extended forays
> > into the web via several search engines have failed to turn up anything
> > relevant. So I'm curious if anyone on the list knows of (or better, has)
> > freely distributable source for a "secure" tftpd.
>
> tftpd in FreeBSD distribution uses chroot() and sets its uid to nobody.
> I don't think, it does anything reasonable with groups.
>
> But... I've looked at both Linux (NetKit 0.09) and FreeBSD (2.2-ALPHA)
> tftpd and found rather strange code in Linux tftpd's validate_access()
> function:
>
> ---8<---
> syslog(LOG_ERR, "tftpd: trying to get file: %s\n", filename);
>
> if (*filename != '/') {
> syslog(LOG_ERR, "tftpd: serving file from %s\n", dirs[0]);
> chdir(dirs[0]);
> } else {
> for (dirp = dirs; *dirp; dirp++)
> if (strncmp(filename, *dirp, strlen(*dirp)) == 0)
> break;
> if (*dirp==0 && dirp!=dirs)
> return (EACCESS);
> }
> /*
> * prevent tricksters from getting around the directory restrictions
> */
> for (cp = filename + 1; *cp; cp++)
> if(*cp == '.' && strncmp(cp-1, "/../", 4) == 0)
> return(EACCESS);
>
>
> --->8---
>
> ...it checks _only_ for "/../" and start _always_ from the second
> character in the filename (in other words, if filename is empty, it will
> "analyze" the memory after it where other piece of code places mode, so at
> least it won't do anything destructive). But it also assumes all not
> starting from '/' filenames to be relative to some directory, and never
> checks them for "../" that FreeBSD one does. So (see code above for
> locations of calls to syslog()):
>
> ---8<---
> Mar 23 06:55:08 phobos in.tftpd[9799]: connect from phobos.illtel.denver.co.us
> Mar 23 06:55:08 phobos tftpd[9800]: tftpd: trying to get file: ../etc/passwd
> Mar 23 06:55:08 phobos tftpd[9800]: tftpd: serving file from /tftpboot
> --->8---
>
> ...and obviously it was /tftpboot/../etc/passwd aka /etc/passwd
>
> Not that it does any damage by itself, but it definitely wasn't supposed
> to do that. FreeBSD tftpd disallows such things.
>
> According to copyright notices, both tftpd are derived from some old
> (1983) Berkeley code, and Linux one has some general clumsiness all over
> its code (and default /tftpboot directory didn't exist until 0.09, 0.08
> seems to require the list of directories, or it will just SIGSEGV
> on NULL pointer).
>
> FreeBSD tftpd compiles with command line:
>
> gcc -O -DLOG_FTP=LOG_DAEMON -o tftpd tftpd.c tftpsubs.c
>
> and works fine if -ls /tftpboot is added as options to its command line.
> Otherwise it only checks file permissions without even trying to become
> "nobody" and thus opens hole for non-executable directories (even if
> directory is non-executable for anyone but root, files in it will be
> accessible). Also it's necessary to hardlink /dev/log under chroot
> directory to keep logging functional.
>
> --
> Alex
>
> P.S. how such umm... not obviously secure code got into tftpd in the first
> place after that many revisions that definitely were done to increase
> security? After all, changes between NetKit revisions _do_ make sense.
>
> Return-Path: dholland@hcs.harvard.edu
>
> > [tftpd source mapped to /dev/null]
> >
> > Finally, it prevents ".." and "." in filename to be used to go up:
>
> He's right; it doesn't block leading ".." in the case where the
> filename doesn't begin with "/".
>
> Someone already caught this and the fix is going to be in the next
> release; in the meantime here's a patch.
>
> > > P.S. how such umm... not obviously secure code got into tftpd in the first
> > > place after that many revisions that definitely were done to increase
> > > security? After all, changes between NetKit revisions _do_ make sense.
>
> It needs an intensive rewrite. Don't hold your breath... :(
>
>
> *** tftpd.c 1996/12/29 18:42:40 1.8
> --- tftpd.c 1997/03/08 11:31:00
> ***************
> *** 40,44 ****
> */
> char rcsid[] =
> ! "$Id: tftpd.c,v 1.8 1996/12/29 18:42:40 dholland Exp $";
>
> /*
> --- 40,44 ----
> */
> char rcsid[] =
> ! "$Id: tftpd.c,v 1.9 1997/03/08 11:30:30 dholland Exp $";
>
> /*
> ***************
> *** 298,301 ****
> --- 298,303 ----
> * prevent tricksters from getting around the directory restrictions
> */
> + if (!strncmp(filename, "../", 3))
> + return EACCESS;
> for (cp = filename + 1; *cp; cp++)
> if(*cp == '.' && strncmp(cp-1, "/../", 4) == 0)
>
>
> --
> - David A. Holland | Number of words in the English language that
> dholland@eecs.harvard.edu | exist because of typos or misreadings: 381
>
