scp -t - revisited.....

[Larry Becke]

*My apologies for mangling this, as I'm not a subscriber, and peter doesn't deign to reply to me as well as the list*
 
On Thu, Dec 06, 2007 at 05:26:14PM -0600, Larry Becke wrote:>> This leads me to believe that using the scp -t>> /some/path/to/a/directory  command= in the authorized_keys file>> causes scp to forget/ignore everything after the remote hostname.>There is one more step between the remote scp (run with -t) and the>"remote filename" as specified in the local shell: The local scp.
You're right as long as the scp client has the power to do anything, beyond send the file names/content.  However, with this method, the local scp is powerless.
>> This gives us almost exactly what we were looking for>I think that depends on the local scp program.
 
Sorry, not with this method.>What happens if you (within the scp protocol, not in the shell)>specify e.g. a new directory ../../../../../../../tmp/breakout ?>I would assume that /tmp/breakout is created.
Again, not with this method.
>If your local scp program is trusted then you're all set. But if that>was the case why bother with locking down the server?
Unfortunately (or in my case, fortunately), that's not how scp works.
 
Using scp as you showed, would not do anything to this method.
 
The reason being is as follows...
 
scp -i key_file  localfile  remotehost:../../../../../../../../../../../tmp/breakout
 
what really happens, as near as I've been able to figure out with the information that J.P. sent me, is that the client (or local) system executes the following.
 
ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp/breakout
 
now - normally this would cause the effect that you mentioned - except for one minor little thing.
 
The ssh key in question, is configured on the server to only run "scp -t /server/selected/path"
 
This overrides the command that was sent by the scp client, and replaces it with what we want to happen.
 
No directory selection, it gets rid of all your carefully crafted pathing exploit attempts - they're all gone, as though they never existed.
 
Now, the scp -t starts the scp server service in receive mode (this is an assumption on my part), waiting for the client to send the commands needed to create the file and it's contents (or multiple files and their contents).
 
This is the cool part - no matter what you *try* to do with the scp client, it will never do anything other than go into receive mode and wait for the transfer commands.
 
Now, if the scp protocol can be exploited some how beyond the open file / send contents, then we may have a problem - but that would be the case with scp in general.
 
I would also assume that using another key to put the scp server side into send mode  - ie    scp -f /server/selected/path - would restrict downloads from the specified directory, again, regardless of what the client asked for.
>> Like I said, I'm sitting here laughing right now, mostly because it>> was a lot of wasted effort on all sides to argue (or discuss with>> pointed statements) over something that already existed, even if it>> wasn't known or documented.>I still believe there was a good reason for that argument.
You're free to believe what you want, I found what I wanted - and it works - very well.>> (Wonders if this will be considered a bug to be fixed or quashed as>> it wasn't an intended *feature* of scp)....   I hope not...>It's just a side effect of the rcp/scp design.
Which apparently neither of us were 100% up on, and I was glad for the opportunity to learn something new.  I hope you did as well.>//Peter
LB
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM