Re: security hole in mget (in ftp client) (fwd)

[John Goerzen <jgoerzen@complete.org>]

I feel strange replying to my own message, but:

We have several other clients:
  xftp
  llnlxftp?
  filerunner

I maintain filerunner and would like to test it but I do not know how
to set up a server to send the necessary responses, and I do not want
to have to write a whole program to test it.  So can somebody either
point me to a server that I can test it with or test it for me?

Thanks.

John Goerzen <jgoerzen@onyx.southwind.net> writes:

> We have at least three clients -- ftp, ncftp, lftp.  Might be a good idea
> to check all of them.
> 
> John Goerzen, Running FREE Debian | Developer for Debian GNU/Linux
> jgoerzen@southwind.net            | Asst. sysadmin, Wichita State CS Dept.
> jgoerzen@gesundheit.cs.twsu.edu   | All opinions are stricly my own
> jgoerzen@complete.org [Owner, the Communications Centre (complete.org)]
> ---------- Forwarded message ----------
> Date: Tue, 5 Aug 1997 02:47:30 EDT
> From: mhpower@MIT.EDU
> To: BUGTRAQ@NETSPACE.ORG
> Subject: security hole in mget (in ftp client)
> 
> 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
> 
> 
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> debian-private-request@lists.debian.org . 
> Trouble?  e-mail to templin@bucknell.edu .
> 

-- 
John Goerzen          | Running Debian GNU/Linux (www.debian.org)
Custom Programming    | Do YOU need more Speed, Power, and Reliability?
jgoerzen@complete.org | Check out http://www.debian.org NOW!
----------------------+----------------------------------------------
Notice: You may purchase the right to send me unsolicited commercial e-mail
("spam") for the fee of $500 (USD) per message.  Billing can be either
pre-arranged or can occur automatically after the reception of a spam.
Failure to pay will be treated in accordance to US Code, title 47, sec. 227,
which allows unsolicited e-mail to be punishable by action to recover actual
monetary loss or $500, whichever is greater, per violation.  Sending spam
to me without payment constitutes unauthorized access to my mail daemon,
which is in violation of federal law.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .