(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