scp -t . - possible idea for additional parameter

[Larry Becke]

> Date: Fri, 12 Oct 2007 09:19:35 +1000
> From: djm at mindrot.org
> To: guyverdh at hotmail.com
> CC: openssh-unix-dev at mindrot.org
> Subject: RE: scp -t . - possible idea for additional parameter
> 
> On Thu, 11 Oct 2007, Larry Becke wrote:
> 
> > 
> > On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretically. See my previous message.I must have missed it.
> > > Is it so terribly hard to add the feature?>It's not easy. See my previous message, and do a little research on path>canonicalization and past directory traversal vulnerabilities in, e.g.>IIS and Apache, to understand this better.
> >  
> > To throw an error and exit if "../" is in the remote path parameter?
> > To add a "./" between hostname: and /path/to/dir in the remote path parameter?
> 
> That is probably insufficient and likely to break some software that
> uses scp. You could use realpath(3) and compare the stem, but that has a
> downside too: it will break on traverse-only directories.

Since the change I'm looking for is something that would have to be
specifically selected - instead of using scp -t, using scp -T, this should (I won't say won't, because anything is possible) not break any normal use of scp.

Given that we would not actually be changing that expansion in any way,
but doing some very minor work up front, before passing the remote path
on to the unchanged code, I'm still not sure that I see that it would
break anything.



Again, as part of a pre-processor, activated only if scp were started
with the -T parameter, instead of the -t parameter, would do 2 things.

Scan the remote path for "../", and if found - error out, don't do any kind of transfer.   Give a simple error message like "Upstream directory traversal not allowed in this mode of operation."
Insert "./" between the hostname and remote directory to make it relative to the startup directory. 

hostname:/some/path/to/dir becomes  hostname:.//some/path/to/dir
hostname:   becomes   hostname:./


I still don't see anything sinister here, however, I may be oversimplifying things.



> 
> Just to be clear, I have zero interest in making any feature additions
> to scp and I think most of the developers feel the same way. It is a
> difficult protocol to extend, and its use of a shell-expanded commandline
> to inform it of which files to transfer makes it very brittle. Given its
> very widespread use, I think it is best to leave it be and concentrate
> efforts on making sftp/sftp-server a compelling substitute.

I understand that everyone that has worked on openssh past and present combined have spent a lot of time making a very nice, clean application that is widely used and respected in just about every area computer related.
However, I feel it is unfortunate to freeze scp's features, as sftp/sftp-server can (to my knowledge) in no way substitute the simplicity that is scp.
I don't see sftp being picked up as an scp replacement until  sftp can be used like scp in a single line.

example:      
sftp -f filename user at remotehost:
sftp -f user at remotehost:filename .

or

sftp -f filename -i keyfile user at remotehost:/some/dir 
sftp -i keyfile -f user at remotehost:/some/dir/filename .
The keyfile could be set to start sftp-server with the -T param (or whatever was chosen to mean, start here, lock upward traversal) and specify a starting directory.

command="/usr/libexec/openssh/sftp-server -T /some/other/path/to/start/in"

Then again, every command sent would have to be parsed to see if "../" were used and if so, error.
It would also have to insert "./" into every source path for the get/mget commands, as well as insert "./" into every destination path for the put/mput commands.
Yet, if it took this kind of command line input, then converted it to the appropriate sftp commands behind the scenes, that might work.

It seems that more work would be involved in this, than scp, but again, I am not a C developer, so maybe I'm totally off base here.


> 
> -d
> 
> PS. I don't know what mail client you are using, but it is mangling 
> the quoting in your replies into an unreadable mess.

hotmail, and very few people replying to myself as well as the mailing list, meaning that I had to cut-and-paste to reply to most people.
my apologies for the mangling....



Maybe I'm just barking up the wrong tree here, as no one seems (to me anyway), to be willing to see things from someone else's perspective.  
So far I've received "use chroot, it's great and simple."  or "use webdav and ssl - even though you have to work with keys, keystores, install a webserver, utilize wget and probably a whole plethora of things I've not found yet" or "use rsync" which unfortunately does not fit into the class of usable software for the types of scripts and transfers we are currently doing.

It seems odd to me that everyone's suggestion is to "Use someone else's software, we don't want ours to work like that."  However, being open-source, it is your software and you make the final decisions on what does and does not make it into the software as a feature.

I've already been hit up by 2 commercial ssh vendors who are eager to implement the idea, one of which already has some of the functionality built in.  I hate the idea of going that route, but may have no choice.  My apologies for wasting everyone's time reading all my useless posts.


_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook – together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033