*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 m=
e to believe that using the scp -t>> /some/path/to/a/directory command=3D =
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 wit=
h -t) and the>"remote filename" as specified in the local shell: The local =
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 =
>> This gives us almost exactly what we were looking for>I think that depen=

ds 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/bre=
akout ?>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=

what really happens, as near as I've been able to figure out with the infor=
mation that J.P. sent me, is that the client (or local) system executes the=

ssh -i key_file {remotehost} scp -d -t ../../../../../../../../../../../tmp=

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 /s=

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 e=
xploit 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 a=
ssumption on my part), waiting for the client to send the commands needed t=
o 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 / s=
end 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 fo=
>> Like I said, I'm sitting here laughing right now, mostly because it>> wa=

s a lot of wasted effort on all sides to argue (or discuss with>> pointed s=
tatements) over something that already existed, even if it>> wasn't known o=
r 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 qua=
shed 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 oppo=
rtunity to learn something new. I hope you did as well.>//Peter
__________________________________________________ _______________
You keep typing, we keep giving. Download Messenger and join the i=92m Init=
iative now.
openssh-unix-dev mailing list