Re: New draft-draft of sftp...

[Simon Tatham <anakin%pobox.com@localhost>]

Jeffrey Altman <jaltman%columbia.edu@localhost> wrote:

> Exactly.  Which goes directly to reason why globbing must be done on
> the system on which the file system is mounted.  It is only on that
> system that the appropriate matches can be done by the file system.
> Trying to guess what the file system is capable or not capable of will
> only produce inaccurate results.

But this is only one side of the story. The other side is the user
expectations, and the security angle.

SCP is a good example of a protocol that does server-side globbing,
and it's one most people on this list will have heard of :-) So
suppose I'm an SCP user and I type a command such as

  scp myserver:[abc]*.* .

to retrieve some files matching a wildcard, and copy them into my
current directory. The server will now send back a list of file
names and file contents, and my client program will create some
files locally.

What's to stop the server sending back a filename which _doesn't_
match the wildcard? Suppose it sends back `/etc/passwd'. Well,
obviously my client can exercise minimal common sense and outlaw any
inbound filename which contains a slash. But if it sends back some
filename which _wasn't_ within the space of possible names I was
expecting, then it can overwrite some local file I didn't want
overwritten. And the client, knowing nothing about the globbing
rules on the server, would have no way to check whether
PASSWORDS.DAT really _did_ match the wildcard I'd specified. (The
example above is carefully chosen; to a Unix user it seems obvious
that PASSWORDS.DAT doesn't match it, but to a VMS user it seems just
as obvious that it does!)

Now suppose I'm talking to a Unix server, so I'm _expecting_ to get
back files beginning with a or b; but suppose my server has been
taken over by a malicious attacker. He can hack the SCP server
process so that it sends back non-matching filenames, and there's
nothing my client software can do to prevent it. So if I want to
protect myself against this type of attack, then I must _always_ do
a wildcard SCP download into an empty directory, so that there are
no existing files that can be accidentally or maliciously
overwritten by the server. I'm fairly sure this is not what most SCP
users do!

There are certainly undeniable reasons why client-side globbing
causes problems. Unfortunately, I consider this to be an undeniable
reason why server-side globbing can _also_ cause problems. Where
does that leave us? On the one hand, we have potentially inaccurate
results; on the other, we have a potential security hazard (although
as far as I know I'm the only SCP implementor who considers it
remotely important). Is there any middle way possible?

Cheers,
Simon
-- 
Simon Tatham         "_shin_, n. An ingenious device for
<anakin%pobox.com@localhost>    finding tables and chairs in the dark."