Re: New draft-draft of sftp...

[Jeffrey Altman <jaltman%columbia.edu@localhost>]

I am going to have to think about this concern for a bit.  However, my
initial reaction is that if the host has been hacked so that daemon
services are replaced then I think you are in bigger trouble.  At that
point you can't count on the contents of any of the files you may
receive from that server.  Depending on what they are you will be hosed.

> 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."
> 


 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 kermit-support%columbia.edu@localhost               OpenSSL.