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

From: "Homer W. Smith" <[email-masked]>
Date: Tue, 12 Aug 1997 19:10:35 -0400 (EDT)

This make any sense to anyone?

------------------------------------------------------------------------
Homer Wilson Smith     News, Web, Telnet      Art Matrix - Lightlink
(607) 277-0959         E-mail, FTP, Shell     Internet Access, Ithaca NY
[email-masked]    [email-masked]     http://www.lightlink.com

---------- Forwarded message ----------
Date: Tue, 12 Aug 1997 16:56:34 -0400 (EDT)
From: Max Parke <[email-masked]>
To: System Group <[email-masked]>
Subject: Re: security hole in mget (in ftp client) (fwd)

This is an evil one...  Don't know if it affects ncftp, Kim.

The moral of the story is don't use mget, or if you do, run the ftp client
from a non-privileged account, definitely not root...

Max

---------- Forwarded message ----------
Date: Tue, 12 Aug 1997 09:17:04 -0700
From: Jim Hutchins <[email-masked]>
To: [email-masked]
Subject: Re: security hole in mget (in ftp client)

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

---

From: [email-masked] (Andy Church)
Date: Tue, 12 Aug 1997 19:38:37 EDT

>    This make any sense to anyone?

[bugtraq forward deleted]

     Well, as the subject says, it's a client issue, not a server one.
You'd need a much-hacked server to do some of the things suggested, like
including a ../file in an arbitrary NLST, though the ability to create a
file with a name like |sh renders that moot.  There's not much you could do
from the server side, except perhaps not list filenames beginning with
characters like | which are special to FTP clients, and that might not be a
good thing anyway.  (For the record, ncftp, at least version 1.9.4, also
handles files like |sh with pipes.  It was probably originally intended as
a feature, but it's too easily exploitable in my opinion.)

  --Andy Church                  | If Bell Atlantic really is the heart
    [email-masked]       | of communication, then it desperately
    www.dragonfire.net/~achurch/ | needs a quadruple bypass.