[5150] in bugtraq
Re: security hole in mget (in ftp client)
daemon@ATHENA.MIT.EDU (Jim Hutchins)
Tue Aug 12 17:06:47 1997
Date: Tue, 12 Aug 1997 09:17:04 -0700
Reply-To: Jim Hutchins <jim@CALIFORNIA.SANDIA.GOV>
From: Jim Hutchins <jim@CALIFORNIA.SANDIA.GOV>
To: BUGTRAQ@NETSPACE.ORG
der Mouse wrote:
>> On most Unix platforms, when an ftp client processes an mget command,
>> it does not check [...for evilness like:] In particular, a malicious
>> ftp server's NLST response might include lines such as "../.forward",
>
>> Perhaps the easiest solution is to fix the ftp client to ignore lines
>> in an NLST response that include a '/' character.
>
>I rather dislike this. It's too useful to "mget */*.??" and the like.
>
>I'd rather see it refuse, or at least confirm, paths beginning with
>"../" or including "/../". One could argue the client should accept a
>leading ../ when the user specified a leading ../, but that's probably
>getting a little too frilly. (Of course, this should all be
>configurable off, but it also should default on.)
The problem is a bit worse than just including files in the NLST with
a leading '..' or '/'. If the server sends a list which includes a
filename that starts with the pipe symbol, the UNIX client will happily
start the specified program and execute it, feeding the "data" to the
program as stdin. How about a file, imbedded in a large directory with
a lot of small files, called "|sh"? And there are one or two other special
characters to FTP, so it looks like even more filename checking is
necessary.
Jim Hutchins
Sandia National Labs, California
