der mouse writes:
> >> it is possible to trick the client into executing arbitrary code on
> >> the client's machine by returning a filename such as '|sh', whose
> >> contents are the list of shell commands to execute.
> 
> >> Suggested fix:
> >> modify recvrequest() to take an extra argument, which means "ignore
> >> special names such as '-' and '|*'".  use this flag when calling
> >> recvrequest() from mget().  I've done this, and it appears to work.
> 
> > On second thought I don't think this is ideal: you also, if possible,
> > want to protect against someone seeing a file called '|sh' on an ftp
> > server and trying to get it.  If you do "get |sh", at present, the
> > contents of the file on the server will be piped to sh since get
> > copies its argv[1] to argv[2] if the user doesn't supply one.
> 
> So, you need to make sure that if argv[2] comes from _anywhere_ other
> than the user explicitly supplying it to a get command (eg, an mget, or
> via the automatic copy from argv[1] on a get), special characters like
> | get ignored.

I've just made this mod as well. If you have a file called '|sh' that
you truely want to execute, you must do
	get |sh |sh
If you just do "get |sh" then a file called "|sh" will be retreived.


> > Additionally, everything that mget generates should have ".." path
> > elements filtered out.
> 
> I don't like this because, as you point out, it breaks "mget ../*.c",
> and (much more plausibly) "mget ../ksrc/ksrc*".
> 
> Ideally, what I'd like here is a three-way switch that controls what to
> do with "dubious" pathnames, such as those beginning with / or
> containing .. components: it could be set to "error out" (refuse to get
> the file), "accept" (trust it), or "prompt" (ask the user).  And at the
> prompt, the user should be able to switch it into either of the other
> modes either for the remainder of the current operation or as if from
> the ftp> prompt.
> 
> Not that I really expect to get that, unless I find time to implement
> it myself.  Coming up with fixes is easy for people who don't have to
> implement them. :-)

I'll think about this, pending input from others...