scp -t - revisited.....

[Peter Stuge]

On Thu, Dec 06, 2007 at 09:04:45PM -0600, Larry Becke wrote:
> *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*

Ah, you mentioned that you weren't subscribed back in the first
thread? Sorry, I forgot all about that.


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

..

> Using scp as you showed, would not do anything to this method.
..
> 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

..

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

Right. Which is why I was careful to point out that specifying the
tmp path in the shell (such as in the example above) will not
expose the problem.


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

Spot on. scp is not designed to confine a user to a given directory.
This is why you got a couple of different suggestions on how to solve
the problem in the first place.


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

I don't have time to demonstrate/test my idea right now, but will
try to get back to you later today. If anyone else understands what I
mean and feels like hacking up an example, please do.


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

I already knew how scp works (internally) and I suppose noone else
suggested forcing the scp -t command because it doesn't actually
provide what you initially asked for.


//Peter