Bugtraq mailing list archives
security hole in mget (in ftp client)
From: mhpower () MIT EDU (mhpower () MIT EDU)
Date: Tue, 5 Aug 1997 02:47:30 EDT
On most Unix platforms, when an ftp client processes an mget command, it does not check whether the ftp server's response to the NLST command specifies any directory information along with the simple list of filenames required by the ftp protocol (RFC 959, section 4.1.3). In particular, a malicious ftp server's NLST response might include lines such as "../.forward", which may be useful in a later attack on the client machine by someone who has control over the ftp server. (Instead of .forward, one might also choose .profile, .cshrc, or .rhosts. NLST response lines beginning with '/' also work, which is of particular interest in cases where the ftp client is running as root.) For example, if the client's session looks something like % mkdir test % cd ~/test % ftp malicious-ftp-server ... ftp> dir ... total 560 -rw-r--r-- 1 103 22 106975 Jul 11 02:13 docs.tar.gz -rw-r--r-- 1 103 22 452337 Jul 11 02:12 source.tar.gz 226 Transfer complete. ... ftp> prompt Interactive mode off. ftp> mget . there's no guarantee that the files created on the client machine will be limited to docs.tar.gz and source.tar.gz in the current directory. Instead, files might be created anywhere where the client user has write access, possibly including overwriting existing files. When setting up a malicious ftp server, it would probably be most "useful" to have a directory that contained a large number of small files, and arrange for the NLST response to contain ../.forward somewhere in the middle. In this way, the ../.forward line is not noticeable when the mget operation begins, and will probably have scrolled off the user's screen by the time the mget operation finishes. Thus, the client user won't realize that this file has been created unless they carefully read the entire mget output. Choosing a pathname other than ../.forward may be helpful if you don't agree that client users most typically start ftp sessions from a directory exactly one level beneath their home directory. Also, the ftp server does not necessarily need to send the contents of a file named ../.forward in response to a "RETR ../.forward" command. Instead, the ftp server may have been modified to send other text, perhaps text that isn't contained in any file accessible via ftp. Presumably, the text will begin with '|' so that there's some chance that sending e-mail to the client will be successful in causing some arbitrary command to be run. (And, I suppose if you're going to write something to .forward, you might want to write it to .qmail as well.) I did find one exception. With the AIX 3.2 ftp client, the mget did not create ../.forward, but instead created a .forward file in the client's current directory. Similarly, with an AIX ftp client running as root, and an NLST response line of /etc/passwd, it created a file named passwd in the current directory. In other words, it's possible, although not confirmed, that AIX is not at all vulnerable to this problem. The 10 other Unix platforms that I tried were all vulnerable. Perhaps the easiest solution is to fix the ftp client to ignore lines in an NLST response that include a '/' character. Until your ftp client is fixed, it would be best to avoid doing non-interactive mgets from any ftp server that isn't known to be trustworthy. One might initially think that a useful workaround is to examine the server's NLST output by issuing the command "ls" (rather than only "dir") before transferring any files. The problem here is that the ftp server might have a time-varying NLST response (e.g., possibly it includes the line ../.forward only the second time that NLST is sent). Matt Power mhpower () mit edu
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)