Bugtraq mailing list archives
Re: security hole in mget (in ftp client)
From: jim () CALIFORNIA SANDIA GOV (Jim Hutchins)
Date: Tue, 12 Aug 1997 09:17:04 -0700
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
Current thread:
- security hole in mget (in ftp client) mhpower () MIT EDU (Aug 04)
- <Possible follow-ups>
- Re: security hole in mget (in ftp client) der Mouse (Aug 05)
- Re: security hole in mget (in ftp client) Jim Hutchins (Aug 12)